Re: XML signature HMAC truncation authentication bypass
At 05:11 PM 7/27/2009, Jon Callas wrote: By the way, do you think it's safe to phase out MD5? That will break all the PGP 2 users. Depends - if you're only replacing it with SHA-1, it's probably not worthwhile.. And if you're breaking things anyway, might as well replace most of the bit-twiddling variable-length number field types with 32-bit-word-aligned types, but nobody listened to me rant about that a decade ago :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
On Jul 26, 2009, at 10:31 PM, Peter Gutmann wrote: Jon Callas j...@callas.org writes: You are of course correct, Peter, but are you saying that we shouldn't do anything? Well, I think it's necessary to consider the tradeoffs, if you don't know the other side's capabilities then it's a bit risky to assume that they're the same as yours. Let's look at it the other way, and suppose that I said that despite increases in processor power and distributed password crackers, we would leave the iteration count where it was in 1997, because if you increase it, it might go to small machines where that would be an issue. Consider the tradeoffs. You'd call me daft for refusing to protect the majority of people. You are wrong with this. *Messages* don't have this property, so long as they were encrypted to a public key. It is unlocking the *key* that has this problem. The data was encrypted using pre-shared secrets (i.e. packet type 3) which does have this property. (Don't ask me, I didn't create the requirements, I just got called in to help diagnose the problem, which was that at some point S2K's coming from PGP Desktop were killing their embedded units. Maybe they were even using externally-generated private keys or who knows what rather than pre- shared secrets for messages, but whatever it was it was the S2K step that was causing it). Okay, password-protected files would get it, too. I won't ask why you're sending password protected files to an agent. I know you didn't design this. That problem *only* exists when you import a key from a fast client into a slow client. That problem can be fixed either through some smart software (look at the iteration count and if it's higher than you like, change it the next time you use the key), or the user can do it manually. This doesn't work in a heterogeneous environment where the requirements will be something like messages having to comply with certain parts of the OpenPGP spec, and no more. Adding riders telling users how to manually configure individual applications doesn't work because end-users will never read the technical spec, or even know that it exists. I guess we could argue this point endlessly, but I really just brought it up to mention the unintended consequences of a particular design decision, and more generally the dangers of allowing unbounded integer and general data ranges in specs. Some implementations will enforce sensible limits, many won't (and will fail against fairly trivial attacks because of this), and without any guidance in the spec the ones that do take care to bound values are deemed non-compliant while the vulnerable ones that don't do any checking are deemed compliant. This is completely backwards for a security spec. Sure, but. I think that unintended consequences is not quite the right way to put it. We don't intend to cause slow computers problems, but it was an intentional change with well-known upsides and downsides. Despite that, the upside seems to outweigh the downside. This change shipped in September 2006. It's nearly three years old, and this would make only the second issue we had with it. When it shipped, BlackBerries used signed math in computing the iteration count, and got it wrong. We made a BlackBerry export tool that reset the iteration count. That got fixed in 4.1 of the BB software, as I remember it. So with millions helped and one field problem, it's not bad. By the way, do you think it's safe to phase out MD5? That will break all the PGP 2 users. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
Jon Callas j...@callas.org writes: Okay, password-protected files would get it, too. I won't ask why you're sending password protected files to an agent. They're not technically password-protected files but pre-shared key (PSK) protected files, where the keys have a high level of entropy (presumably 128 bits, but I don't know the exact figure). So in this case the S2K isn't actually necessary because of the choice of password/PSK used. (Sorry, for non-OpenPGP folks S2K = string to key, a parameterised way of processing a password, for example by iterated hashing with a salt, into a key). By the way, do you think it's safe to phase out MD5? That will break all the PGP 2 users. The answer depends on what sort of user base you expect to have to support. In my case I disable things that I don't think get used much in betas and see if anyone complains. If no-one does, it remains disabled in the final release. Now if only I could rearrange this process so I didn't have to implement support for assorted practically-unused mechanisms in the first place... This is another interesting philosophical debate: What do other people do in terms of deprecating obsolete/insecure/little-used mechanisms? Deprecate by stealth? Flag day? Support it forever? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
Jon Callas j...@callas.org writes: You are of course correct, Peter, but are you saying that we shouldn't do anything? Well, I think it's necessary to consider the tradeoffs, if you don't know the other side's capabilities then it's a bit risky to assume that they're the same as yours. You are wrong with this. *Messages* don't have this property, so long as they were encrypted to a public key. It is unlocking the *key* that has this problem. The data was encrypted using pre-shared secrets (i.e. packet type 3) which does have this property. (Don't ask me, I didn't create the requirements, I just got called in to help diagnose the problem, which was that at some point S2K's coming from PGP Desktop were killing their embedded units. Maybe they were even using externally-generated private keys or who knows what rather than pre-shared secrets for messages, but whatever it was it was the S2K step that was causing it). That problem *only* exists when you import a key from a fast client into a slow client. That problem can be fixed either through some smart software (look at the iteration count and if it's higher than you like, change it the next time you use the key), or the user can do it manually. This doesn't work in a heterogeneous environment where the requirements will be something like messages having to comply with certain parts of the OpenPGP spec, and no more. Adding riders telling users how to manually configure individual applications doesn't work because end-users will never read the technical spec, or even know that it exists. I guess we could argue this point endlessly, but I really just brought it up to mention the unintended consequences of a particular design decision, and more generally the dangers of allowing unbounded integer and general data ranges in specs. Some implementations will enforce sensible limits, many won't (and will fail against fairly trivial attacks because of this), and without any guidance in the spec the ones that do take care to bound values are deemed non-compliant while the vulnerable ones that don't do any checking are deemed compliant. This is completely backwards for a security spec. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
Jon Callas j...@callas.org writes: 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. In that case why not use a billion iterations (or at least bytes of output), that would really slow down attackers. 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. Where this falls apart completely is when there are asymmetric capabilities across sender and receiver. Having an embedded device suspend (near) real- time processing while it iterates away at something generated on a multicore 3GHz desktop PC isn't really an option in a production environment (the actual diagnosis was messages generated by PGP Desktop cause our devices to crash because they were triggering a deadman timer that soft-restarted them, it wasn't until they used an implementation that sanity-checked input values that they realised what the problem was). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
Where this falls apart completely is when there are asymmetric capabilities across sender and receiver. You are of course correct, Peter, but are you saying that we shouldn't do anything? I don't believe that we should roll over and die. We should fight back, even if the advantage is to the attacker. Having an embedded device suspend (near) real- time processing while it iterates away at something generated on a multicore 3GHz desktop PC isn't really an option in a production environment (the actual diagnosis was messages generated by PGP Desktop cause our devices to crash because they were triggering a deadman timer that soft-restarted them, it wasn't until they used an implementation that sanity-checked input values that they realised what the problem was). You are wrong with this. *Messages* don't have this property, so long as they were encrypted to a public key. It is unlocking the *key* that has this problem. That problem *only* exists when you import a key from a fast client into a slow client. That problem can be fixed either through some smart software (look at the iteration count and if it's higher than you like, change it the next time you use the key), or the user can do it manually. Set your passphrase once to the same thing it used to be. Jon - 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
Re: XML signature HMAC truncation authentication bypass
Leandro Meiners lmein...@gmail.com quotes: For example, by specifying an HMACOutputLength of 1, only one bit of the signature is verified. This can allow an attacker to forge an XML signature that will be accepted as valid. This excessive generality is a serious problem in way too many crypto specs, and implementations of security protocols. For example PKCS #11 allows you to leak keys out of cryptographic hardware by specifying the use of a 1-bit key derivation function, allowing you to guess an entire key one bit at a time (fortunately few, if any, implementations actually support this). In the PKI world, virtually no spec requires sensible limits on anything (some years ago I brought a CA to a halt by specifying a huge salt and large iteration count for the challenge-response protocol they used to authenticate certificate issues. Then I repeated it to make sure it wasn't just a coincidence the first time :-). 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. Netscape (and obviously this test was done some years ago) will happily accept a certificate with a 1MB MPEG of a cat in the X.500 DN, but then become what could mildly be described as unresponsive once it's stored it in its cert.database. The SSH oracle attack of a few months ago was helped by the fact that the length field wasn't constrained to sensible values. This list goes on and on, it's scary just how vulnerable a lot of security software is to anything that can drop a slightly unexpected value into a data field. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
