<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>