I've used old-existing code in our project to encrypt and decrypt over http (encrypted value is being sent as a request parameter)
Then, I came to know that we are not supposed to use 'sun.misc.BASE64Encoder'. In addition, the whole operation failed due to encoding/decoding stuff by browser/container.
Please let me know, if there is any API that gives us standard encryption/decryption stuff which can be used over web, and with out being worried about 'encoding'. [which means no +, etc.. characters in the result of encrypted value]
1) Please don't rush, I used both encryption and encoding in my post
2) My encrypted values were damaged when sent as request parameters due to the presence of '+' symbol in encrypted value.
URLEncoder and URLDecoder can be used to encode / decode (better terms than encrypting / decrypting) values for use in URLs. URLEncoder will turn spaces into +, and do all other necessary escaping like %2B instead of a +. URLDecoder will do it the other way around.
I am afraid, you've got it wrong. I was referring to Encryption and decryption to exchange sensitive values from server to user, and vice versa as request parameters.
The problem I've got is- when I use 'sun.misc.BASE64Encoder', I get an encrypted value something like ' uD2+reYclBs=' which contains + symbol and it needs to be encoded while I exchange it from the user. It's becoming a bit complex, and also, I should not be using sun.xyz classes.
So, I am wondering whether there is any other API which follows web-standards, so that the encrypted values will not be damaged by container. (I was a victim of - replacing + symbol by space by container)
Looks like you need a combination of encryption* and encoding / decoding. So first you encrypt*, then you encode that. At the other end, first you decode, then you decrypt.
* 1) you can use Apache Commons Codec for a different base64 encoder / decoder, and 2) base64 is actually very bad encryption. The algorithm is well known, and it does not involve any keys or secrets. Anyone who can monitor your traffic can easily "decrypt" the data.
- Yeah, I need a combination of encryption and encoding, and thread going on - Here
- If am correct, the container is damaging the encrypted value received (in the form of request param), since there is a clash between standards. (usage of + sign in 'encrypted value' where it should be used during encoding).
- So, I think it's better to make sure that is there any encryption technique which complies with the standards of web-containers so that they won't damage the same.
You don't need to worry about other people decoding your message. It's still encrypted.
The sending part involves 3 steps:
- encrypting the data.
- converting the encrypted data into base64.
- encoding the base64 data so it can be sent.
The receiving part involves the inverted steps:
- decoding the request data back into base64; anyone can do this.
- convert the base64 back into the encrypted data; anyone can do this.
- decrypting the encrypted data; and this is where your security lies. They need your key(s) to be able to decrypt the data. Unless they break your encryption, but that should be quite hard if you don't choose a too weak encryption algorithm.
Let them get the encrypted data for all you care. They can't do much with it.
Thank you very much Rob, Now, everything is clear.
A bit digressed question.
-> I am just wondering which 'encoding' technique is used for jsessionid. It contains only alphabetics and numbers, but no special characters. That (similar) kind seems to be a perfect match for my situation which results in no special character presence.