[noise] Strengthening the Noise framework's metadata protection with PURBs

[Trevor Perrin]

On Wed, Aug 7, 2019 at 5:51 PM Bryan Ford <brynosaurus at gmail.com> wrote:
>
> We recently published the final version of our PETS ’19 paper on Padded Uniform Random Blobs or PURBs, which I hope the Noise framework community will find interesting and relevant if you haven’t seen it already:
>
> Reducing Metadata Leakage from Encrypted Files and Communication with PURBs
> http://bford.info/pub/sec/purb-abs/
>
> In particular, I’d like to see if there’s interest in strengthening the Noise framework’s metadata leakage protection in a future update so that as many as its message transmissions as possible are leakage-resistant PURBs?

Hi!

This touches on a bunch of things we could do:

 (1) encoding ephemerals for indistinguishability

 (2) "handshake indistinguishability" as discussed in 10.5 of the
spec, where a "compound handshake" could negotiate different Noise
protocols and hides which Noise protocol is negotiated.   We could pay
more attention to that in the NLS / NoiseSocket framework which adds
negotiation to Noise, and has some rough docs on the wiki.

 (3) algorithms to decide how much padding to add, like your PADME.

 (4) multi-recipient messages.  We haven't done much here, it would be
a stretch to consider fallback from a 0-RTT attempt (like the IK/XX
"Noise Pipes" discussed in spec) a "multi-recipient" case but it at
least involves trial decryption.

But we've never thought much about the PGP-like case of encrypting a
single message to multiple recipient public keys.  Not sure whether
Noise has something to offer there, or if the goals are different
enough to deserve a different design effort.  For example, Filippo
Valsorda's "age" attempts to improve on PGP but just designs something
from scratch [1].

Anyways, (1-3) could be looked at as we get back into NoiseSocket/NLS
work (which has been a bit dormant last several months, hope to fix
that soon).

For multi-recipient messages (4), your paper has some interesting
ideas but whether we could find demand for this in general; or for a
Noise-based construction in particular; I'm not sure.

Trevor

[1] https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/view#heading=h.y2j00d5szll4