[messaging] Deterministic nonce generation for AES-CTR

[Nick Badger]

First off: in response to my own OP, with suggestions above and after a
bunch of discussion on /r/netsec (
https://www.reddit.com/r/netsec/comments/3sjgqk/muse_encrypted_transportagnostic_social_protocol/),
I've decided to move away from this funky nonstandard nonce generation to
SIV block mode. I'm also adding an option for CTR mode with a random nonce
for performance-sensitive applications, but as a compromise for network
deduplication, in that mode I'm moving the nonce out of the content objects
and into the keyshare objects.

Once again merging threads to continue:

---------

On Fri, Nov 13, 2015 at 11:16 AM, Taylor R Campbell <
campbell+moderncrypto at mumble.net> wrote:

> The critical distinction I meant to make was not between
> nondeterministic versus deterministic nonces, but rather between
> (pseudo)random versus sequential nonces.
>

Gotcha. In our case it's a one-to-many message environment, with no trusted
third parties. In this case there isn't any external connection between
messages, and also no state management. I haven't thought of any way to
implement a key-specific private deterministic iterable in that kind of
environment, but I'm all ears if someone else has.

I suppose a very limited subset (essentially API channels using mutable
references) of the protocol is one-to-one, but the majority of content has
indeterminate key state. Though, these API channels are the situations
where keys would most likely be reusable -- which is exactly why they'll
probably be Axolotl'd (or similar) before we hit full production, since key
reuse is potentially very dangerous.

---------

On Thu, Nov 12, 2015 at 5:41 PM, Jeff Burdges <burdges at gnunet.org> wrote:

> I'll second that you should read up on Tahoe-LAFS, including the
> complicated parts around mutable files and their append-only efforts.
>
> Jeff
>

I took around an hour out of my morning to glance around Tahoe, and it's a
really interesting project, but very, very complicated. Protocol scope for
Muse is much more restricted. Our approach to mutable content is to allow
immutable addresses to be bound to mutable references, but the actual
content is still static. Erm, okay, that's a mouthful. Think of mutable
lists in python:

one = 1
two = 2
three = 3
dynamic_content = [one]
dynamic_content = dynamic_content.pop().append(two)
dynamic_content = dynamic_content.pop().append(three)

and so on. Using that as a metaphor, each of "one", "two", "three",
"dynamic_content" are static addresses generated from a hash. The
"identity" (aka public key) that placed the dynamic binding is allowed to
rebind, updating the content to point to a different static resource, or to
debind, which is analogous to "del dynamic_content". For Muse, the binding
objects definitely have the largest attack surface. Critically though, the
mutable objects on Muse can only have a single author. If you're trying to
do things with multiple authors, you have to do it at the application
level. The protocol itself is just trying to mediate between actual
entity-agents (like people and businesses) and the devices they use on the
physical network.

---------

Thanks a ton for all the help, guys.

Nick Badger
https://www.ethyr.net
https://www.muterra.io
http://www.nickbadger.com
PGP fingerprint 37B9 22FC 2E47 50AA E06B 9CEC FB65 8930 46F0 333A, listed
at MIT <https://pgp.mit.edu/> and PGP <http://keyserver.pgp.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151113/45a560a8/attachment.html>