|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: nits on SRP text key lengths>>>>> "Black" == Black David <Black_David@emc.com> 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
Home Last updated: Thu Apr 11 17:18:21 2002 9610 messages in chronological order |