Thanks for this long and thoughtful reply. Some feedback below
Jon Callas wrote:
If you look at the basic components we have, the ciphers, hash
functions, and so on, they're all secure enough that a major government
can't crack them. [...]
If you look at the medium-level functions, like HMAC, salted hashing,
tweakable cipher modes, and so on, they are *more* secure. [...]
If you look at the protocols, like TLS, IPsec, OpenPGP, S/MIME, and so
on, they're also secure, because they assemble the reasonably secure
components together reasonably securely. [...]
All of these things are freely exportable. It's just a matter of
filling out paperwork.
Indeed, there is no doubt that good algorithms and good protocols are
implemented in exportable implementations.
I was referring mainly to key management and implementation correctness
for "hard things" in applied cryptography, e.g.
how to hide a secret on a comupter system, e.g. from Trojan horse
how to distribute trust in a remote party public key given that
brwosers and OSs allow easy tampering with the list of "trusted" CAs,
how to make secret random generation reliable in the presence of
"ennemy" software on the local system
how to provide traffic flow confidentiality
strength of the API between the (non-crypto) application and the
all of the above with a fool-proof user interface, including at
crypto-application installation time
I don't have an example of a cryptosystem that I'd actually want to use
that is non-exportable. And I'm sure that if someone made something
that is custom, it's exportable. I have direct evidence of this.
Agreed, if you are satisfied with the current state of development for
IT security with respect to issues such as the above ones, and if the
extent of customization does not include innovations in these issues.
Otherwise, the export control regime is still a nuisance.
Back in 1999, when we were at Counterpane together, John Kelsey and I
created a set of incompatible Blowfish variants.
By itsef, that's alggorithm tweaking. Remote from key management and
implementation pitfall avoidance.
- Thierry Moreau
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]