Don't want to use unlimited strength policy files
Your code snippet throws an InvalidKeyException despite using BouncyCastle, because you are not using the BC Lightweight API. If you access BC through the JCE API then the same limits on crypto strength apply as with Sun/Oracle providers. PKCS#12 files are usually encrypted with 3DES (pbeWithSHA1And3-KeyTripleDES-CBC), which is not restricted...
AES with PKCS#5 padding
java,encryption,aes,bouncycastle,jce
The code is indeed using PKCS#7 instead. The reason that "PKCS5Padding" is specified is very likely due to compatibility with the older DES and 3DES ciphers. Note that PKCS#5 padding is exactly 8 bytes, not less. Bouncy Castle usually follows the Sun/Oracle providers for the sake of compatibilty, although you...
Does this use 256-bit AES encryption?
Your example appears to use a 32-byte key and a 256 bit version of the AES cryptosystem. So, technically yes it is 256-bit AES encryption. The actual size of the message determines the resulting output but it should be larger then the original message. Also, you should be able to...
Why is a SecretKeySpec needed when deriving a key from a password in Java?
java,cryptography,jce,secret-key
Every SecretKey has an associated algorithm name. You cannot use a SecretKey with algorithm "DES" in a context where an AES key is needed, for example. In your code, the following line produces a SecretKey: SecretKey secretKey = factory.generateSecret(spec); However, at this point the key is not an AES key....
Exception while file signing using HSM and SUNPKCS11
We also encountered the same issue. Specify the provider name when getting the Signing instance. When code to sign using HSM is called, there may some other piece of code in your application adding another provider [Security.insertProvider] which implements the same signing algorithm. When your sign, you pass a parameter...
Issue with Decryption of text file in JCE
You are closing your FileOutputStream before you close your CipherOutputStream. This prevents the latter from completing its work and writing the encrypted data to disk. bos.close(); encryptedBos.close(); should change to: encryptedBos.close(); bos.close(); ...
(1)Convert the ECDSA private & public key, (2)Verification by ECDSA
java,cryptography,digital-signature,jce,ecdsa
You're asking a lot of different questions about dealing with ECDSA. I will address your first question about database storage here. I recommend you do some additional research on the mechanics of ECDSA if you want to learn about how to properly use it. Examples given here would be hard...
Provider-independent crypto in Java?
I think you are adding the static registration into the wrong file. Use security.policy instead of java.policy within the same folder. See: https://www.bouncycastle.org/wiki/display/JA1/Provider+Installation...
Jsch not working with certain sftp servers
If you are using Java 8, then this might be caused by a bug in Java JCE that has recently been fixed. Upgrading to Java SE 8u45 (or higher) solves the issue. I verified that with 1.8.0_45, jsch-0.1.53 is actually able to successfully negotiate an SSH session with a server...
Java 1.7 + JSCH: java.security.InvalidKeyException: Key is too long for this algorithm
We ended up swapping JSCH out for SSHJ. It depends on the BouncyCastle crypto libraries rather than on Java's built-in crypto packages, and is capable of connecting to our server with no problems.
PDFbox Exception - Exception in thread “main” java.lang.VerifyError
java,apache,bouncycastle,pdfbox,jce
Use version 1.44 of the Bouncy Castle libs, as mentioned here: https://pdfbox.apache.org/dependencies.html The Bouncy Castle libs are often not backwards compatible, that is why....