<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 7, 2014 at 11:41 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@lothar.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=warner@lothar.com&cc=&bcc=&su=&body=','_blank');return false;">warner@lothar.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">* it sounds like you only care about authenticating the pubkeys, but<br></div>
  you're actually encrypting them too. You might be able to simplify<br>
  things: instead of xsalsa20, just use a keyed MAC (HMAC-SHA256 or bare<br>
  poly1305 aka "crypto_onetimeauth").<br></blockquote><div><br></div><div>The "one weird trick" of my protocol is to launder key exchanges through a "broadcast" feed containing both encrypted messages and key exchanges, both padded to the same size (presently targeting ~64kB) and published to all recipients (ala a remailer)</div>

<div><br></div><div>I'm interested in what happens when you impose this sort of artificial constraint and whether it can positively impact a protocol's simplicity. It seems to have worked out for Twitter.</div><div>

<br></div><div>--</div></div>Tony Arcieri<br>
</div></div>