On 10/18/21 17:56, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
On 10/15/21 21:22, Stephen Frost wrote:
Now, to address the concern around re-encrypting a block with the same
key+IV but different data and leaking what parts of the page changed, I
do think we should use the LSN and have it change regularly (including
unlogged tables) but that's just because it's relatively easy for us to
do and means an attacker wouldn't be able to tell what part of the page
changed when the LSN was also changed. That was also recommended by
NIST and that's a pretty strong endorsement also.
Not sure - it seems a bit weird to force LSN change even in cases that don't
generate any WAL. I was not following the encryption thread and maybe it was
discussed/rejected there, but I've always imagined we'd have a global nonce
generator (similar to a sequence) and we'd store it at the end of each
block, or something like that.
The 'LSN' being referred to here isn't the regular LSN that is
associated with the WAL but rather the separate FakeLSN counter which we
already have. I wasn't suggesting having the regular LSN change in
cases that don't generate WAL.
I'm not very familiar with FakeLSN, but isn't that just about unlogged
tables? How does that help cases like setting hint bits, which may not
generate WAL?
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Oct 15, 2021 at 3:22 PM Stephen Frost <sfr...@snowman.net> wrote:
Specifically: The default cipher for LUKS is nowadays aes-xts-plain64
and then this:
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt
where plain64 is defined as:
plain64: the initial vector is the 64-bit little-endian version of the
sector number, padded with zeros if necessary
That is, the default for LUKS is AES, XTS, with a simple IV. That
strikes me as a pretty ringing endorsement.
Yes, that sounds promising. It might not hurt to check for other
precedents as well, but that seems like a pretty good one.
I'm not very convinced that using the LSN for any of this is a good
idea. Something that changes most of the time but not all the time
seems more like it could hurt by masking fuzzy thinking more than it
helps anything.
This argument doesn't come across as very strong at all to me,
particularly when we have explicit recommendations from NIST that having
the IV vary more is beneficial. While this would be using the LSN, the
fact that the LSN changes most of the time but not all of the time isn't
new and is something we already have to deal with. I'd think we'd
address the concern about mis-thinking around how this works by
providing a README and/or an appropriate set of comments around what's
being done and why.
I don't think anyone objects to varying IV more, as recommended by NIST.
AFAICS the issue at hand is exactly the opposite - maybe not varying it
enough, in some cases. It might be enough for MVCC purposes yet it might
result in fatal failure of the encryption scheme. That's my concern, at
least, and I assume it's what Robert meant by "fuzzy thinking" too.
FWIW I think we seem to be mixing nonces, IVs and tweak values. Although
various encryption schemes place different requirements on those anyway.
* Andres Freund (and...@anarazel.de) wrote:
On 2021-10-15 15:22:48 -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Finally, there is an interesting web page about when not to use XTS:
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
This particular article always struck me as more of a reason for us, at
least, to use XTS than to not- in particular the very first comment it
makes, which seems to be pretty well supported, is: "XTS is the de-facto
standard disk encryption mode."
I don't find that line of argument *that* convincing. The reason XTS is the
de-facto standard is that for generic block layer encryption is that you can't
add additional data for each block without very significant overhead
(basically needing journaling to ensure that the data doesn't get out of
sync). But we don't really face the same situation - we *can* add additional
data.
No, we can't always add additional data, and that's part of the
consideration for an XTS option- there are things we can do if we use
XTS that we can't with GCM or another solution. Specifically, being
able to perform physical replication from an unencrypted cluster to an
encrypted one is a worthwhile use-case that we shouldn't be just tossing
out.
Yeah, XTS seems like a reasonable first step, both because it doesn't
require storing extra data and it's widespread use in FDE software (of
course, there's a link between those). And I suspect replication between
encrypted and unencrypted clusters is going to be a huge can of worms,
even with XTS.
It's probably a silly / ugly idea, but can't we simply store a special
"page format" flag in controldat - when set to 'true' during initdb,
each page would have a bit of space (at the end) reserved for additional
encryption data. Say, ~64B should be enough. On the encrypted cluster
this would store the nonce/IV/... and on the unencrypted cluster it'd be
simply unused. 64B seems like a negligible amount of data. And when set
to 'false' the cluster would not allow encryption.
With something like AES-GCM-SIV we can use the additional data to get IV reuse
resistance *and* authentication. And while perhaps we are ok with the IV reuse
guarantees XTS has, it seems pretty clear that we'll want want guaranteed
authenticity at some point. And then we'll need extra data anyway.
I agree that it'd be useful to have an authenticated encryption option.
Implementing XTS doesn't preclude us from adding that capability down
the road and it's simpler with fewer dependencies. These all strike me
as good reasons to add XTS first.
True. If XTS addresses the threat model we aimed to solve ...
Thus, to me, it doesn't seem worth going down the XTS route, just to
temporarily save a bit of implementation effort. We'll have to endure that
pain anyway.
This isn't a valid argument as it isn't just about implementation but
about the capabilities we will have once it's done.
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
On 10/15/21 23:02, Robert Haas wrote:
On Fri, Oct 15, 2021 at 3:22 PM Stephen Frost <sfr...@snowman.net> wrote:
That is, the default for LUKS is AES, XTS, with a simple IV. That
strikes me as a pretty ringing endorsement.
Yes, that sounds promising. It might not hurt to check for other
precedents as well, but that seems like a pretty good one.
TrueCrypt/VeraCrypt uses XTS too, I think. There's an overview of other FDE
products at [1], and some of them use XTS, but I would take that with a
grain of salt - some of the products are somewhat obscure, very old, or
both.
What is probably more interesting is that there's an IEEE standard [2]
dealing with encrypted shared storage, and that uses XTS too. I'd bet
there's a bunch of smart cryptographers involved.
Thanks for finding those and linking to them, that's helpful.
I'm not very convinced that using the LSN for any of this is a good
idea. Something that changes most of the time but not all the time
seems more like it could hurt by masking fuzzy thinking more than it
helps anything.
I haven't been following the discussion about using LSN, but I agree that
while using it seems convenient, the consequences of some changes not
incrementing LSN seem potentially disastrous, depending on the encryption
mode.
Yes, this depends on the encryption mode, and is why we are specifically
talking about XTS here as it's an encryption mode that doesn't suffer
from this risk and therefore it's perfectly fine to use the LSN/FakeLSN
with XTS (and would also be alright for AES-GCM-SIV as it's specifically
designed to be resistant to IV reuse).
I'm not quite sure about the "perfectly fine" bit, as it's making XTS
vulnerable to traffic analysis attacks (comparing multiple copies of an
encrypted block). It may be a reasonable trade-off, of course.
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Oct 15, 2021 at 10:57:03PM +0200, Tomas Vondra wrote:
That said, I don't think that's really a huge issue or something that's
a show stopper or a reason to hold off on using XTS. Note that what
those bits actually *are* isn't leaked, just that they changed in some
fashion inside of that 16-byte cipher text block. That they're directly
leaked with CTR is why there was concern raised about using that method,
as discussed above and previously.
Yeah. With CTR you pretty learn where the hint bits are exactly, while with
XTS the whole ciphertext changes.
This also means CTR is much more malleable, i.e. you can tweak the
ciphertext bits to flip the plaintext, while with XTS that's not really
possible - it's pretty much guaranteed to break the block structure. Not
sure if that's an issue for our use case, but if it is then neither of the
two modes is a solution.
Yes, this is a vary good point. Let's look at the impact of _not_ using
the LSN. For CTR (already rejected) bit changes would be visible by
comparing old/new page contents. For CBC (also not under consideration)
the first 16-byte block would show a change, and all later 16-byte
blocks would show a change. For CBC, you see the 16-byte blocks change,
but you have no idea how many bits were changed, and in what locations
in the 16-byte block (AES uses substitution and diffusion). For XTS,
because earlier blocks don't change the IV used by later blocks like
CBC, you would be able to see each 16-byte block that changed in the 8k
page. Again, you would not know the number of bits changed or their
locations.
Do we think knowing which 16-byte blocks on an 8k page change would leak
useful information? If so, we should use the LSN and just accept that
some cases might leak as described above. If we don't care, then we can
skip the use of the LSN and simplify the patch.
While there may not be an active attack against PG that leverages such a
leak, I have a hard time seeing why we would intentionally design this
in when we have a great option that's directly available to us and
doesn't cause such a leak with nearly such regularity as not using the
LSN would, and also follows recommendations of using XTS from NIST.
Further, not using the LSN wouldn't really be an option if we did
eventually implement AES-GCM-SIV, so why not have the two cases be
consistent?
I'm a bit confused, because the question was what happens if we encrypt
the page twice with the same LSN or any tweak value in general. It
certainly does not matter when it comes to malleability or replay
attacks, because in that case the attacker is the one who modifies the
block (and obviously won't change the LSN).
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
