cancel
Showing results for 
Search instead for 
Did you mean: 

How do I convert a long binary (from ENCRYPT) to a url encoded value?

Former Member
4,085

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.

Accepted Solutions (1)

Accepted Solutions (1)

MarkCulp
Participant

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

Former Member
0 Kudos

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.

MarkCulp
Participant
0 Kudos

Regarding the 16 bytes, just cut them off like this:

set @url_part = base64_encode( byte_substr( encrypt( @src, @key ), 17 ) );

graeme_perrow
Advisor
Advisor

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.

VolkerBarth
Contributor
0 Kudos

...using a salt is of course the right thing to do, I would claim with my - limited - knowledge of security issues...

That means the encrypted value can only be decrypted with the DECRYPT() function, i.e. within SQL Anywhere, correct?

MarkCulp
Participant
0 Kudos

Ah yes, I forgot about the salt!

Former Member
0 Kudos

Thanks for this info everyone. I am even more confident in our use of encrypt/decrypt in some key places in our apps, but now realize this won't solve my compatability issue here.

VolkerBarth
Contributor
0 Kudos

Answers (0)