multiple message support

[alphaprobe]

Can the core handle multiple messages ? Lets say the first message is 18bytes. The first cycle byte enables will obviously be FFFF and the second cycle byte enables are 0xC000. Then after many clock cycles second message of size 20 bytes arrives with first cycle byte enables as 0x3FFF (and data also barrel shifted by 2 bytes), second cycle of second message with byteenables as 0xFC00 i.e remaining 6 bytes.

If the data inputs and byteenables are handled outside the core, will the core be able to handle it ?

I am planning to modify the test environment to generate a text file with multiple lines, each line representing one message and then using it to feed the encryption core by adjusting/barrel shifting the aes_gcm_data_in_i and aes_gcm_data_in_bval_i signals. But i wish to know if the core can handle it in the first place.

[BLu85]

If each message stimulates the aes_gcm_ghash_pkt_val_i then you won't see them as if you had sent through the AES core a single message that was the concatenation of them. At the falling edge of the signal aes_gcm_ghash_pkt_val_i the Tag is produced and the aad and the ct counters are reset. Also you need to manage the data alignment outside the core (byte enable 0x3FFF won't be accepted).

[alphaprobe]

I have simulations where there are holes in the aes_gcm_data_in_bval_i (switching between 0x0000 and 0xFFFF until the end) by forcing the "bit-3 : inserts a delay between a Data in and the next one" in self.data['delays']. My observation is that aes_gcm_ghash_pkt_val_i and aes_gcm_ghash_pkt_val_i should never be de-asserted until last message is sent. So the TAG will not be produced right until the end of simulation. So that makes sure the aad and ct are never reset in entire simulation. The challenge is going to be one cycle delayed increment of counter since we need to contnue use the Ek from from older counter value needs to be figured out. Checking.

[BLu85]

You can have holes in the aes_gcm_data_in_bval_i, that is fine. If you set low aes_gcm_ghash_pkt_val_i then the Tag is produced. This signal needs to be valid for the entire message (for both aad and data).

[alphaprobe]

I should have added one detail. The aad is dont care for me. So i dont care if the tag is generated at the end of the entire test. I just need to make sure cipher text is valid across all the messages and has to be sent as available immediately. This allows me to keep aes_gcm_ghash_pkt_val_i asserted in the entire simulation consisting multiple independent messages.

[BLu85]

In that case you can just remove lines 285 and 287 in the file gcm_ghash.vhd. That will let you have the tag always available.

[alphaprobe]

Hi Luca, I have figured out how to get the core working with multiple messages. I only had to add below lines in gcm_gtr.vhd file, before gtr_ack is assigned

gctr_data_in_bval_i_pulse <= or_reduce(gctr_data_in_bval_i); gctr_data_in_bval_store_0 <= and_reduce(gctr_data_in_bval_comb); gtctr_ack_p: process(rst_i, clk_i) begin if rst_i = '1' then gctr_data_in_bval_old <= (others => '0'); elsif rising_edge(clk_i) then if gctr_data_in_bval_i_pulse = '1' then if gctr_data_in_bval_store_0 = '1' then gctr_data_in_bval_old <= (others => '0'); else gctr_data_in_bval_old <= gctr_data_in_bval_comb; end if; end if; end if; end process;

gctr_data_in_bval_comb <= 
gctr_data_in_bval_old or gctr_data_in_bval_i when gctr_data_in_bval_i_pulse = '1' else
(others => '0');  -- Assign all bits to '0' when pulse is not active
And the assignment of gctr_ack assignment changed to 

gctr_ack <= not(ghash_h_loaded_i and ghash_j0_loaded_i) or and_reduce(gctr_data_in_bval_comb);

With those changes if first message ends at 0xF000 and next starts with 0x0FFF, the gctr_ack pulse is suppressed during 0xF000 cycle and assigned 1 during next 0x0FFF cycle,

[BLu85]

Hi @alphaprobe, Glad you managed to sort it. I guess this thread can now be closed?