SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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