Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
| От | Ryan Lambert |
|---|---|
| Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
| Дата | |
| Msg-id | CAN-V+g-6bduh7mYG1x29r0qNY=9p2mWsQf6EvRheDL+LMOzP8w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Список | pgsql-hackers |
As I understand, the reason we
want to avoid using the same IV for too many pages is to dodge a
cryptanalysis attack, which requires a large amount of data encrypted
with the same key/IV in order to be effective. But if we have two
copies of the same page encrypted with the same key/IV, yes it's twice
as much data as just one copy of the page with that key/IV, but it still
seems like a sufficiently low amount of data that cryptanalysis is
unfeasible. Right? I mean, webservers send hundreds of kilobytes
encrypted with the same key; they avoid sending megabytes of it with the
same key/IV, but getting too worked up about 16 kB when we think 8 kB is
fine seems over the top.
So I guess the question is how much data is considered sufficient for a
successful, practical cryptanalysis attack?
Yes, a cryptanalysis attack could hypothetically derive critical info about the key from two encrypted blocks with the same IV.
A major (very important) difference with web servers is they use asymmetric encryption with the client to negotiate and share the secure symmetric encryption key for that session. The vast majority of the encryption work is done w/ short lived symmetric keys, not the TLS keys we all think of (because that's what we configure). Many DB encryption keys (symmetric) will live for a number of years, so the attack vectors and timelines are far different. By contrast, the longest CA TLS keys through paid vendors are typically 2 years, most are 1, LetsEncrypt certs only live 3 months.
Another (probably bad) idea is if there was a REENCRYPT DATABASE, the hyper-paranoid could force a full rewrite as often as they want. Large databases seem to be the ones that are most likely to have long living pages, and the least likely to want to wait to reencrypt the whole thing.
Ryan Lambert
В списке pgsql-hackers по дате отправления: