<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 23, 2015, at 7:45 AM, Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 22, 2015 at 10:11 PM, Davy Durham <span dir="ltr"><<a href="mailto:ddurham@davyandbeth.com" target="_blank">ddurham@davyandbeth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Okay, so I've lurked on this list for a couple of weeks and wasn't
sure if it was a safe place to propose crypto ideas, but given the
recent threads, and the plethora of friendly discuss, I feel that I
can do this :) And, I agree with Rule #1 of crypto, namely not to
invent your own. But I think the unstated rest of that thought is
"... and then to put it into practice without gobs of scrutiny".
Since I'm not doing that, here goes.<br></div></blockquote><div><br></div><div>I know others on this list might dump on arm-chair crypto attempts, but so as long as non-proven crypt is not put into practice, it's all fun. Besides, it's nice to be able to break a crypto system before breakfast :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Alice wishes to send Bob a piece of information d. Alice and Bob
have not exchanged any information previously.<br>
Alice makes up a random key, ka, and Bob makes up a random key, kb.<br>
The following sequence diagram allows Alice to send d to Bob while
the d remains protected from eavesdropping in between.<br>
<br>
<blockquote><tt> Alice
Bob</tt><tt><br>
</tt><tt>d = data</tt><tt><br>
</tt><tt>ka = random bits</tt><tt><br>
</tt><tt>d' = E(d, ka)</tt><tt><br>
</tt><tt> d'</tt><tt><br>
</tt><tt> ----------------------------------------></tt><tt><br>
</tt><tt> kb = random
bits</tt><tt><br>
</tt><tt> d'' = E(d',
kb)</tt><tt><br>
</tt><tt> d''</tt><tt><br>
</tt><tt> <----------------------------------------</tt></blockquote></div></blockquote><div>The problem in your crypto system happens right here. Eve simply computes d' XOR d'', and the result is kb, revealing Bob's secret key.</div><div><br></div><div>Your basic intuition is right, though. If we can find an encryption function E(d, k) such that E(E(d, k1), k2) == E(E(d, k2), k1) where E is a secure symmetric key encryption, then you can use it to create a public key crypto system.</div><div><br></div><div>If you look at regular DH, it almost fits into this model. Instead of user data d, use a constant g. Then you need E(E(g, k1), k2) == E(E(g, k2), k1). If E(g, k) = g^k mod p, then E(E(g, k1), k2) = (g^k1)^k2 = g^(k1*k2) = E(E(g, k2), k1).</div><div><br></div><div>One hard part in public key crypto is finding candidate functions E with this property. It leads naturally to investigating Abelian groups.</div></div></div></div></blockquote><br></div><div>Another good rule of thumb when getting into crypto protocol design: if you find yourself saying “one-time pad” you have almost certainly made a mistake. There is no security advantage to an OTP over a PRF. The only difference between them is that an OTP has len(msg) bits of entropy where a PRF has a fixed amount of entropy. But a fixed amount of entropy is the right thing. Entropy is expensive and you don’t want to use more of it than you actually need.</div><div><br></div><div>rg</div><div><br></div><br></body></html>