[liberationtech] Not another Haystack right?

[Michael Rogers]

Hi Steve,

Thanks very much for the detailed points.

On 29/11/11 16:49, Steve Weis wrote:
> This rationale for why they are inventing a new transport protocol needs
> to be explained better. Why reinvent the wheel instead of using TLS?

TLS can't operate over one-way transports or high-latency transports.
For example, I can't use TLS to encrypt data on a memory stick. Yes,
there are other solutions that work for memory sticks, but those
solutions don't work for TCP connections. We're trying to create a
single format that works across all available transports, so that the
higher layers of the software can be transport-agnostic.

Maybe that's a fool's errand, but I think relying on a different crypto
design for each transport, each with subtly different security
guarantees, would also be problematic.

> From a quick read through, they're stuffing connection info into an IV
> and encrypting it with an ephemeral "IV key" in ECB mode. The spec says
> "the purpose of encrypting the IV is not to keep the plaintext IV
> confidential, but rather to prevent an observer from identifying the
> Briar protocol through techniques such as deep packet inspection".
> 
> That seems unnecessarily complicated. Someone could encrypt all the
> Brian connection info in a regular encrypted payload with a random IV,
> which will be just as indistinguishable. I guess the idea is that the
> receiver can quickly decrypt one block and check whether it's a Briar
> connection, rather than having to decrypt a whole blob.

The reason for not using a random IV is that the recipient precalculates
the IV that the sender will use for each connection. That allows the
recipient to identify which contact each connection comes from, and
select the appropriate keys for decrypting and authenticating the
connection, without an interactive handshake (again, because we want to
operate over one-way and high-latency transports).

> This IV has a 32-bit connection number that cannot be reused, requiring
> counter state on each node.

Yes, some kind of persistent counter is necessary in any secure channel
based on symmetric keys.

> There's no mention of what happens when an
> attacker opens connections to exhaust that counter or causes a node to
> reset its counter.

The counter is only updated when an expected IV is received. An attacker
cannot generate expected IVs, since each one is generated by encrypting
a known plaintext with a secret key.

An attacker could replay IVs created by an innocent sender, but in that
case it would be correct for the recipient to update the counter, since
no IV should be accepted more than once. Each replayed IV would only
cause the counter to be updated once, no matter how many times it was
replayed.

> It's also not clear what happens when someone sends
> corrupted IVs. There is no authentication on the IV itself, unless you
> authenticate the HMAC on the entier paylaod. Nodes have to decrypt the
> IV and try to parse the resultant fields.

It's true that there's no authentication on the IV, but an attacker
cannot cause modified data to be accepted by modifying the IV. Any
modification to the IV will cause the connection to be closed without
any payload bytes being accepted. Here's why:

If an attacker modifies the IV, the result must either be another
expected IV or an unexpected IV.

If the result is expected (unlikely, but let's consider the
possibility), there will be two effects. (1) The recipient will use the
keys corresponding to the modified IV, rather than the keys
corresponding to the original, to decrypt and authenticate the
connection. The authentication will fail at the first frame because the
wrong key is being used, and the recipient will close the connection
without accepting any payload data. (2) When the genuine connection with
the same IV is received, it will be rejected. That's fine - we can cope
with the occasional lost connection, it doesn't break security.

If, on the other hand, the result is unexpected, the recipient will
close the connection immediately. Either way, all the attacker achieves
is to force the recipient to close the connection without accepting any
payload data.

I'll update the docs to make this clearer.

> It's unclear how nodes handle
> unexpected frame, connection, or block numbers. If you can reliably get
> a Briar node to fail in a distinct manner, it might reveal itself as a
> Briar node.

Good point. The short answer is that if an attacker removes, duplicates
or reorders parts of an encrypted connection, the recipient will attempt
to decrypt the first MAC following the modification with a different
portion of the CTR mode keystream than the sender used to encrypt it.
That will cause the MAC check to fail and the connection will be closed
without accepting the payload of the first frame affected by the
modification or any subsequent frame.

> I think questions about of Java versions and Oracle's export policies
> are bikeshedding at this point. This needs a lot more review before I
> would ever trust it.

Thanks for contributing to that review. :-) It's really helpful to have
the design rigorously examined like this.

Cheers,
Michael