Re: Key lengths for algorithms for variable-length keys

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <Pine.HPX.4.58.0503081150460.5475%edison.cisco.com@localhost> you write:
>>    Key data MUST be taken from the beginning of the hash output.  As
>>    many bytes as are needed are taken from the beginning of the hash
>>    value. [...]
>
>I'll make these changes unless I hear objections.

Sounds good to me.

>I also see that about half of the occurances of bit lengths are of the
>form "nnn-bit" and the other half are of the form "nnn bit".  All of the
>occurances of byte lengths are of the format of "mmm bytes".  Unless I
>hear objections, I'm going to change these to be "nnn bit" and clean up
>the syntax a bit.

I don't really care, but: If you want an adjective, you should write
"128-bit"; if you want a noun, write "128 bits".  On this basis, the errors
I can find are:

   one initialization vector).  This is a block cipher with 8 byte
(should be "8-byte")
   The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys
(should be "128-bit")
   [SCHNEIER].  This is a block cipher with 8 byte blocks.
(should be "8-byte")
   The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
   with 256 bit keys as described [TWOFISH].  This is a block cipher
(should be "256-bit")
   with 16 byte blocks.
(should be ("16-byte")
   The "arcfour" is the Arcfour stream cipher with 128 bit keys.  The
(should be "128-bit")
   The value for 'dss_signature_blob' is encoded as a string containing
   r followed by s (which are 160 bits long integers, without lengths or
(should be "160-bit-long integers" or "160-bit integers")
   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
(should be "1024-bit")
   The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit
(should be "2048-bit")

in [SSH-ARCH]:
   Because MACs use a 32 bit sequence number, they might start to leak
(should be "32-bit")

>> > If this stipulation is meant to apply to all future algorithms, it
>> > seems like a particularly bad idea.  Is it intended to prevent me
>> > defining "arcfour-256%bjh21.me.uk@localhost" to be RC4 with a 256-bit key, for
>> > instance?  If not, what does it do?
>>
>> I agree this doesn't make sense.
>
>Does anything further need to be edited or clarified if the above changes
>are made?

No.

-- 
Ben Harris