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 <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
