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

[Raif S. Naffah]

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

i was under the impression that it would be desirable to have that 
behind the JCE facade so that internally to Classpath, all 
crypto-related classes can get what they need without using the JCE 
mechanism.


> >> 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).

is not that what the current JCE Adapters do, or are you suggesting that 
this will change?


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


cheers;
rsn

pgpHEwmifKodg.pgp
Description: PGP signature