Re: FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard

Wijnen, Bert (Bert) wrote:
> FYI and possible reaction.
> 
> -----Original Message-----
> From: Steve Moulton [mailto:[email protected]]
> Subject: RE: Last Call: The AES Cipher Algorithm in the SNMP's
> User-based Security Model to Proposed Standard


> Developers at SNMP Research (namely Matt Hecht <[email protected]> and
> Brian Park <[email protected]>) have encountered some issues
> with draft-blumenthal-aes-usm-05.txt that should be addressed before 
> the document proceeds.
> 
> 1)  It would be very helpful to have a worked example, showing
>     the construction of the initialization vector and
>     the input and output of the encryption for a short message.
>     This is very helpful in verifying an implementation before
>     going to interoperability testing.  It would be unnecessary
>     to show key construction and localization steps, as those
>     are very well covered in RFC3414.

Didn't want to delay the publication


> 2)  In section 3.1.1, the text implies that the document specifying
>     AES has not been published.  Either I misunderstand
>     http://www.nist.gov/aes, or it appears that the document
>     has been published as FIPS 197.

Thank you!  You'r right, of course. Corrected.


> 3)  Several editorial changes are noted below.

All the editorials have been taken care of - thanks a bunch!!


> Since FIPS 197 gives 192 and 256 bit encryption algorithms, it would 
> have been helpful to have the document address the key extensions. I
> anticipate that there will be implementations using longer
> key lengths; addressing them in this document would help address
> interoperability.

1. The algorithm seems to be less strong with 192-bit and 256-bit keys
    under Related Keys attack. Plus, key expansion/localisation will
    have to change to accomodate these modes.
2. It is preferable to use cipher block-length=key-length.
3. Not clear if there's demand for AES with 192 and 256-bit key.

> Note:
> 
> I was unsure of the edit in section 1.3 below (changing
> "parameter s" to "parameters", but was unable to find a 
> parameter "s" in FIPS 800-38B.

It's parameter S, the numer of feedback bits of CFB.
It is there :-).


Thanks!

Regards,
Uri.