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'".
My comment was supposed to be dry humor,
akin to saying that if you light a match in a powder room, you may
experience superficial burns.
More likely to get slapped.
I'd also like to note that the principle of "no weak crypto" is in the
charter, so I'm not including any weak algorithms, period.
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. Possibly is something that
would only concern US lawyers and we already have UUENCODE and BASE64 to
do the same thing but is something I have been thinking about for a while.
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.
Warmly,
Padgett