It's not a secret anymore!
The moose likes Security and the fly likes Encrypting a shared key on the Java platform Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Encrypting a shared key on the Java platform" Watch "Encrypting a shared key on the Java platform" New topic

Encrypting a shared key on the Java platform

Raghvendra Pratap Singh

Joined: Jul 26, 2012
Posts: 22

I need to call a webservice which requires me to encrypt a parameter before calling it. I have received a specification which reads:

"We use AES to encrypt. Settings for the encryption follow:

Key: PublicKey12345678910

Number of bits: 128

Padding: PKCS #7

Cipher: Cipher Block Chaining (CBC)"

Now, my problem is probably a lack of basic understanding of the encryption process. I have my public key, but what do I do with it? I have tried to find an answer online but all my efforts seem to result in either the wrong encrypted key or very often an "InvalidKeyLengthException, key not 128, 196 or 256 bits" (or something in that general direction). My most recent effort, which borrows heavily from an answer here on stack, looks like this:

Could someone explain to me in which order to do the things in the supplied specification? Also, any code implementing this behavior on the Java platform would also be much obliged.

Thanks and Regards, Raghvendra Pratap Singh
"Quality means doing it right when no one is looking"
Richard Tookey

Joined: Aug 27, 2012
Posts: 1166

You need to go back to whoever specified the encryption method and ask them -

1) How do they convert " PublicKey12345678910 " to the AES 128 bit key? Nothing is the specification says use PBE - especially not with the DES assumption!
2) What IV (initialization vector) do they use? You are trying to get the IV from the PBE process but that may or may not be what is needed.
3) How do they convert the raw ciphertext to a form suitable for shipping as a parameter? One should never ever ever use a String object as a container for binary data and the ciphertext is most definitely binary data. One normally needs to encode it using something like Hex or Base64 or ASCII85.
4) What character encoding should be used when converting the input String to bytes prior to encryption? You currently use your platform default encoding but when recovering the cleartext at the other end the same encoding must be use and your default may not be the same as the encoding they use.

Without the first two bits of information you could spend the next 5 years and still not get it right..

Notes :-
i) - there is no need to use BouncyCastle provider. You can just use the default provider since it includes AES.
ii) -for this work PKCS7 padding is equivalent to PKCS5 padding so you should be using

I'm betting the sevice uses the .NET libraries. You should try to get a copy of their code.

Finally - I hope that is not the real key! If it is then it was very very poor in the first place and it is now compromised!
Pat Farrell

Joined: Aug 11, 2007
Posts: 4659

Richard Tookey wrote:1) How do they convert "PublicKey12345678910 " to the AES 128 bit key? Nothing is the specification says use PBE - especially not with the DES assumption!

Most implementations don't approach it this way. RSA is really slow, so the standard implementation uses RSA to encipher a randomly generated AES key. The AES key is used to encipher the main text, and RSA is only used for the key. Then at the receiving end, they use their matching RSA private key to decipher the block containing the AES key and then use the AES key for the rest of the message. AES is many times faster than RSA, often tens of thousands of times faster.

@Richard is correct in that the IV is a critical part of the message. By most protocols, the IV can be sent in the clear. A few protocols put the IV in with the AES key in the RSA enciphered block. Without the proper IV, its impossible to decipher the message.

Most good libraries will handle these steps internally, so you don't have to worry about them too much, but you have pass in the proper arguments. How the arguments are transmitted between the users (usually named Alice and Bob in all the examples) is critical, and that is application design specific, not defined by the crypto library

I agree. Here's the link:
subject: Encrypting a shared key on the Java platform
It's not a secret anymore!