[liberationtech] Not another Haystack right?

[Michael Rogers]

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

I'd love to use a standard solution rather than building a new one, but
to be honest, I don't know enough about GPG to know whether it would be
suitable. Does it have a standard way of authenticating a message with a
MAC rather than a signature?

One of our design goals is that Briar traffic should be
indistinguishable from random data - do you know whether GPG can meet
that criterion, or is there some identifiable structure to the ciphertexts?

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

Yup, that would work too, but I don't see why it's preferable to
attaching the encrypted IV to the start of the connection.

> Or you can just tag the output with an
> identifier derived from the ephemeral key if it's only being used once.

That's essentially what the encrypted IV is - a pseudo-random tag.

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

Yes - if you open a connection to a transport endpoint and send it 15
bytes of random data, then wait, then send another byte, a Briar node
will never hang up after 15 bytes but will always hang up after 16
(unless you guessed an expected IV, which is a one in 2^128 chance).

That's definitely a problem we should address, but I'm not sure how.
Perhaps we should keep reading and discarding data for a while even if
the IV isn't expected?

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

Great idea. Some parts of the protocol are in flux at the moment, but
once they've stabilised we should write them up and submit them.

Cheers,
Michael