Subject: [Cfrg] Noise

From: Tony Arcieri <[email-masked]>
Date: Wed, 6 Apr 2016 00:36:34 -0700

WhatsApp announced today they are using Trevor Perrin's Noise protocol for
transport encryption protocol:

https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

New web site here:

http://noiseprotocol.org/

Allegedly it is the transport encryption protocol now used by over a
billion WhatsApp users worldwide.

I bring it up mostly to ask if anyone is doing or plans to do analysis on
it.

-- 
Tony Arcieri

---

From: Bill Cox <[email-masked]>
Date: Wed, 6 Apr 2016 09:41:21 -0700

With a quick read over the Noise protocol, I am impressed.  It may lack
some of the cipher suite agility we see in TLS, and I do not see any
extension mechanism, but the frameworks looks both simple and well
designed.  I am concerned that there seems to be no version negotiation,
and the application software is expected to do this out-of-band, or in
cleartext negotiation pre-handshake.  The Noise documentation does a good
job IMO covering various security properties.

At this point, I think I would be able to spot many rookie mistakes such as
malleable encrypted data, lack of entropy, and replayable messages.  The
Noise framework gives the user the flexibility to shoot themselves in the
foot with all of these rookie mistakes, so the security of connections
depends heavily on how the framework is used.  If using one of the
recommended modes, such as "Noise_XX", it looks hard to mess up badly,
assuming version negotiation goes well.  Noise_XX uses this handshake:

Noise_XX
 -> e
 <- e, dhee, s, dhse
 -> s, dhse

The 'e' is an ephemeral Curve25519 public key.  's' is a static Curve25519
public key.  "dhee" and "dhse" I think are tokens indicating that the data
following the tag will be encrypted using keys derived from two ephemeral
keys (dhee) or one ephemeral and one static key (dhse).

The signal protocol
<https://github.com/whispersystems/libsignal-protocol-java/> used on top of
the Noise framework seems hard to analyze, at least from just the Java
code.  It looks like hiding meta-data, such as who is talking to who, was
not a top level priority compared to the convenience of finding contacts
who already use WhatsApp from your email contacts.

IIUC (highly unlikely), this meta data (who talked to who, when, how long)
is all that is legally required by the US government from
telecommunications companies.  Maybe hiding this meta data was
intentionally not done by the WhatsApp team.  In any case, kudos to the
WhatsApp team.  Regardless of the security of their implementation, it
takes guts to ship strong end-to-end encryption in this political
environment.

Bill

On Wed, Apr 6, 2016 at 12:36 AM, Tony Arcieri <[email-masked]> wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Apr 2016 22:15:02 +0300

> job IMO covering various security properties.

As far as I can see, Application can send data before the handshake and
this data is confirmed. Ther are also application message fields in
handshake messages.

One thing I noticed is that there doesn't seem to be space for splitting
messages, limiting application data to ~63kB per handshake message, but
going for TLS, that's usually plenty.

Also, it is unclear how to do parameter negotiation without losing
a roundtrip (client negotiation can be included in prologue but what
about server data sent immediately?)

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Wed, 6 Apr 2016 21:44:32 -0700

My effort to further analyze WhatsApp security failed, because I can't find
any source code implementing Noise Pipes as claimed by WhatsApp.

The noiseprotocol.org site has 3 implementations: one in Go, one in Rust,
and one in Haskell, while the libsignal library the WhatsApp points to is
entirely in Java and has no code that resembles a Noise Pipes
implementation.  Is this more security through obscurity?

Bill