I am using a test app that used java for TLS communication. Standard Oracle java is installed in my system.
I need to use the TLS_DHE_RSA_WITH_AES_128_CCM cipher suite, which is not supported by standard Java, so many suggested using Bouncy Castle. I downloaded and copied the bcprov-ext-jdk18on-171.jar to $JAVA_HOME/lib folder.
Also, updated java.security file to include Bouncy Castle in the provider list as below:
security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider
I still cannot get TLS_DHE_RSA_WITH_AES_128_CCM to work though.
Are the steps I did sufficient and correct? Can someone suggest the steps to install and configure Bouncy Castle?
The BouncyCastleProvider adds cryptographic algorithms such as the AES in the CCM mode of operation to the available algorithms of Cipher and other classes. As CCM is not included by default in Java, you will need to register this provider through code (i.e. Security.addProvider(new BouncyCastleProvider)) or adding it into the java.security file (as demonstrated in the question). You will probably want to add it to the end of the provider list as the algorithms of the Oracle provider are generally better tested and may be sped up using hardware acceleration.
However, the BouncyCastleProvider does not contain an implementation of the TLS protocol. You'd need to register the BouncyCastleJsseProvider for that instead. This is required as the Java TLS implementation won't magically know how to use the CCM implementation within Bouncy Castle. JSSE is an acronym of the Java Secure Socket Extension.
You can add that provider at the start of the providers so you know for sure that this provider is used for implementing TLS:
Security.insertProviderAt(new rg.bouncycastle.jsse.provider.BouncyCastleJsseProvider(), 1);
And you can also directly register it in the java.security file.
Note that the JSSE provider doesn't provide implementations such as RSA or AES for Cipher or Signature so it should not be in the way.
Related
I have to run a quite old programcode which uses ABA-provider for JCE.
All classes are available in the source folder. However, a NoSuchProviderException occures: "JCE cannot authenticate the provider ABA".
I found some related topics in the forums but they coulnd't help me out.
This is what I did:
ABAProvider prov = new ABAProvider();
Security.addProvider(prov);
In debug-mode prov is initialized but this throws the exception:
keyFactory = SecretKeyFactory.getInstance( "DES", "ABA" );
I hope this information might help you to help me :)
Thanks in advance!
ABA seems to be a cleanroom implementation of Java JCE. Just remove the dependency and use the providers supplied in your favorite runtime
Signing certificates for Java have to be renewed. You cannot use an old certificate on a new version of Java. So the signature on the provider has likely expired.
More information here:
The next step is to request a code-signing certificate so that you can use it to sign your provider prior to testing. The certificate will be good for both testing and production. It will be valid for 5 years.
The usefulness of DES for most cryptographic operations (possibly except creating 3 key TDES) has "expired" as well.
What's the padding mode for AES/GCM? I understood it can be NoPadding, as in ECB mode it can be PKCS5Padding, how about in GCM mode? in JCE interface, we need provide "algorithm/mode/padding" (Reference).
So I used the following code to get the instance and it works in JDK but failed in IBM SDK which says
cannot find provider for supporting AES/GCM/PKCS5Padding
Cipher.getInstance("AES/GCM/PKCS5Padding");
What's real use case for padding?
GCM is a streaming mode which means that the ciphertext is only as long as the plaintext (not including authentication tag). GCM doesn't require a padding. This means that the PKCS5Padding version is actually only a synonym for NoPadding for convenience during programming.
Some providers don't have this strange mode. Java has pluggable cryptographic providers and basically all JRE distributions have a default cryptographic provider which may have different cipher strings and defaults than those of other providers.
There are cases where padding the plaintext makes sense. For example, you can hide the length of the actual plaintext by appending a random length PKCS5Padding.
As known Java crypto provider require be a signed Jar file for using some algorithms types (Cipher for example) otherwise java.lang.SecurityException will be thrown (JCE cannot authenticate the provider).
Does Android require security provider be a signed jar?
I developed a simple provider with dummy cipher and as expected in JVM I received SecurityException but on Android my cipher works corrdectly.
I'd like to use AES-GCM with BouncyCastle as the provider in order to avail myself of integrity checks using decryption. I'm curious about the kind of exception raised when the integrity check fails. Is it InvalidCipherTextException?
Also are there any other exceptions I should be handling in the context of decrypting an AES-GCM encrypted blob?
I see that there are a few more exceptions listed out at http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/crypto/package-tree.html
For the lightweight API, the resulting exception is indeed the InvalidCipherTextException. This answer has been extracted from the Bouncy Castle source code, which is openly available (e.g. using anonymous access to the source repository).
if (!Arrays.constantTimeAreEqual(this.macBlock, msgMac))
{
throw new InvalidCipherTextException("mac check in GCM failed");
}
This seems identical in the 1.13 to 1.18 version of this file in the repository, please check again for later versions.
Hi
I am trying to user RSA on J9. The algorithm is offered by the 'J9JCE' provider which is an installed extension(i listed all the existing providers and algorithms and found them) but the exception i get is:
Exception in thread "main" java.security.NoSuchAlgorithmException: JCE provider signer certificates not found/read
at javax.crypto.Cipher.getInstance(Cipher.java:191)
at Test.encript(Test.java:26)
at Test.main(Test.java:42)
I still don't know the answer to the problem but a workaround is to use the provider from Bouncy Castle which works fine.