From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Ryan Lambert <ryan(at)rustprooflabs(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Joe Conway <mail(at)joeconway(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Date: | 2019-07-09 14:51:22 |
Message-ID: | 20190709145122.okewkmezew73qg5g@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 8, 2019 at 09:57:57PM -0600, Ryan Lambert wrote:
> Hey everyone,
>
> Here is my input regarding nonces and randomness.
>
> > As I understand it, the NIST recommendation is a 96-bit *random* nonce,
>
> I could not find that exact requirement in the NIST documents, though given the
> volume of that library it would be possible to miss. The recommendation I
> repeatedly saw for the nonce was unique. There is also an important
> distinction that the nonce is not the Initialization Vector (IV), it can be
> used as part of the IV, more on that later.
>
> The most succinct definition for nonce I found was in SP-800-38A [1] page 4:
> "A value that is only used once."
> SP-800-90A [2] (page 6) expands on the definition: "A time-varying value that
> has at most a negligible chance of repeating, e.g., a random value that is
> generated anew for each use, a timestamp, a sequence number, or some
> combination of these."
>
> The second definition references randomness but does not require it. [1] (pg
> 19) reinforces the importance of uniqueness: "A procedure should be
> established to ensure the uniqueness of the message nonces"
Yes, that is what I remembered but the URL I referenced stated
randomness is preferred. I was hopeful that whatever was preferring
randomness was trying to avoid a problem we didn't have.
> Further, knowing the nonce gets you nowhere, it isn't the salt until it is ran
> through the forward cipher with the encryption key. Even with the nonce the
> attacker has doesn't know the salt unless they steal the key, and that's a
> bigger problem.
Yes, I had forgotten about that step --- good point, meaning that the
nonce for block zero is different for every encryption key.
> The strictest definition of nonce I found was in [2] (pg 19) defining nonces to
> use in the process of random generation:
>
> "The nonce shall be either:
> a. A value with at least (security_strength/2) bits of entropy, or
> b. A value that is expected to repeat no more often than a (security_strength/
> 2)-bit random
> string would be expected to repeat."
>
> Even there it is randomness (a) or uniqueness (b).
Thanks, this was very helpful.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-07-09 14:52:21 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Paul Guo | 2019-07-09 14:48:49 | Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) |