Re: [cp-patches] GNU Crypto and Jessie merge

[Casey Marshall]

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?