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

[Raif S. Naffah]

On Saturday 07 January 2006 07:12, Casey Marshall wrote:
> 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).

agree.  also on the crypto "hooks" issue, i think (but i am not a 
lawyer) emulating Sun in including any hooks for strong-crypto stuff in 
the non-exportable deliverable should be safe.

any insight from real-life users and packagers on how they deal with 
this issue, would help us with the right solution.


> 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?


it has to be on the strong side since it may also uses Ciphers and Macs.


cheers;
rsn

pgpdiD6Ly9fpp.pgp
Description: PGP signature