Check encryption key correctness in JAVA

Question

I'm using BouncyCastle to encrypt/decrypt some files using AES and PKCS5 padding in CBC mode :

Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding", "BC");

Now two questions:

• How can I check that the provided key for decrypting data is correct or not ?
• How Can I check encrypted input is untouched (e.g. not changed by user using an HEX editor)?

Thanks

Answer 1

Take a look at this tutorial on BC encryption, specifically the InitCiphers methods, and in detail at the second code block which specifies the actual type of cipher.

How can I check that the provided key for decrypting data is correct or not?

According to JCE Javadocs, specifically the constructor of Class SecretKeySpec:

This constructor does not check if the given bytes indeed specify a secret key of the specified algorithm. For example, if the algorithm is DES, this constructor does not check if key is 8 bytes long, and also does not check for weak or semi-weak keys. In order for those checks to be performed, an algorithm-specific key specification class (in this case: DESKeySpec) should be used.

Note that Interface KeySpec lists all implementing classes, basically a list of validation options.

How Can I check encrypted input is untouched (e.g. not changed by user using an HEX editor)?

Indeed. That's a good one. 'Input' is pretty generic. Do you mean the actual content to decrypt? Well, if it's munged I believe it will not decrypt properly. Does that make sense?

IFF you are talking about the case of a key with parity bits being altered, as described in item (6) at the Bouncy Castle FAQ, you will have to do an actual parity check on the key. Only the first 56 bytes of the key are used for the encryption ops, and the last 8 bytes are reserved for parity checking. So, essentially, the last part of the 'key' can be changed and the first part is still useful. To detect whether either the parity or the key have been altered, you would run a parity check. I found this little ditty on doing a parity check. And, for more info on how parity is set in these keys, see comments in the JDK7 Crypto Provider source for Class DESKeyGenerator by Jan Luehe (near bottom) which discuss parity setting.

I recently had some interaction with BC, and I hope this info helps.

Answer 2

The JCE ciphers are usually very basic. If you need a full featured protection including integrity and key testing, you need to combine them. And as usual it is better to not device that yourself. So better opt for a more high level format like PKCS7/12 or PGP.

Depending on the Padding used some ciphers will give you a PaddingException when you try to decrypt it with the wrong key. For stronger integrity check I would use a padding consiting of HMAC bytes.

A pretty complete method is included in the JCE, it is the AESWrap algorithm. It requires padded data but will ensure integrity. It is best combined with a length byte as described in RFC 3537. Note, that this is only intended for smaller amounts of secrets (like symmetric keys). The RFC3537 padding is restricted to 255 bytes.

To use this with a password derived key, you can use this:

char[] pass = ... // your password
byte[] codeBytes = ... // up to 255 bytes you want to protect

// generate wrapping key from password
SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
SecureRandom rand = SecureRandom.getInstance("SHA1PRNG");
byte[] salt = new byte[16]; rand.nextBytes(salt);
SecretKey kek = f.generateSecret(new PBEKeySpec(pass, salt, 1000, 128));
kek = new SecretKeySpec(password.getEncoded(), "AES"); // convert into AES

// RFC3537 padding (lengthbyte)
byte[] wrappedCodeBytes = new byte[codeBytes + 1 % 8];
System.arraycopy(codeBytes,0,wrappedCodeBytes,1,wrappedCodeBytes.length);
paddedCodeBytes[0]=(byte)codeBytes.length;
byte[] pad = new byte[paddedCodeBytes.length - codeBytes.length -1]; rand.nextBytes(pad);
System.arraycopy(pad,0,paddedCodeBytes,codeBytes.length+1,pad.length);
// AESWrap is WRAP_MODE:needs a SecretKey 
SecretKey paddedCodeKey = new SecretKeySpec(paddedCodeBytes, "RAW");

// now wrap the password with AESWrap kek is 128 bit
Cipher c = Cipher.getInstance("AESWrap"); // default IV
c.init(Cipher.WRAP_MODE, kek);
byte[] result = c.warp(paddedCodeKey);

The unwrapping is left for the reader as an exercise :) The example code uses 128bit keysize, since more entropy cant be expected from the PBKDF2 anyway.

Note that this will detect wrong passwords with high probability, and some critics will see this as a weakness of AESWrap.

Answer 3

You can use an AEAD mode, like CCM or GCM, in place of CBC. These modes authenticate an encrypted message, so if the wrong key is used, or the cipher text has been altered, you can detect it. You wouldn't be able to distinguish these cases though.

There is support in Java 7's cryptography API for GCM, but the SunJCE provider that ships with Oracle's Java implementation doesn't support it yet. You can get support through third-party providers like BouncyCastle.

You can achieve the same things if you use additional cryptographic services, like a digital signature or message authentication code.

Answer 4

You should add a MAC which first verifies the integrity of the message, and only then you should decrypt it. A common choice of MAC is HMAC with whatever hash function you prefer, such as SHA-2.

Instead of doing this yourself, it's often a good idea to use an authenticated cipher. AES-GCM is a common choice. But you need to be really careful to never reuse an IV in that case.

Answer 5

Encryption is not just about the algorithm and the encryption key, it's also a lot about the system organization.

In general, you can't determine that the key is correct. Any key can be used to decrypt the data that's supposed to be decrypted, but it's up to some other mechanism to tell you if that is the "correct" result.

In general, you can't determine if the data to be decrypted is untouched, except through some external check. It's a property of most encryption systems that changing any of the encrypted data would change the decrypted output drastically, probably into something you'd interpret as garbage.