|
We have a SQLA 17.0.04.2100 database that is currently running whole database AES128 encryption, as AES256 encryption was not available in SQLA10 and we did not change this setting to AES256 when upgrading (via mandatory reload) from SQLA10 to SQLA17. Therefore, as the title says, are there any significant performance implications to be aware of if we now reload the database specifying AES256? I assume that the main performance hit for encryption was going from no encryption to AES128 in the first place? Does AES256 have any additional overhead that is likely to noticeably affect performance over AES128? Please note that we only have very small test databases, so we are unable to test this fully without trying it on an actual customer database that can by many GB in size. Basically, is there anything we should be aware of in advance of approaching a customer to do this? |
|
I'm afraid I have no performance data w.r.t AES256 vs. AES128. We've never done any such testing so I can't answer that question. However, the question that came up in the comments about the cache being encrypted - cache pages in memory are not encrypted but cache pages written to the temporary file are encrypted. So basically disk I/O is encrypted/decrypted, protecting file access, correct?
(05 Sep '17, 12:48)
Volker Barth
Replies hidden
That is correct.
(05 Sep '17, 13:02)
Graeme Perrow
|
I don't know the answer :)
According to different benchmarks AES 256 is not significantly slower than AES 128. I assume SA devs haven't implemented the encryption algorithm, but deligated this task to OpenSSL (or whatever library being used in SA17).
I guess when people turn on the stronger encryption algoritm, they know that there are performance penalties.
Probably for every single disk operation (read/write). If the data in server cache is also encrypted, then the SQL statements should become slower as well.
I'd better tell: if you can identify performance issues, somebody should start analyzing it (read execution plans, for instance). If you want to know how slow will the DB be after the stronger encryption is applied, I would say - it depends.
Can't tell on AES128 vs. AES256, but here are two hints:
This older FAQ with a rule-of-thumb guideline by Sybase, related to SQL Anywhere 10 and AES128 - I guess the according whitepaper is no longer available, at least I could not find it in SAP land...
The property "IsAesniAvailable" might tell whether the according encryption is supported by the CPU.
Of course, as Vlad has told, some tests with your data set and usual workload will tell about your situation:)
I am still wondering, whether SA encrypts its cache, or not.
I don't know for sure, but note the following statement, taken from the doc topic "Tip: Use the cache to improve performance":
and from "Performance issues when using encryption":
So I would guess the answer is no.
Ok, thank you Volker. I appreciate your help.
I was simply thinking about the potential security misses. E.g. if the cache is not encrypted, it is possible to dump the process and read something from it.