On Jan 6, 2006, at 12:50 AM, Mark Wielaard wrote:
Hi,
On Thu, 2006-01-05 at 15:07 -0800, Casey Marshall wrote:
We just shove exportable algorithms and providers under `gnu/java/
security,' and non-exportable algorithms and providers under `gnu/
javax/crypto.' Thus, if you need to make an exportable source/binary,
just `rm -rf {,gnu/}javax/crypto.' It's more of a manual process, but
very easy.
What is the definition of "non-exportable"?
It probably depends on who you ask, since different countries have
different restrictions. I think the U.S. definition of strong/non-
exportable crypto is approximately:
- Symmetric ciphers with a key length larger than 40 bits.
- MACs with a key length larger than 40 bits (I don't recall if
all MACs were disallowed, or what..
- Key exchanges (DH).
- Asymmetric ciphers (RSA) with primes larger than 512 bits.
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?
_______________________________________________
Classpath-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath-patches
