Re: XML signature HMAC truncation authentication bypass

2009-07-29 Thread Bill Stewart

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

2009-07-28 Thread Jon Callas


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

2009-07-28 Thread Peter Gutmann
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

2009-07-27 Thread Peter Gutmann
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

2009-07-26 Thread Peter Gutmann
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

2009-07-26 Thread Jon Callas
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

2009-07-20 Thread Jon Callas

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

2009-07-19 Thread Peter Gutmann
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


XML signature HMAC truncation authentication bypass

2009-07-17 Thread Leandro Meiners
XML Signature Syntax and Processing (XMLDsig) is a W3C recommendation
for providing integrity, message authentication, and/or signer
authentication services for data. XMLDsig is commonly used by web
services such as SOAP. The XMLDsig recommendation includes support for
HMAC truncation, as specified in RFC2104. However, the XMLDsig
specification does not follow the RFC2104 recommendation to not allow
truncation to less than half of the length of the hash output or less
than 80 bits. When HMAC truncation is under the control of an attacker
this can result in an effective authentication bypass. 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.
- http://www.kb.cert.org/vuls/id/466161


More information at:
HMAC truncation in XML Signature: When Alice didn't look.
- http://www.w3.org/QA/2009/07/hmac_truncation_in_xml_signatu.html



-- 
Leandro Federico Meiners

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com