[Cryptography] Non-Authenticated Key Agreement

[Davy Durham]

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'm no crypto expert.  I've dabbled, used libraries, read a bit and 
taken an online course or two (Dan Boneh is awesome!).  But the 
following occurred to me, and I'm initially just curious if it has been 
described before, does it have a name.  And if its original, and if 
truly has the properties I believe it has, the next question is what 
value it might have in practice.  I've googled around quite a bit and 
haven't seen it described.

It's so simple, it's either been thought of and discarded out of hand 
(for reasons I don't yet realize) or else perhaps the 'big brains of 
crypto' were just too distracted by more advanced topics to notice it.

Consider the following for a non-authenticated key agreement mechanism 
that does not involve any complex math (beyond a [P]RNG) and requires no 
previous knowledge between the parties...  Further, I believe it has all 
of the good qualities of DH and the same number of steps in a ladder 
diagram, but remains much simpler in concept and implementation.

Given an encrypt (and decrypt, for that matter) function based the 
one-time pad idea:
     E(d, k) = d xor k
     Where:
         - d is data given to encrypt
         - k is the one-time pad key to encrypt with
             - k is at least as long as d.
             - k is ephemeral, i.e. it is picked at random each time the 
algorithm is used

Notice the obvious property of E:
     E(E(d, k1), k2)   is bit-equivalent to   E(E(d, k2, k1)


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''
           <----------------------------------------
    d''' = E(d'', ka)
                              d'''
           ---------------------------------------->
                                                   d = E(d''', kb)

At this point, by having taken advantage of the property of E pointed 
out above, Bob now has the value of d that Alice originally wanted Bob 
to know.
Considering that d could be a symmetric key, Alice and bob could 
continue a conversation using standard methods.


Assuming it hasn't been proposed before, is it useful?

The method described above is protected against eavesdropping, but it is 
vulnerable to an active man-in-the-middle.  As a middle party, Mallory, 
could insert herself in the insecure communications channel and Alice 
wouldn't know that she initially communicated with Mallory instead of Bob.

It appears to have the same security properties as Diffie-Hellman, and 
would seem to have some value in practice anywhere DH is used (e.g. in 
combination with other methods for authentication like ECDHE uses DH or 
STS uses DH).  However, this method's computation would appear to be 
less expensive than DH (if generating the random bits for the keys is 
cheaper than computing the DH parameters) and is conceptually as easy to 
understand as the one-time pad.  And DH is only as strong as the the 
computation is difficult to reverse but this method uses the perfect 
secrecy property of the one-time pad and is thus as good as the keys, ka 
and kb, were random (assuming MiM is prevented by its use in combination 
with other things)

Your thoughts?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150923/1631e0b7/attachment.html>