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

On 7/10/19 4:24 AM, Antonin Houska wrote:
> Joe Conway <mail(at)joeconway(dot)com> wrote:
>
>> On 7/8/19 6:04 PM, Stephen Frost wrote:
>> > * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>> >> Uh, well, renaming the user was a big problem, but that is the only case
>> >> I can think of. I don't see that as an issue for block or WAL sequence
>> >> numbers. If we want to use a different nonce, we have to find a way to
>> >> store it or look it up efficiently. Considering the nonce size, I don't
>> >> see how that is possible.
>> >
>> > No, this also meant that, as an attacker, I *knew* the salt ahead of
>> > time and therefore could build rainbow tables specifically for that
>> > salt. I could also use those *same* tables for any system where that
>> > user had an account, even if they used different passwords on different
>> > systems...
>> >
>> > I appreciate that *some* of this might not be completely relevant for
>> > the way a nonce is used in cryptography, but I'd be very surprised to
>> > have a cryptographer tell me that a deterministic nonce didn't have
>> > similar issues or didn't reduce the value of the nonce significantly.
>>
>> I have worked side by side on projects with bona fide cryptographers and
>> I can assure you that they recommended random nonces. Granted, that was
>> in the early 2000s, but I don't think "modern cryptography" has changed
>> that any more than "web scale" has made Postgres irrelevant in the
>> intervening years.
>
> I think that particular threads have to be considered.
>
>> Related links:
>
>> https://defuse.ca/cbcmodeiv.htm
>> https://www.cryptofails.com/post/70059609995/crypto-noobs-1-initialization-vectors
>
> The first one looks more in-depth than the other one, so I focused on it:
>
> * "Statistical Correlations between IV and Plaintext"
>
> My understanding is that predictability of the IV (in our implementation of
> full-instance encryption [1] we derive the IV from RelFileNode combined with
> block number) can reveal information about the first encryption block (16
> bytes) of the page, i.e. part of the PageHeaderData structure. I don't think
> this leaks any valuable data. And starting the 2nd block, the IV is not
> predictable because it is cipher text of the previous block.
>
> * "Chosen-Plaintext Attacks"
>
> The question here is whether we expect the OS admin to have access to the
> database. In [1] we currently don't (cloud, where DBA has no control over the
> storage layer is the main use case), but if it appears to be the requirement,
> I believe CBC-ESSIV mode [2] can fix the problem.
>
> Anyway, I'm not sure if this kind of attack can reveal more information than
> something about the first block of the page (the page header), since each of
> the following blocks uses ciphertext of the previous block as the IV.
>
> * "Altering the IV Before Decryption"
>
> I don't think this attack needs special attention - page checksums should
> reveal it.
>
>
> [1] https://commitfest.postgresql.org/23/2104/
> [2] https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_.28ESSIV.29
>

Please see my other reply (and
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
appendix C as pointed out by Ryan downthread).

At least in my mind, I trust a published specification from the
nation-state level over random blogs or wikipedia. If we can find some
equivalent published standards that contradict NIST we should discuss
it, but for my money I would prefer to stick with the NIST recommended
method to produce the IVs.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development