Re: Cryptography provider

[Mark Wielaard]

Hi, (again CC Classpath and gnu-crypto mailinglists since some people
read those lists that know far more about these issues then I do)

On Wed, 2002-12-04 at 11:38, Joerg Brunsmann wrote:
> --- Mark Wielaard <address@hidden> wrote: 
> 
> > 4. Yes it is used for example when a SHA1 algorithm is needed for
> > calculating a class SUID. And, if I have ever time to implement it, it
> > will be used by the java.util.jar package when verifying manifest
> > signatures. (Hint, hint, if someone wants something nice to hack on ...)
> 
> But even with such an implementation the 'keytool' and 'jarsigner' tools 
> can't be implemented in gcj compiled java source code since we're missing 
> a KeyStore implementation which is distributed by default.

Correct. So this is another hacking challenge :)

Except for making sure that the java.security framework is correct we
will need to make sure that the basic algorithm support can be used by
default so that they can also easily be used in the core library classes
to implement all things like serial version uid and jar manifest
checking completely. So we would need to support (or are already
supporting) the following (see also gnu/java/security/provider):

Message Digests:
- MD5 -> MD5 class
  (Needed for Jar Manifests)
- SHA1 -> SHA class
  (Needed for SUID and Jar Manifests)

KeyPairGenerator/AlgorithmParameterGenerator/AlgorithmParameter
- DSA -> DSAKeyPairGenerator/DSAParameterGenerator/DSAParameters
  (Needed for creating keys for Jar Manifest signatures)
  (It would be nice to also support RSA and/or PGP since the Jar File
   Specification says that they are also valid ways of signing jar
   files, but I don't know if that is actually used by anyone.)

Signatures:
- SHA1withDSA -> DSASignature class
  (See above, with same remark about RSAWithMD5 and PGP.)

SecureRandom:
- SHA1PRNG -> SHA1PRNG class (buggy see Classpath bug #835)
  (Needed for generating secure keys)

KeyStore:
- ??? -> Nothing implemented yet.
  (What standard keystore format should we support?
   Maybe support a readonly version of the proprietary Sun format
   to migrate people away from it?)

Am I missing something? Enough hacking challenges for you :)
(Seriously, just testing out and/or debugging what we already have
installed would really help.)

For everything else we should encourage users to install a full security
provider such as GNU Crypto, Bouncy Castle or Cryptix. Maybe we can
import GNU Crypto, especially when they have imported the javax.crypto
framework, but I am afraid that US export restrictions will make it a
mayor PITA to handle this correctly. So I would like the GNU Crypto
people to take care of that issue since they already have made
arrangements to do this.

Cheers,

Mark