In order to post questions, answers, or comments, you now need a validated email address. Details on how to validate your address are in the FAQ.

Can anyone provide me with a better explanation of what simple encryption means in SQL Anywhere? The manual states that simple encryption is equivalent to "obfuscation", which leaves me just as unknowing as before. In practice, how easy would it be to deobfuscate a SQL Anywhere 10 db. If its easily done, we may need to move our databases to a strong encryption.

asked Sep 13 '11 at 08:54

Sergio's gravatar image

Sergio
460141820

edited Sep 22 '11 at 13:07

Volker%20Barth's gravatar image

Volker Barth
22.2k220331480


I can't give you any details on the algorithm other than to say that there is no external key necessary - everything that is required to decrypt the data is already there in the database, which means that it's not strong encryption. There's no way to quantify how easy it would be to deobfuscate such a database. All we generally say is that a determined hacker that has some knowledge of cryptography could probably break it if they tried. I can't tell you whether this would take them five minutes or six weeks.

If you have any security concerns at all, then you may as well switch to strong encryption. Modern computers have enough RAM and processor power that the overhead of encrypting and decrypting pages is negligible, so the only drawback to using strong encryption is key management.

answered Sep 13 '11 at 09:30

Graeme%20Perrow's gravatar image

Graeme Perrow
7.0k36194

"Key management" - that's the point IMHO: Who's gonna enter/supply the DBKEY when the strong encrypted database is started?

Is there a part-time DBA to enter the DBKEY? Or are users to supply both a DBKEY and their credentials? (And how good will a DBKEY they are able to enter?)

Or will the DBKEY be supplied by the application (and how is it stored then)?

Some questions whose answers are sometimes hard to decipher, as well:(

(Sep 13 '11 at 09:42) Volker Barth
Replies hidden

Sorry, I didn't mean to imply that key management is a simple problem. It is certainly non-trivial and there are a number of implications - if you get it wrong, it can be the equivalent to writing your safe combination on a post-it note and sticking it to the safe. I was just trying to say that if you're worried about all your queries being 20% slower because of encryption, that's likely not going to be an issue.

(Sep 13 '11 at 09:49) Graeme Perrow

@Graeme: No need to be sorry, I did not misunderstand you. And I fully agree with your reasoning, both w.r.t. performance and key management.

The one advantage of simple "encryption" is that it's so simple to use:)

(Sep 13 '11 at 10:06) Volker Barth

Thanks for the answer. Basically, i need to know if a sybase db with simple encryption satisfies the requirements of the Health Insurance Portability and Accountability Act wrt health data protection, in case the db file is stolen or lost. Specifically, there is this document: NIST SP 800-66, An Introductory Resource Guide for Implementing the (HIPAA) Security Rule (http://csrc.nist.gov/publications/nistpubs/).

(Sep 22 '11 at 04:55) Sergio
Replies hidden
3

I don't think the document you mention specifies particular requirements -it seems about how to go about assessing whether a particular process meets the test of having taken necessary precautions - so it's a matter of opinion, which will include an assessment of the level and nature of the threat etc. However, if you look at some of the draft proposals now under consideration, they discuss very high levels of cryptographic security (which I would have thought) are very unlikely to be met by the simple encryption method.

If I was setting out to apply security to such a project, I would certainly take the strongest approach I reasonably could at this stage, if only to avoid having to change it later.

(Sep 22 '11 at 05:36) Justin Willey

With simple encryption, to access a stolen database you "only" need to have working credentials - so you would be relying on their secretness. One might also be able to

  1. decipher the database file (as it's just obfuscated, cf. Graeme's evaluation) or
  2. load the database file on a database engine without connecting - in case cache warming is activated, I would think one could access some "un-obfuscated" database pages from memory or
  3. let DBTRAN run against the (not loaded) transaction log to read SQL statements.

Well, I've just done the third (on own databases, yes), but I'm sure there are enough folks who are willing and able to succeed with points 1 or 2, if your data seems worthwhile.

In contrast, with a strongly encrypted file (and a secure DBKEY), the first method should be too difficult, and the second and third do not work at all - you can't load a strongly encrypted database (nor translate a log) without spcifying the DBKEY.

answered Sep 22 '11 at 05:51

Volker%20Barth's gravatar image

Volker Barth
22.2k220331480

AFAIK, simple encryption means the database (or configuration file, cf. DBFHIDE) is encrypted with a built-in key, so the SQL Anywhere software can encrpyt and decrypt data without the need of a separate key.

I can't tell how hard it is to decrypt such data yourself (or to re-engineer the built-in key) but it's obviously different from strong encryption.

At least, I'm quite sure it has not written down in a book as other, so-called secure keys...

answered Sep 13 '11 at 09:31

Volker%20Barth's gravatar image

Volker Barth
22.2k220331480

I don't think it is a hardcoded key, I guess it is just a simple algorithm like XOR the data or use ROT13.

(Sep 14 '11 at 05:16) Martin

If you just want to prevent some Script Kiddies or normal users from reading your data you are ok with simple encryption. If you are afraid, that knowledgeable hackers are able to decrypt your credit card infos from the database, then switch to strong encryption.

By the way, if you work for Sony Playstation Network I would also recommend strong encrpytion ;-)

answered Sep 14 '11 at 05:14

Martin's gravatar image

Martin
7.7k84122206

Your answer
toggle preview

Are you providing an answer to the original question, or making a comment on the question or an answer? If you are making a comment please do not post a new answer. Click "Add new comment" on the question or answer instead. If you are responding to a previous comment, click on the "reply" icon (    ) for that comment.

Follow this question

By Email:

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

By RSS:

Answers

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 (indent for sublists):
    1. Foo
    2. Bar
  • bullet list (indent for sublists):
    * Foo
    * Bar
  • to add a line break, add two spaces to where you would like the new line to be.
  • Code blocks should be indented by 4 spaces. SQL code should begin with ":::SQL" on the first line.
  • basic HTML tags are also supported

Tags:

×34
×25

Asked: Sep 13 '11 at 08:54

Seen: 1,379 times

Last updated: Sep 22 '11 at 13:07

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link: [text](http://url.com/ "title")
  • image: ![alt text](/path/img.jpg "title")
  • numbered list (indent for sublists):
    1. Foo
    2. Bar
  • bullet list (indent for sublists):
    * Foo
    * Bar
  • to add a line break, add two spaces to where you would like the new line to be.
  • Code blocks should be indented by 4 spaces. SQL code should begin with ":::SQL" on the first line.
  • basic HTML tags are also supported