<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 2:59 PM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Mon, Jan 18, 2016 at 11:35 AM, John Gilmore <<a href="mailto:gnu@toad.com">gnu@toad.com</a>> wrote:<br>
>> Not singular "split golden key"  but plural this involves key pairs for<br>
>> both ends of the conversations.<br>
><br>
> The discussion is slightly interesting, but please notice that it<br>
> isn't relevant to Chaum's proposed design.  Beating the stuffing out<br>
> of a propped-up strawman isn't much of a feat of strength.  cMix<br>
> doesn't have a golden key, it doesn't split that key, etc.<br>
><br>
> It's worth reading Chaum's cMix design to at least *understand* what<br>
> you may want to criticize.  Try:<br>
><br>
>   <a href="https://eprint.iacr.org/2016/008.pdf" rel="noreferrer" target="_blank">https://eprint.iacr.org/2016/008.pdf</a><br>
<br>
</span>Quite.<br>
<br>
And moreover, Chaum is first and foremost showing a new technique<br>
here, applying homomorphic encryption to a particular problem.</blockquote><div><br></div><div>Yes,</div><div>I may have been distracted but my point is multiple keys are involved</div><div>and monitoring traffic over time is hard.  Hard enough that once an endpoint </div><div>is exposed it is unlikely that the insertion into the system will be relinquished</div><div>any time soon.</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>"Each sender establishes a shared key separately with each
of the mix nodes, which </div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>is used as a seed to a cryptographic
pseudorandom number generator to generate a </div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>sequence of
message keys. Each sender encrypts its input"</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>..."</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>"Only if all of the mixing nodes cooperate, can the
senders and receivers of messages be linked or identified.</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Chaum's proposal is a useful contribution to that debate insofar as<br>
the FBI will clearly reject it and so would anyone who might choose to<br>
use a mix network.<br></blockquote><div> </div><div> Very much so!</div><div><br></div><div>The debate needs to address the venn diagram of small, medium, large and global</div><div>jurisdictions and communication.   As New York looks to ban encrypted </div><div>smartphones I should note that some federal agencies just enacted</div><div>new policies mandating increased access controls including encryption.</div><div><br>The proposed NY law  <a href="http://www.nysenate.gov/legislation/bills/2015/a8093">http://www.nysenate.gov/legislation/bills/2015/a8093</a></div><div>Not just content on the device but https phone to phone chat </div><div>conversations are interesting and other content that is never kept</div><div>in a log or record.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>