[liberationtech] Not another Haystack right?

Tue Nov 29 10:22:56 PST 2011

Interesting discussion so far, though I'll admit the vagaries of the more
technical pieces are a bit beyond me.

Michael,

I'd like to know 2 things:

1. what are some use-cases you see for Briar? That is not clear from your
site, other than "Briar is a secure news and discussion system designed to
be used by journalists, activists and civil society groups in authoritarian
countries. "

How would they use it? What would they do with it? What are their goals,
and for what reasons would they choose Briar over, say, secret Facebook
groups run over TOR and HTTPS (there may be lots of problems with that
example, its just an example that I think activists are likely to utilize,
and I know of at least one case where a "secret facebook group" has been
used to coordinate actions in an Arab country, though I doubt they were
using any additional security in most cases)

With regard to its use by journalists especially, how will sources be able
to be identified? Although you may not want people to know that Brian Joel
Conley who lives in Portland OR, etc said X, Y, and Z, a journalist will
need to know that X, Y, and Z were all said by the same source, among other
needs.

2. who is funding your project? Are you being public about this? If not, it
raises some concerns for the validity and viability of the project, though
it may also be understandable given the subject matter. If it's not being
funded by the Broadcast Board of Governors already, and you're willing to
consider USG funding, let me know and I'm happy to put you in touch with
some folks who may be able to assist.

regards

Brian

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

> 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
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
>
> Should you need to change your subscription options, please go to:
>
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> If you would like to receive a daily digest, click "yes" (once you click
> above) next to "would you like to receive list mail batched in a daily
> digest?"
>
> You will need the user name and password you receive from the list
> moderator in monthly reminders.
>
> Should you need immediate assistance, please contact the list moderator.
>
> Please don't forget to follow us on http://twitter.com/#!/Liberationtech
>

-- 

Brian Conley

Director, Small World News

http://smallworldnews.tv

m: 646.285.2046

Skype: brianjoelconley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20111129/2d162720/attachment.html>