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 (bruce@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
