Re: CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits
"James Kempf" <[email protected]>
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <029201c37c8c$f5b54870$956015ac@dclkempt40> |
Hi Charlie,
These are good arguments, but I don't see them swaying the security
directorate. Assuming one instruction per cycle and perhaps 100 instructions
to check, a 2 GHz Pentium can check about 20 million tokens per second.
Assuming 200 ms active time, that's about 4 million tokens in the time that
the token is active.
One can argue with the details of the above calculation, but it is the kind
of thing I'd expect to see pop out of a security review. Of course, I
suppose we could argue that the document is Experimental anyway, so perfect
security isn't necessary, but what's the harm in lengthening the field?
jak
----- Original Message -----
From: "Charlie Perkins" <[email protected]>
To: "James Kempf" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, September 16, 2003 12:34 PM
Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by
truncating the results of the HMAC_SHA1 computation to retain only the
leading 32 bits
>
> Hello James,
>
> I don't think it is needed, for two reasons:
>
> - The authorization token is only going to be used once
>
> - The data being protected is only good for a few hundred
> milliseconds at most (typically).
>
> Regards,
> Charlie P.
>
>
> James Kempf wrote:
>
> >Issue 22 suggests that 32 bits isn't enough for the authorization token.
> >
> >See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for
details.
> >
> >Possible resolutions:
> >
> >1) Make the authorization token longer, say 64 bits.
> >2) Keep the authorization token at 32 bits.
> >
> >Suggested resolution: Make the authorization token longer, say 64 bits.
> >Justification: The probability of a birthday attack is proportional to
> >2**(sqrt(n)), where n is the number of bits in the identifier. If n is
32,
> >then sqrt(n) is 16, which is not enough protection (65536). Making n
equal
> >64 means sqrt(n) is 32 (over 4 billion) which should be enough.
> >
> >
> >_______________________________________________
> >Seamoby mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
>
>
>