On Fri, 2006-01-06 at 12:12 -0800, Casey Marshall wrote: > I'd propose playing it safe, and defining weak/strong as: > > Weak: all hash functions (SHA, MD5, etc.) and digital signature > algorithms (RSA, DSA). PRNGs based on hash functions (e.g. SHA1PRNG). > Strong: all ciphers, symmetric (AES, DES, etc.) and asymmetric > (RSA). All MACs (HMACs, OMAC, etc.). Key exchange functions (DH, > SRP). Cipher-based PRNGs (Fortuna, CSPRNG). > > The wrinkle may be SASL. That API deals with authentication, not > crypto, so I don't think it is subject to these restrictions. We can > include SASL in the `strong' side, since it uses SRP, a generic key > exchange, but that would unnecessarily limit the usefulness of a > crypto-disabled Classpath. > > Thoughts?
IANAL, and please don't consider this legal advice, but I did check with a lawyer, who checked with another lawyer. But, again, please don't consider this legal advice. That being said... It seems that the only way to avoid an export submission is to eliminate all confidentiality algorithms from the exported libraries (even under-40-bit confidentiality requires a submission to BIS that is quite similar to a review request, although BIS does not issue a CCATS for 56 bit and under products). Algorithms/protocols that can be used only for authentication, signature and integrity do not require such a submission. Thus, hash algorithms and PRNGs are OK, and MACs should also be OK (since they are one-way functions that cannot easily be used for confidentiality). Likewise, assuming that SASL cannot be diverted for confidentiality uses, it would be OK to include in the libraries. (and assume that this does not apply to exports from the US to their restricted countries, which I'm told today includes Cuba, Iran, Libya, North Korea, Sudan and Syria) (and THIS INFORMATION COULD BE WRONG! Please don't count on it! Check for yourself!) That being said, having the code divided along these lines would be convenient to me. AG _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
