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

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

Are there any metrics on how long a page can live without being modified in
one way or another to trigger it to re-encrypt with a new IV? Is it
possible that a single page could live essentially forever without being
modified? If its the latter than I would opt on the side of paranoid due
to the expected lifecycle of keys. If it's the former it probably merits
further discussion on the paranoia requirements. Another consideration is
if someone can get this data and there are a LOT of pages sharing IVs the
exposure increases significantly, probably not linearly.

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

>