<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">First off: in
response to my own OP, with suggestions above and after a bunch of
discussion on /r/netsec
(<a href="https://www.reddit.com/r/netsec/comments/3sjgqk/muse_encrypted_transportagnostic_social_protocol/">https://www.reddit.com/r/netsec/comments/3sjgqk/muse_encrypted_transportagnostic_social_protocol/</a>),
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.<br><br>Once again merging threads to continue:<br><br>--------- <br></div><div class="gmail_quote"><br>On Fri, Nov 13, 2015 at 11:16 AM, Taylor R Campbell <span dir="ltr"><<a href="mailto:campbell+moderncrypto@mumble.net" target="_blank">campbell+moderncrypto@mumble.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>The critical distinction I meant to make was not between<br>
nondeterministic versus deterministic nonces, but rather between<br>
(pseudo)random versus sequential nonces.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div> <br>--------- <br><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 5:41 PM, Jeff Burdges <span dir="ltr"><<a href="mailto:burdges@gnunet.org" target="_blank">burdges@gnunet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""></span>I'll second that you should read up on Tahoe-LAFS, including the<br>
complicated parts around mutable files and their append-only efforts.<br>
<span class=""><font color="#888888"><br>
Jeff<br></font></span></blockquote><div><br></div><div>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:<br><br></div><div>one = 1<br></div><div>two = 2<br></div><div>three = 3<br></div><div>dynamic_content = [one]<br></div><div>dynamic_content = dynamic_content.pop().append(two)<br></div><div>dynamic_content = dynamic_content.pop().append(three)<br><br></div><div>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.<br></div><div><br>--------- <br></div></div><br></div><div>Thanks a ton for all the help, guys.<br></div><div><br><div dir="ltr">Nick Badger<br></div><div><a href="https://www.ethyr.net" target="_blank">https://www.ethyr.net</a><br></div><div><a href="https://www.muterra.io" target="_blank">https://www.muterra.io</a><br></div><a href="http://www.nickbadger.com" target="_blank">http://www.nickbadger.com</a><br><span><font size="1">PGP fingerprint 37B9 22FC 2E47 50AA E06B 9CEC FB65 8930 46F0 333A, listed at <a href="https://pgp.mit.edu/" target="_blank">MIT</a> and <a href="http://keyserver.pgp.com/" target="_blank">PGP</a></font></span> <br></div></div><br></div></div>