Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
| От | Jonathan S. Katz |
|---|---|
| Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
| Дата | |
| Msg-id | d1bec239-e458-8317-20a9-376d42f4435a@postgresql.org обсуждение исходный текст |
| Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) ("Jonathan S. Katz" <jkatz@postgresql.org>) |
| Список | pgsql-hackers |
>>>> Buffer Encryption >>>> ============== >>>> We will use AES-CBC for buffer encryption. We will add key id (4byte) >>> >>> I think we might want to use CTR for this, and will post after this. > > Not sure if I missed this post or not (as several people mentioned, it > is easy to get lost in this thread). > > I think what will help drive this decision is whether or not we consider > the data we are storing on disk as a "file system" in itself. Trying to > make myself literate in disk encryption theory[1], it seems a big > weakness in using CTR mode for encryption is we need to be able to > guarantee a fresh counter for every page we encrypt[2], so if we can > guarantee the uniqueness of IV per TDEK, this is on the table. > > XTS mode, on the other hand, appears to be more durable to reusing an IV > as the "tweak" was designed to represent a disk sector, though there are > still problems. However, I presume this is one of many reasons why > fscrypt uses XTS[3]. Much like Joe earlier, I forgot my citations: [1] https://en.wikipedia.org/wiki/Disk_encryption_theory [2] https://crypto.stackexchange.com/questions/14628/why-do-we-use-xts-over-ctr-for-disk-encryption [3] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html Jonathan
Вложения
В списке pgsql-hackers по дате отправления: