On 02/24/2014 07:46 AM, David Juran wrote: Hello David, The replacement you are looking for is probably "org.bouncycastle.jcajce.provider.asymmetric.ec.KeyAgreementSpi". Michal

On 02/25/2014 05:15 PM, David Juran wrote: It is, but only in Rawhide. I updated bouncycastle package(s) yesterday. http://koji.fedoraproject.org/koji/buildinfo?buildID=500443 Michal

On 02/27/2014 03:13 PM, David Juran wrote: 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 03/03/2014 03:39 AM, David Juran wrote: 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 03/03/2014 02:54 PM, David Juran wrote: 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. 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 03/03/2014 02:54 PM, David Juran wrote: 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.