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
