[Cryptography] Cryptographically securing a two-phase commit

[Natanael]

Den tors 30 juli 2020 08:35Peter Gutmann <pgut001 at cs.auckland.ac.nz> skrev:

> Jon Callas <jon at callas.org> writes:
>
> >I'm not sure this is even possible.
>
> That was my feeling as well, but I wanted to get confirmation before I
> declared it unsolvable.  In particular making an absolute statement like
> that
> to security people invites vigorous pen-testing of the validity of the
> statement.
>
> The current thinking for dealing with it involves adding an SSH or TLS
> channel
> and channel-binding the data being communicated.  So set up a TLS channel,
> send some sort of bound proof of freshness inside the channel and then
> follow
> it with the blob, with the proof-of-freshness -> blob link provided by the
> channel.  That moves the issue to a MITM problem, which is much easier to
> deal
> with.  The drop-the-nth-block DoS that you point out is still possible, but
> most of the hole before that is closed.
>

Tahoe-LAFS uses signed Merkle trees over the ciphertext. This allows
continuous partial validation and arbitrary reads while being able to
verify full file version consistency (relevant for things like volume
encryption, where an evil maid attack might selectively replace part of a
ciphertext with an older version), but it does add a bit overhead for
memory/storage/CPU versus something simpler.

Trying to stream (encrypt and authenticate as the data is generated) this
would require sending intermediate nodes of the Merkle tree along with the
ciphertext packets as you're building this tree over the ciphertext, using
additional memory overhead and network overhead, but it doesn't add much
CPU overhead.

Protocols like TLS does something related and simpler than Merkle trees
with the standard steam cipher + polynomial hash tags, like
ChaCha20+poly1305 or AES-GCM. Since the tags are applied per packet in for
example TLS this also allows partial reads, but IMHO isn't ideal for
rewritable at-rest encryption (to be robust it requires full overwrite per
section on each write, and nonce tracking). This may also be vulnerable to
the evil maid attack mentioned above, with partial section reversals. It
uses less CPU and memory than Merkle trees, but uses more storage/network
overhead (many tags instead of one).

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200801/c30d5b46/attachment.htm>