Padgett Peterson <PADGETT(_at_)hobbes(_dot_)orl(_dot_)lmco(_dot_)com> writes:
Paul Hoffman said more forcefully what I meant about IDEA being a MUST
algorithm. It's also my understanding that if any encumbered algorithm is a
MUST, the spec will be spiked.
Same-same: proprietary mechanisms always seem to fail. So let's just
say "only algorithms in the public domain *everywhere* may be
'musts'".
Sounds reasonable.
Agree with "no weak crypto" per se but a standard might want to be as broad
as possible. Am thinking of the possibility that the purpose of an algorithm
might be to enforce the *expectation of privacy* without being strong
crypto. In that case ROT13 or XOR55 might suffice.
ROT13 demonstrates almost no expectation of privacy :-)
Personally I would find 128+ bit symmetric ciphers to be much better
for _enforcing_ expectation of privacy.
What's wrong with real crypto? I'd guess even CAST128 can't compete
with XOR55 for megabytes per second, but it sure beats it for adding a
bit of extra privacy. If you're thinking of export regs, I think this
is not a good reason. Performance I don't think is the issue either?
Am also thinking of the concept of an exportable product with plug-in
capability. Would like to see the ability to plug-in new crypto modules
in any case. Know this is more product oriented but would like to see
a standard support this.
Historically this has not always helped exports, re "crypto with a
hole" and a few cases where this kind of idiocy was enforced, or where
developers were leaned up on to remove the hole.
No idea how this one has translated into the EARs.
Plug-in crypto modules is a nice feature though.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`