Jon Callas <j...@callas.org> writes: >I've always been pleased with your answer to Question J, so I'll say what >we're doing at PGP.
That wasn't really meant as a compliment :-). The problem is that by leaping on things the instant they appear you end up having to support a menagerie of wierdo algorithms and mechanisms that the industry as a whole never adopts. How many crypto libraries that could be used to implement the OpenPGP spec actually support Haval, or Tiger, or Twofish, or SAFER-SK128? The result of this too-quick adoption has been a bunch of gaps in newer versions of the spec (look for a range of algorithm IDs marked as "reserved") where algorithms adopted too quickly were removed again when they failed to gain general (or any) acceptance. Another concern with too-quick adoption is the potential for moving to an algorithm that's later found to be flawed. This hasn't happened yet for cryptographer-designed algorithms and mechanisms (as opposed to WEP et al) but it's quite possible that some new algorithm introduced at Crypto n is shown to reduce to rot-13 in a paper published in Crypto n+1. I use an informal five- year rule that I won't make an algorithm a default (i.e. enabled without explicit user action) until it's had active attention paid to it for at least five years, where "active attention" means not so much published in an obscure conference somewhere but required in an industry spec or something similar that results in active scrutiny of its security. (Actually it's not quite that simple, it's more of a balancing act and the pace depends on whether there are credible threats to the current default algorithm or not). In crypto, "new" doesn't necessarily mean "better", it can also mean "riskier". Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com