XML signature HMAC truncation authentication bypass

[Peter Gutmann]

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.

>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 majordomo at metzdowd.com