Hello!
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
I'm maintaining the azureus package for fedora and (quite some time ago), it's come to my attention (https://bugzilla.redhat.com/show_bug.cgi?id=820117) that azureus bundles an ancient version of BouncyCastle and relies on the JCEECDHKeyAgreement class. This class no longer exists in current BouncyCastle and all information I can find about it is a javadoc of a rather old Bouncycastle version (http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/jce/provider/JCEECDHKe...) So now my question is, does anyone have any good leads on how to convert this too use the current BouncyCastle API? The problematic (upstreams) sources can be found in http://svn.vuze.com/public/client/branches/BRANCH_4812/azureus2/src/com/aeli...
On 02/24/2014 07:46 AM, David Juran wrote:
Hello!
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
Hello David,
The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi".
Michal
I'm maintaining the azureus package for fedora and (quite some time ago), it's come to my attention (https://bugzilla.redhat.com/show_bug.cgi?id=820117) that azureus bundles an ancient version of BouncyCastle and relies on the JCEECDHKeyAgreement class. This class no longer exists in current BouncyCastle and all information I can find about it is a javadoc of a rather old Bouncycastle version (http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/jce/provider/JCEECDHKe...) So now my question is, does anyone have any good leads on how to convert this too use the current BouncyCastle API? The problematic (upstreams) sources can be found in http://svn.vuze.com/public/client/branches/BRANCH_4812/azureus2/src/com/aeli...
Hello
On mån, 2014-02-24 at 09:17 +0100, Michal Srb wrote:
On 02/24/2014 07:46 AM, David Juran wrote:
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi".
Is this class provided in fedora? I can see it in the bouncycastle sources but not in bcprov.jar. Am I missing something obvious?
On 02/25/2014 05:15 PM, David Juran wrote:
Hello
On mån, 2014-02-24 at 09:17 +0100, Michal Srb wrote:
On 02/24/2014 07:46 AM, David Juran wrote:
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi".
Is this class provided in fedora? I can see it in the bouncycastle sources but not in bcprov.jar. Am I missing something obvious?
It is, but only in Rawhide. I updated bouncycastle package(s) yesterday.
http://koji.fedoraproject.org/koji/buildinfo?buildID=500443
Michal
On ons, 2014-02-26 at 07:02 +0100, Michal Srb wrote:
On 02/25/2014 05:15 PM, David Juran wrote:
Hello
On mån, 2014-02-24 at 09:17 +0100, Michal Srb wrote:
On 02/24/2014 07:46 AM, David Juran wrote:
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi".
Is this class provided in fedora? I can see it in the bouncycastle sources but not in bcprov.jar. Am I missing something obvious?
It is, but only in Rawhide. I updated bouncycastle package(s) yesterday.
Thanks!
The javadoc sub-package seem a bit... Lacking. It has some examples, but the typical API documentation is missing.
Also, I don't want to be ungreatful, but any clues what happened to org.bouncycastle.jce.provider.JCEIESCipher which used to be in bouncycastle-1.46? Any hints of what to use instead?
On 02/27/2014 03:13 PM, David Juran wrote:
On ons, 2014-02-26 at 07:02 +0100, Michal Srb wrote:
On 02/25/2014 05:15 PM, David Juran wrote:
Hello
On mån, 2014-02-24 at 09:17 +0100, Michal Srb wrote:
On 02/24/2014 07:46 AM, David Juran wrote:
I would need help with some pointers for how to find a replacement for (the ancient?) org.bouncycastle.jce.provider.JCEECDHKeyAgreement.
The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi".
Is this class provided in fedora? I can see it in the bouncycastle sources but not in bcprov.jar. Am I missing something obvious?
It is, but only in Rawhide. I updated bouncycastle package(s) yesterday.
Thanks!
The javadoc sub-package seem a bit... Lacking. It has some examples, but the typical API documentation is missing.
Also, I don't want to be ungreatful, but any clues what happened to org.bouncycastle.jce.provider.JCEIESCipher which used to be in bouncycastle-1.46? Any hints of what to use instead?
You can generally ask the JDK for a particular algorithm:
javax.crypto.KeyAgreement ecDH = javax.crypto.KeyAgreement.getInstance("ECDH");
in a provider-agnostic way so that it should not really be necessary to get into the BC code.
In fact, I just looked at Azureus and they seem to have commented that out. Perhaps bouncycastle did not support ECDH at that time?
You can try to delete the InternalDH class and any reference to bouncycastle and try using the above line instead.
On tor, 2014-02-27 at 15:51 -0500, David Walluck wrote:
You can generally ask the JDK for a particular algorithm:
javax.crypto.KeyAgreement ecDH = javax.crypto.KeyAgreement.getInstance("ECDH");
Well, at least it compiles... (-:
in a provider-agnostic way so that it should not really be necessary to get into the BC code.
In fact, I just looked at Azureus and they seem to have commented that out. Perhaps bouncycastle did not support ECDH at that time?
Is there any way of knowing which crypto:s are supported by a specific bouncycastle installation? I.e. will this work with bouncycastle-1.46 on F20 or will it require rawhide with bouncycastle-1.50?
On 03/03/2014 03:39 AM, David Juran wrote:
Is there any way of knowing which crypto:s are supported by a specific bouncycastle installation? I.e. will this work with bouncycastle-1.46 on F20 or will it require rawhide with bouncycastle-1.50?
The easiest way to check is to make a test class and to put the call from the last email inside a try..catch block as it will throw a NoSuchAlgorithmException if it's not supported in that version.
To look for the supported algorithms more specifically, it is a bit complicated since DH is actually an alias. I don't currenly have EC on my system, but it will look something like: Alg.Alias.KeyAgreement.DH:DiffieHellman (but the EC variant).
You could start with something like: java.security.Provider p = java.security.Security.getProviders(). Here p.getName() will return something like "BC" for bouncycastle. Then, you could iterate over java.security.Provider.stringPropertyNames(). At least if you use this code you can verify that the BC provider is loaded and all of the algorithms that it supports.
NB: In the code I gave in the last email, the addition of the second argument "BC" will force the BC provider to be used, otherwise it will check all available providers. I think you should actually prefer to check them all, although it does not look like the SunEC Provider is available in OpenJDK which will make having BC loaded a requirement.
On mån, 2014-03-03 at 04:25 -0500, David Walluck wrote:
On 03/03/2014 03:39 AM, David Juran wrote:
Is there any way of knowing which crypto:s are supported by a specific bouncycastle installation? I.e. will this work with bouncycastle-1.46 on F20 or will it require rawhide with bouncycastle-1.50?
The easiest way to check is to make a test class and to put the call from the last email inside a try..catch block as it will throw a NoSuchAlgorithmException if it's not supported in that version.
So for the curious, it seems that both the F20 and rawhide versions do support ECDH. For F19, I'm still pushing it to testing, so I guess we'll find out (-:
To look for the supported algorithms more specifically, it is a bit complicated since DH is actually an alias. I don't currenly have EC on my system, but it will look something like: Alg.Alias.KeyAgreement.DH:DiffieHellman (but the EC variant).
You could start with something like: java.security.Provider p = java.security.Security.getProviders(). Here p.getName() will return something like "BC" for bouncycastle. Then, you could iterate over java.security.Provider.stringPropertyNames(). At least if you use this code you can verify that the BC provider is loaded and all of the algorithms that it supports.
What I actually did was just to do java.security.Security.addProvider(new BouncyCastleProvider()) without much further checking. But I guess if https://bugzilla.redhat.com/show_bug.cgi?id=711090 got solved, I wouldn't even have to do that.
NB: In the code I gave in the last email, the addition of the second argument "BC" will force the BC provider to be used, otherwise it will check all available providers. I think you should actually prefer to check them all, although it does not look like the SunEC Provider is available in OpenJDK which will make having BC loaded a requirement.
Bah, makes total sense, so much for pushing before reading the _entire_ email. Thanks (-:
On 03/03/2014 02:54 PM, David Juran wrote:
So for the curious, it seems that both the F20 and rawhide versions do support ECDH. For F19, I'm still pushing it to testing, so I guess we'll find out (-:
How did you test this? Note that it will compile even with a bogus string and would only fail when it hits this code path at runtime.
What I actually did was just to do java.security.Security.addProvider(new BouncyCastleProvider()) without much further checking. But I guess if
Well, this installs the bouncycastle provider. So without providing any 2nd argument to getInstance(), it will iterate through all installed providers until it finds something, or throws an exception if it does not find anything with that name.
On mån, 2014-03-03 at 15:18 -0500, David Walluck wrote:
On 03/03/2014 02:54 PM, David Juran wrote:
So for the curious, it seems that both the F20 and rawhide versions do support ECDH. For F19, I'm still pushing it to testing, so I guess we'll find out (-:
How did you test this? Note that it will compile even with a bogus string and would only fail when it hits this code path at runtime.
I created the attached test program. And since running it didn't throw any exception, I concluded that it works. Or?
On 03/03/2014 02:54 PM, David Juran wrote:
What I actually did was just to do java.security.Security.addProvider(new BouncyCastleProvider()) without much further checking. But I guess if https://bugzilla.redhat.com/show_bug.cgi?id=711090 got solved, I wouldn't even have to do that.
I just looked at this. This seems to apply to the old GCJ/Classpath only, not OpenJDK. I am not sure that file is marked as config for OpenJDK. but there really should be a better mechanism for this in Linux.
I think there is no difference installing it dynamically the way you did, which is correct. The static install obviously makes it available automatically to all applications and there is no need to import any bouncycastle classes directly.
java-devel@lists.fedoraproject.org
-
David Juran -
David Walluck -
Michal Srb