At 05:34 PM 7/29/2005 -0400, Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, Alex Alten write
>At 08:12 AM 7/25/2005 -0400, Steven M. Bellovin wrote:
>>In message <[EMAIL PROTECTED]>, Alex Alten
>> >Steve,
>> >
>> >This also seems to be in conjunction with the potential switch over from
>> >RSA et al. to
>> >ECC for PKI, etc.
>> >
>>Yes, Eric and I have been talking about that, and we'll add some
>>discussion of that to the next version of the paper.
>Variable output is really needed too, say 16, 32, 64, 128, 256 and 512 bits.
>And on the wishful side, the ability to optimize compression across
>multiple CPUs.

That's completely orthogoal to what the paper is about.  We're talking
about how to convert to *any* new hash algorithm; we're not concerned
with which is chosen.  (I confess, though, that hash outputs of less
than 128 bits don't strike me as cryptographically useful except for
HMAC and the like.)

Sorry for going off on a tangent.

Actually 32 (or even 16) bits is really useful for retrofitting old insecure protocols where you don't want to alter the header size, you only need access control, and the packets only exist
for less than 100 msecs.

- Alex


- Alex Alten

[Moderator's note: I have to strongly disagree. 16 bits is rarely, if
ever, of any use in authentication in a modern system. Even if you
think something can't live long enough to be spoofed, it usually can,
and as it turns out, attackers are often cleverer than protocol
designers. Crypto is too brittle to play such games with it. --Perry]
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to