XML signature HMAC truncation authentication bypass

Jon Callas jon at callas.org
Mon Jul 27 20:11:34 EDT 2009

On Jul 26, 2009, at 10:31 PM, Peter Gutmann wrote:

> Jon Callas <jon at 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  
> 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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list