On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote:
On 7/8/19 6:04 PM, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.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.
Related links:
https://defuse.ca/cbcmodeiv.htm
https://www.cryptofails.com/post/70059609995/crypto-noobs-1-initialization-vectors
AFAIK it very much depends on the encryption mode. CBC mode does require
random nonces, other modes may be fine with even sequences as long as
the values are not reused. In which case we might even use the LSN, for
example. And I wonder if sha2(LSN) could be considered "random", but
maybe that's entirely silly idea ...
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
