RE: iSCSI: nits on SRP text key lengths

[Paul Koning <[e-mail]>]

>>>>> "Black" == Black David <[e-mail]> writes:

 Black> Careful - these keys have to be sent as text, not raw binary.
 Black> If a hex encoding is used, one gets 4 bits to the byte rather
 Black> than 8, so the current max would be 4096 bits.

Yes, but the draft talks about the length limits for the binary data,
NOT the length limit for the encoding.

 Black> Also the discussion of symmetric and asymmetric key lengths in
 Black> draft-orman-public-key-lengths-05.txt suggests that that a
 Black> 4096 bit limit might be prudent to give us some breathing room
 Black> going into the future (and one could use that draft to argue
 Black> for a significantly larger limit, but I won't).  I recommend
 Black> reading the entire draft (it'll be out as an RFC soon), as
 Black> it's very tempting to oversimplify this sort of key length
 Black> discussion, which has some subtleties.  For example, one might
 Black> think that if a 128 AES key were used with IPsec, an
 Black> equivalent strength IKE group (larger than 2048 bits) would be
 Black> needed, but that is *not* necessarily the case.

Perhaps.  But given that SRP and DH-CHAP both deal with passwords
(because after all the argument against CHAP relates to dictionary
attacks), the question becomes: how big a field modulus makes sense
for protecting passwords?  Given the entropy of passwords, I find it
hard to justify a group larger than 768 bits, never mind one that goes
into several thousand bits.  The analogy with AES doesn't really apply
because AES is far stronger than any plausible password scheme.

	paul