On 7/9/19 4:23 AM, Tomas Vondra wrote: > 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 ...
Yeah, we worked mostly with CBC so that could be the case in terms of what is required. But I don't think it is ever a bad idea. But as Stephen pointed out elsewhere on this thread, I think we should be getting our guidance from places like NIST, which has actual experts in this stuff. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature