[prev in list] [next in list] [prev in thread] [next in thread]
List: cryptography
Subject: Re: [Cryptography] Cryptographically securing a two-phase commit
From: Natanael <natanael.l () gmail ! com>
Date: 2020-08-01 19:15:40
Message-ID: CAAt2M182RqKRRKnUzKRA0Q_hQ3Y+_HJNJ0f+jRnYD5ngpTa8Cw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Den tors 30 juli 2020 08:35Peter Gutmann <pgut001@cs.auckland.ac.nz> skrev:
> Jon Callas <jon@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).
>
[Attachment #5 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Den tors 30 juli 2020 08:35Peter Gutmann <<a \
href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> \
skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Jon Callas <<a \
href="mailto:jon@callas.org" target="_blank" rel="noreferrer">jon@callas.org</a>> \
writes:<br> <br>
>I'm not sure this is even possible.<br>
<br>
That was my feeling as well, but I wanted to get confirmation before I<br>
declared it unsolvable. In particular making an absolute statement like that<br>
to security people invites vigorous pen-testing of the validity of the<br>
statement.<br>
<br>
The current thinking for dealing with it involves adding an SSH or TLS channel<br>
and channel-binding the data being communicated. So set up a TLS channel,<br>
send some sort of bound proof of freshness inside the channel and then follow<br>
it with the blob, with the proof-of-freshness -> blob link provided by the<br>
channel. That moves the issue to a MITM problem, which is much easier to deal<br>
with. The drop-the-nth-block DoS that you point out is still possible, but<br>
most of the hole before that is closed.<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div \
dir="auto"><br></div><div dir="auto">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). </div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div>
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic