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.


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

Reply via email to