XML signature HMAC truncation authentication bypass

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