On Thu, Oct 7, 2021 at 12:57 PM Stephen Frost <sfr...@snowman.net> wrote: > Yes, for integrity verification (also known as 'authenticated > encryption') we'd definitely need to store a larger nonce value. In the > very, very long term, I think it'd be great to have that, and the patch > proposed on this thread seems really cool as a way to get us there.
OK. I'm not sure why that has to be relegated to the very, very long term, but I'm really very happy to hear that you think the approach is cool. > Having TDE, even without authenticated encryption, is certainly > valuable. Reducing the amount of engineering required to get there is > worthwhile. Implementing TDE w/ XTS or similar, provided we do agree > that we can do so with an IV that we don't need to find additional space > for, would avoid that page-level format change. I agree we should do > some research to make sure we at least have a reasonable answer to that > question. I've spent a bit of time on that and haven't gotten to a sure > answer one way or the other as yet, but will continue to look. I mean, I feel like this meeting that Bruce was talking about was perhaps making decisions in the wrong order. We have to decide which encryption mode is secure enough for our needs FIRST, and then AFTER that we can decide whether we need to store a nonce in the page. Now if it turns out that we can do either with or without a nonce in the page, then I'm just as happy as anyone else to start with the method that works without a nonce in the page, because like you say, that's less work. But unless we've established that such a method is actually going to survive scrutiny by smart cryptographers, we can't really decide that storing the nonce is off the table. And it doesn't seem like we've established that yet. -- Robert Haas EDB: http://www.enterprisedb.com