Horton

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Ryan Lambert <ryan@rustprooflabs.com>

View thread
From: Ryan Lambert <ryan@rustprooflabs.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Joe Conway <mail@joeconway.com>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Antonin Houska <ah@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-09T12:39:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

Hi Thomas,

> CBC mode does require
> random nonces, other modes may be fine with even sequences as long as
> the values are not reused.

I disagree that CBC mode requires random nonces, at least based on what
NIST has published.  They only require that the IV (not the nonce) must be
unpredictable per [1]:

" For the CBC and CFB modes, the IVs must be unpredictable."

The unpredictable IV can be generated from a non-random nonce including a
counter:

"There are two recommended methods for generating unpredictable IVs. The
first method is to apply the forward cipher function, under the same key
that is used for the encryption of the plaintext, to a nonce. The nonce
must be a data block that is unique to each execution of the encryption
operation. For example, the nonce may be a counter, as described in
Appendix B, or a message number."

[1]
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf

Thanks,
Ryan Lambert


>