Please be aware that the SAP SQL Anywhere Forum will be shut down on August 29th, 2024 when all it's content will be migrated to the SAP Community.

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 13 Sep '11, 08:54

Sergio's gravatar image

accept rate: 0%

edited 22 Sep '11, 13:07

Volker%20Barth's gravatar image

Volker Barth

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.

permanent link

answered 13 Sep '11, 09:30

Graeme%20Perrow's gravatar image

Graeme Perrow
accept rate: 54%

"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:(

(13 Sep '11, 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.

(13 Sep '11, 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:)

(13 Sep '11, 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 (

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

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.

(22 Sep '11, 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.

permanent link

answered 22 Sep '11, 05:51

Volker%20Barth's gravatar image

Volker Barth
accept rate: 34%

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

permanent link

answered 13 Sep '11, 09:31

Volker%20Barth's gravatar image

Volker Barth
accept rate: 34%

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

(14 Sep '11, 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 ;-)

permanent link

answered 14 Sep '11, 05:14

Martin's gravatar image

accept rate: 14%

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]( "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: 13 Sep '11, 08:54

question was seen: 5,775 times

last updated: 22 Sep '11, 13:07