DPAv4.2 OPOI window, error when re-creating the dataset

[lambdaupb]

Hi, I'm interested in using the OPOI subset of the DPAv4.2 dataset from your paper.

Is it possible there is a mixup in the code?

As I see it, the convert_to_h5.py selects the window [0:400_000] into the files
dpa_v42_0_100000.h5, dpa_v42_100000_200000.h5, dpa_v42_200000_300000.h5 and dpa_v42_300000_400000.h5
(each 100k samples)

Then generate_dataset.py merge_dataset skips the first 100_000 samples, making the window [100_000:400_000]

feature_selection_dlsca/experiments/DPAV42/generate_dataset.py

Lines 320 to 326 in eb5b909

	ns_chunck = 100000
	attack_samples = np.zeros((n_attack, 300000))
	profiling_samples = np.zeros((n_profiling, 300000))
	for s_i in range(1, 4):
	fs = ns_chunck * s_i

into file dpa_v42_full.h5 (300k samples)

then generate_nopoi(20) for some reason skips the first 150k samples:

feature_selection_dlsca/experiments/DPAV42/generate_dataset.py

Lines 214 to 221 in eb5b909

	def generate_nopoi(window, desync=False):
	n_profiling = 70000
	n_attack = 10000
	number_of_samples = 150000
	in_file = h5py.File(f'{dataset_folder_dpav42_nopoi}/dpa_v42_full.h5', 'r')
	profiling_samples = np.array(in_file['Profiling_traces/traces'], dtype=np.float32)[:, 150000:]
	attack_samples = np.array(in_file['Attack_traces/traces'], dtype=np.float32)[:, 150000:]

which results in a 150k (300k - 150k) sample intermediate set which is averaged with stepsize=10

dpa_v42_nopoi_window_20.h5 then has 15k samples per trace.

However the generate_opoi() function then indexes into the dpa_v42_nopoi_window_20.h5 with [17000:17400] and [20600:21000], which are larger than the 15k samples available.

For me at least this leads to an error:

/tmp/ipykernel_2697999/2547568393.py in generate_opoi()
    179 
    180     for i in range(len(profiling_samples)):
--> 181         profiling_samples_opoi[i][:400] = profiling_samples[i][17000:17400]
    182         profiling_samples_opoi[i][400:] = profiling_samples[i][20600:21000]
    183 

ValueError: could not broadcast input array from shape (0,) into shape (400,)

Question 1

Is the window of [170_000:174_000] and [206_000:210_000], as mentioned in the Paper the correct range in the raw original DPAv4.2 traces?

I'm asking since I'm having trouble getting a good GE attack with the ID MLP and others. I probably have a bug somewhere, but I wanted to confirm I'm not working on a wrong sample window.

Or would it be possible for you to provide the DPAv4.2 OPOI .h5 file for me to use?
Compressed it should be reasonably small, maybe its even possible to attach them here in this issue.

[AISyLab]

It is very likely that line 156 from https://github.com/AISyLab/feature_selection_dlsca/blob/master/experiments/DPAV42/generate_dataset.py should be:
in_file = h5py.File(f'{dataset_folder_dpav42_nopoi}/dpa_v42_nopoi_window_10.h5', "r")
instead of:
in_file = h5py.File(f'{dataset_folder_dpav42_nopoi}/dpa_v42_nopoi_window_20.h5', "r")
where the dataset has 30000 features instead of 15000.
Let us know if it solves the problem.
Thank you

[lambdaupb]

I've found out that the DPAv4 dataset used in the methodology paper by Zaid et. al. use the window [270_000:274_000]

See my analysis here:
gabzai/Methodology-for-efficient-CNN-architectures-in-SCA#4 (comment)

I think the offset of 150k in the generate Nopoi might have been added after the OPOI datasets used in the feature selection paper have been generated.

Since the offsets given in your code are exactly 100k smaller than in the Zaid et. al. dataset, my first thought is, that your dataset too is actually [270_000:274_000] and the mask is at [306_000:310_000].

The unmasked attack is successful on byte 0 using the [270_000:274_000] interval.

Question 1: Is your attack on the masked or unmasked data?

Question 2: Do the offsets [270_000:274_000] and [306_000:310_000] seem like they were the ones used for the DPAv4.2 OPOI dataset in the feature selection paper?

Thanks your your help, I appreciate it a lot.

[lambdaupb]

Ok, I have replicated the OPOI DPAv4.2 results by using the windows [270_000:274_000] and [306_000:310_000] without unmasking.

This probably means the offsets given in Table 2 in Section 3 has wrong offsets given for the OPOI DPAv4.2 dataset.

[AISyLab]

Hi,

I believe that Zaid's paper only consider DPAv4 instead of DPAv4.2.
But, yes, one interval should contain masks and the other one masked sbox output for the first key byte. Have the attack worked for you on OPOI dataset with 800 features?
Best regards

[lambdaupb]

I was confused about the DPA 4.0 vs. 4.2 in Zaid's paper as well.

However the footnotes link to the DPAv4.2 dataset page, I matched the first trace in the Zaid DPAv4 dataset to the first trace in the raw 4.2 dataset download and the issue linked above Zaid also refers to the DPAv4.2 dataset, I assume that the paper confusingly uses DPAv4 as a shorthand for DPAv4.2.

Yes, I was able to get a Ntge ~ 4 for the 800 sample ( [270_000:274_000] + [306_000:310_000]), averaged win20 stride10 dataset without providing the mask with the OPOI MLP best from this repository with an independent implementation of the attack.