AES-GCM NIST Test Vectors - Not Getting Expected Results about aes-gcm-128-192-256-bits HOT 7 CLOSED

Well, I found my issue. I have been instantiating the aes_gcm module instead of the top_aes_gcm module so the parameters were not being overwritten. The top-level was used as the reference for the port mapping but I must have forgot to update the module name. Of course, this carried over when copying/pasting the instantiation to the other testbenches. Regardless, thank you for your time and consideration.

from aes-gcm-128-192-256-bits.

Hi @dmyers38

I tried the core with few (not all) the NIST vectors. The project has a testbench included that you might want to try. The DUT runs against a model created using pyCryptodome.
Could it be just a matter of loading the data in the wrong byte order (LSB vs MSB)?
I will givie it a go when I get some time.

from aes-gcm-128-192-256-bits.

@BLu85, I have tried a variety of simulations at this point. I seemingly got it working with your testbench (see attached waveform file). I had to hardcode the PT and AAD, but it does give the correct NIST output CT and Tag. However, I still cannot get it to work with any of my simulations (could still be an implementation issue). No matter what I do I end up with aforementioned CT and Tag. I don't believe it could be a byte order issue since the waveforms all show the same inputs. I've matched my simulation to follow the same timing as your testbench.

Waveform File - aes_dump.zip

I can send a VCD of one of my simulations too if that would be better than the image above.

Thank you again for your time.

from aes-gcm-128-192-256-bits.

As you said the input signals seem to be the same. It would be worth dumping your simulation in a VCD (or better .ghw file) so I can explore the sub-blocks and understand what is the source of the problem.
Also, what python command did you run to get the IP configuration for your case and for the python TB?

from aes-gcm-128-192-256-bits.

Looking at the waveforms in the image you posted, I noticed that the number of clocks between the assertion of the signal aes_gcm_icb_start_cnt_i and the assertion of the signal aes_gcm_ready_o, is less than 14 clocks. That number of clocks is the minimum needed to generate the H and J0 vectors for the AES 256 bits. Probably a misconfiguration of the IP has set it to a 128 bits key. Could you compare the generated .vhd files in the TB folder (when you said you got the correct results) with the ones that gave you the wrong result?

from aes-gcm-128-192-256-bits.

Attached is a VCD of the simulation from the waveforms above (the simulator I am using does not export to GHW). It should be noted that the testbench is driving on the negative edge of the clock to avoid race condition issues on the positive edge. However, my other simulations drive the core via FIFOs and an FSM on the positive edge of the clock. They all result in the same incorrect CT and Tag.

Also, what python command did you run to get the IP configuration for your case and for the python TB?

I used python3 gcm_config.py -m 256 -b enc -p 0 -s L to generate the IP and python3 gcm_testbench.py -m 256 -b enc -s L -k 92e11dcdaa866f5ce790fd24501f92509aacf4cb8b1339d50c9c1240935dd08b -i ac93a1a6145299bde902f21a -g for the testbench.

Could you compare the generated .vhd files in the TB folder (when you said you got the correct results) with the ones that gave you the wrong result?

The generated files in the TB and SRC directories show no differences.

Waveforms - sim_aes_dump.zip

from aes-gcm-128-192-256-bits.

This commit adds the possibility to externally load the key, iv, aad and data. NIST test vectors can be tested as:
python3 gcm_testbench.py -m 256 -b enc -s L -k 92e11dcdaa866f5ce790fd24501f92509aacf4cb8b1339d50c9c1240935dd08b -i ac93a1a6145299bde902f21a -a 1e0889016f67601c8ebea4943bc23ad6 -d 2d71bcfa914e4ac045b2aa60955fad24

from aes-gcm-128-192-256-bits.