on 2011 Sep 25 6:58 PM
I need to AES encrypt a parameter value for an existing POST method. We currently create the entire html by STRINGing together the content in a Stored Proc and pass it back to the front end app for execution. (SQLA 11.0.1).
The AES encryption looks simple since SQLA already has that function. But how to create a url-friendly string with the necessary % encoding? In my good-ole-mainframe days, I would have indexed thru the bytes of the binary value and substituted the necessary encoding. But I don't have a clue how to handle this.
You could just use http_encode() directly but I typically use base64_encode() first to make the binary string a bit more palatable for using in an URL. The one drawback to using base64_encode is that it expands the length of the string by 1/3 (i.e. every three bytes gets converted to 4 ascii characters)... but this may actually be better than directly using http_encode() on the binary string since every non-"nice" byte will be expanded to three bytes (%xy) by http_encode - so depending on what bytes are actually in your binary value base64_encode could be better.
If you are going to use SQL Anywhere's encrypt() function to encrypt the value then you may need to know that SA prepends 16 bytes to the encrypted string... so if you are going to unencrypt the value outside of SA (in your front end) then you will need to strip the first 16 bytes before unencrypting it.
FWIW: If you are concerned about securing this parameter between the server and the backend then perhaps you should look at using HTTPS?
HTH
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for feeding my thinking Mark.
Seeing http_encode took a string argument, and encrypt producing a long binary, lead me to believe that wasn't going to work for me. I just tried it and see I do get some results.
But... the extra 16 bytes is a problem because it is being used outside of SQLA.
We are using https, but we are launching IE by passing the url with confidential parameters which occasioned the need to encrypt those values.
I'm afraid this will not work. The encryption is salted with a random number which we get from the 16-byte header. Without the header, you can't get the salt. Without the salt, you can't decrypt the data.
See my previous product suggestion...
User | Count |
---|---|
71 | |
11 | |
10 | |
10 | |
10 | |
8 | |
7 | |
7 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.