Re: 112-bit prime ECDLP solved
At 7:54 AM -0600 7/18/09, Zooko Wilcox-O'Hearn wrote: This involves deciding whether a 192-bit elliptic curve public key is strong enough... Why not just go with 256-bit EC (128-bit symmetric strength)? Is the 8 bytes per signature the issue, or the extra compute time? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 112-bit prime ECDLP solved
On Sunday,2009-07-19, at 13:24 , Paul Hoffman wrote: At 7:54 AM -0600 7/18/09, Zooko Wilcox-O'Hearn wrote: This involves deciding whether a 192-bit elliptic curve public key is strong enough... Why not just go with 256-bit EC (128-bit symmetric strength)? Is the 8 bytes per signature the issue, or the extra compute time? Those are two good guesses, but no. The main concern is the size of the public key. This is why (if I understand correctly), hyperelliptic curves might eventually offer public key signatures which are twice as good for the purposes of TahoeLAFS as elliptic curves. (By which I mean, the keys are half as big.) I discussed this topic a bit in a subsequent message to the cryptography mailing list entitled Why hyperelliptic curves?. Actually, the computation time matters, too. Our measurements on an ARM 266 MHz embedded system showed a significant penalty for 256-bit ECDSA vs. 192-bit: http://allmydata.org/pipermail/tahoe-dev/2009-June/002083.html Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
On Jul 17, 2009, at 8:39 PM, Peter Gutmann wrote: PGP Desktop 9 uses as its default an iteration count of four million (!!) for its password hashing, which looks like a DoS to anything that does sanity-checking of input. That's precisely what it is -- a denial of service to password crackers. There are a couple of things I'll add, one in the OpenPGP standard, and one in that implementation. In the standard, the iteration count is not a count of hash iterations as in (e.g.) PKCS#5, but a length of output. So four million is four million bytes of output. For SHA-1, that's a count of 200,000, and for SHA-256 125,000 iterations. While this is a bit eccentric, it allows you to use any size hash and any block size cipher. Even more eccentric is the way it's encoded, as an 8-bit floating point value. In the implementation, we upped the default because of more password cracking, but also added a twist in it. We time the number of iterations take 1/10 of a second on the computer you're using, and use that value. The goal is to have the iteration count scale as computers get faster without having to make software changes. The downsides of this are left as an exercise for the reader (as are the obvious workarounds). Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
