[liberationtech] Not another Haystack right?

[Jacob Appelbaum]

On 11/29/2011 11:08 AM, Steve Weis wrote:
> 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.
> 
> 

Indeed, while I like the idea for a sneakernet, I think `gpg -R` does
the job fine most times, no?

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

I agree - this seems like a sane suggestion.

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

I'd like to echo this reasonable concern. Active probing was a nightmare
we thought would not come for many more years. It's here today and
actively probed services that don't respond "in the right way" -
whatever that means - the connections are torn down.

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

I really suggest submitting to Usenix security. It's happening in
Seattle next year and it should be great. I think the CFP is coming up
in a few months.

All the best,
Jake