[liberationtech] Not another Haystack right?

[Steve Weis]

Hi Michael. Thanks for the responses.

Some more comments inline.

On Tue, Nov 29, 2011 at 10:02 AM, Michael Rogers <m-- at gmx.com> wrote:

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

Just to play devil's advocate: Why not use GPG? You can store or transmit
encrypted, authenticated blobs over whatever slow, insecure channel you
want. You can also use whatever ephemeral key scheme you want.

I realize you have a different design goal, but just want to hear why it's
worth building a new standard from scratch.


>
> 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).
>
>
Is performance the main motivation? A recipient could try verifying MACs
with derived keys for all their contacts. That scales fine for hundreds of
contacts and typical message sizes. This is somewhat the same idea
behind chaffing and winnowing. Or you can just tag the output with an
identifier derived from the ephemeral key if it's only being used once.


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

Does immediately closing a connection given a bad IV allow an adversary to
quickly identify running Briar nodes?

There's precedent for that risk. For example, people have been seeing weird
SSH connection probes originating from Chinese IP addresses:
http://www.forbes.com/sites/andygreenberg/2011/11/17/chinas-great-firewall-tests-mysterious-scans-on-encrypted-connections/
http://www.nsc.liu.se/~nixon/sshprobes.html

It might be worth submitting the proposal to a venue like IEEE Security &
Privacy, Privacy Enhancing Technologies, or Usenix Security. That would be
a good way to get more peer review.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20111129/117513cc/attachment.html>