[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>
More information about the cryptography
mailing list