Re: [IPsec] rfc 8750 question

[Robert Moskowitz <[e-mail]>]

On 5/10/22 01:37, Valery Smyslov wrote:
> Hi Bob,
>
>> I just noticed that 8750 defines one algorithm number for aes-gcm:
>>
>>    30     | ENCR_AES_GCM_16_IIV        | RFC 8750
>>
>> But rfc 4106 defined 3:
>>
>>         18 for AES-GCM with an 8 octet ICV;
>>         19 for AES-GCM with a 12 octet ICV; and
>>         20 for AES-GCM with a 16 octet ICV.
>>
>>
>> so for 8750, what is the ICV length?
> It's 16.
>
> You may guess it by comparing what RFC 4106 defined:
>
> 20	ENCR_AES_GCM_16
>
> and what RFC 8750 defined:
>
> 30	ENCR_AES_GCM_16_IIV
>
> The only difference is a suffix "_IIV".

Actually, I thought that was the implicit IV size.  And thus this was 
some kind of AND condition of the base cipher AND implicit IV.

Humpf.

I really want the AES_GCM_12 used along with diet-esp.  Those 4 bytes 
are important when you are dealing with an MTU of 64 bytes and only have 
a 26 byte UDP data packet.

With diet-esp in transport mode for a single UDP app, I can have a 
2-byte SPI (server will have LOTS of clients).  I COULD get by with a 
1-byte SN, but that would only cover ~4 min of comm before advancing the 
implicit msb, so better a 2-byte SN and that gives word alignment for 
the ESP header (not really soooo important). Those 4 bytes in the ICV 
hurt.  And the data is only valid for 1sec for the app.

The lightweigt crypto (like Xoodyak) from the NIST LWC effort (workshop 
this week) looks more attractive, as I can easily only squeeze the 12 
bytes out of the sponge for the tag...