I am using ECC algorithm for security. Now the concern is I am placing the data in web page after encryption of the data in hex format and transmit to server and then it decrypts the data, but when I encrypt the data then at that time then the method returns me the byte [] and then I will have to convert that byte [] into Base64 byte [], if I am not doing this thing then it gives me error of bad padding while decrypting the data. so my conern is why I need to convert that byte [] data into Base64 byte [] data ?
|
|
|||
|
|
|
It sounds like you are using cryptography improperly. There is no reason to store encrypted data within an html page. Further more ECC and another asymmetric algorithms are very resource intensive. A symmetric cipher should be used with a mode that has authentication. But most importantly. Why aren't you using HTTPS? |
|||||||||||||||||
|
|
If you don't want the user to touch something simply use session variables.(Ex. $_SESSION) If you want to protect the end user get a nice certificate and deliver only trough HTTPS. |
|||
|
|
|
I'm going to have to agree with Rook, and say whatever you're doing, you're doing it wrong. To answer your question, the reason you have to convert binary data into a base64 encoded string is that binary data cannot be reliably encoded into a text-only document (like HTML) without doing some convert-to-text transformation on it, the most popular of which is base64 encoding. I won't get into details, but there a a number of things that have to do with character sets and stuff. Other transforms exist (hexadecimal output, for example) but base64 is probably the simplest way to go. That said, you probably shouldn't do whatever you're doing. If you need to transmit data to the client securely, then use SSL/TLS/HTTPS. Otherwise, you're not doing it securely. If you need to store data client-side which the client won't read, then just don't. Store the data on your server and provide the client with a session key that references the server storage location. Otherwise, you're not doing it securely. Really. |
|||
|
|