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.

asked 25 Sep '11, 17:58

Bill%20Aumen's gravatar image

Bill Aumen
accept rate: 16%

edited 27 Sep '11, 07:09

Volker%20Barth's gravatar image

Volker Barth

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?


permanent link

answered 25 Sep '11, 22:06

Mark%20Culp's gravatar image

Mark Culp
accept rate: 40%

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.

(26 Sep '11, 19:30) Bill Aumen
Replies hidden

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

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

(27 Sep '11, 03:57) Mark Culp

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.

(27 Sep '11, 06:02) Graeme Perrow

...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?

(27 Sep '11, 06:39) Volker Barth

Ah yes, I forgot about the salt!

(27 Sep '11, 08:33) Mark Culp

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.

(27 Sep '11, 10:51) Bill Aumen
Replies hidden
(27 Sep '11, 11:28) Volker Barth
showing 2 of 7 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 25 Sep '11, 17:58

question was seen: 1,928 times

last updated: 27 Sep '11, 11:28