# [Cryptography] Non-Authenticated Key Agreement

Ron Garret ron at flownet.com
Wed Sep 23 13:38:39 EDT 2015

```On Sep 23, 2015, at 7:45 AM, Bill Cox <waywardgeek at gmail.com> wrote:

> On Tue, Sep 22, 2015 at 10:11 PM, Davy Durham <ddurham at davyandbeth.com> wrote:
> 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.
>
> 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 :)
>
> Alice wishes to send Bob a piece of information d.  Alice and Bob have not exchanged any information previously.
> Alice makes up a random key, ka, and Bob makes up a random key, kb.
> The following sequence diagram allows Alice to send d to Bob while the d remains protected from eavesdropping in between.
>
>    Alice                                           Bob
> d = data
> ka = random bits
> d' = E(d, ka)
>                          d'
>       ---------------------------------------->
>                                               kb = random bits
>                                               d'' = E(d', kb)
>                          d''
>       <----------------------------------------
> 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.
>
> 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.
>
> 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).
>
> One hard part in public key crypto is finding candidate functions E with this property.  It leads naturally to investigating Abelian groups.

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.

rg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150923/426b4b17/attachment.html>
```