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

[Casey Marshall]

On Jan 6, 2006, at 1:12 PM, Raif S. Naffah wrote:

> On Saturday 07 January 2006 05:48, Casey Marshall wrote:
> > On Jan 6, 2006, at 12:41 AM, Raif S. Naffah wrote:
> > > On Friday 06 January 2006 10:07, Casey Marshall wrote:
> > > > After thinking about exportability a little more, I think the best
> > > > option may be to not provide any `--disable-crypto' option at all,
> > > > and just structure the source code so that packagers can remove
> > > > all non-exportable crypto by just removing whole directories. The
> > > > build system doesn't care if you remove an entire package, anyway.
> > > >
> > > > This is a little closer to what Raif suggested, but I'd suggest
> > > > not doing it by splitting the hierarchy up. That is, instead of
> > > > making the boundary:
> > > >
> > > >    <root>/gnu/javax/crypto/prng             <-- weak algs
> > > >    <root>/non-export/gnu/javax/crypto/prng  <-- strong algs
> > > >
> > > > 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.
> > > >
> > > > How does this sound?
> > >
> > > how do you address the Factory classes? a Factory for a split
> > > "service"
> > > must see all its subordinates, which are different depending on
> > > whether
> > > the non-exportable stuff is in or out.  yes?
> >
> > Splitting into strong and weak factories might be the best bet.
>
> no. that does not make sense; unless... we do something like this:
>
> abstract class WeakOrStrongXxxFactory implements IFactory {
>   ...
> }
>
> public abstract XxxFactory implements IFactory {
>    private static IFactory weakFactory;
>    private static IFactory strongFactory;
>    static {
>       weakFactory = new WeakXxxFactory();
>       strongFactory = Configuration.ENABLE_STRONG_CRYPTO
>             ? new StrongXxxFactory()
>             : null;
>    }
>
>    pubic static final IXxx getInstance(String name) {
>       Ixxx result = weakFactory.getInstance(name);
>       if (result != null)
>          return result;
>
>       if (strongFactory != null)
>          return strongFactory.getInstance(name);
>    }
> ...
> }
>
> interface IXxxFactory {
>    getInstance...
>    getNames...
> }

You have to do that if you want to present a unified factory  
interface to (e.g.) all PRNG implementations. But we don't have to do  
that, here, because there already is a unified factory for PRNGs:  
java.security.SecureRandom, and that's the one that makes sense for  
Classpath. The weak provider queries the weak PRNG factory, and the  
strong provider queries the strong factory.

> > Otherwise, I'd instead try using reflection for the strong
> > algorithms, which may not exist at runtime. There will be a split
> > between JCE providers on strong/weak boundaries anyway.
> >
> > This seems kind of academic, though, because I don't think there are
> > many packages that need to be split in half based on strength (PRNG,
> > obviously. Anything else?).
>
> Key pairs: DSS (weak) - DH and RSA (strong)
> Signatures: DSS (weak) - RSA (strong)

I don't think RSA, as a signature algorithm, is considered strong  
crypto; the implementation (PKCS#1) signs a hash of the message, so  
it's not `invertible' [1]. Same for key pairs -- they're just  
collections of bits, not actual encryption.

There would be an issue with keeping DH key pairs on the `weak' side:  
they depend on classes under javax.crypto.{spec,interfaces}, but  
those are probably OK to export.

Maybe someone who knows exactly what they can or cannot export has  
some guidance.

1. <http://www.rsasecurity.com/rsalabs/node.asp?id=2331>

> > Also, we don't really need the Factory
> > classes in most places, like the JCE adapters, because we can just
> > replace calls to
> >
> >    FooFactory.getInstance ("Bar");
> >
> > to
> >
> >    new Bar ();
> >
> > As a stand-alone API, the factory classes should have used reflection
> > and had some amount of configurability, because as-is they aren't all
> > that flexible.
>
> i don't think it's a good idea to drop the Factory Pattern, just  
> because
> it is more convenient for packaging.  we can debate that issue on the
> GNU Crypto list if you want.

I'm talking about GNU-Crypto-in-Classpath, though, so why does a  
Factory make sense in that context? It seems to me like it's little  
more than an additional level of indirection (security-getInstance ->  
wrapper -> factory-getInstance -> class, instead of security- 
getInstance -> wrapper -> class).

And, I didn't say GNU Crypto's API should drop Factories, I said they  
should be made more flexible then they are now.

Thanks.