[Cryptography] Name for three key ECDH

[Phillip Hallam-Baker]

One of the features I am using in the Mesh is the an authenticated and
encrypted ECDH mode. I will explain in discrete log but y'all know what I
mean here.

One of my hold ups here is what to call this exchange.

I am trying to tweak this to get the desired properties.

* Every message should be authenticated under the sender's key.
* The communication should not create a non repudiable proof of the
involvement of either party
* All communications after the first request to be encrypted
* Enable pre-calculation of the exchange on the client side to the greatest
extent possible


The last was something I was thinking about this morning. If I have a light
bulb and it is using a stream cipher, I don't really need to wait to do any
of the calculations normally required to encrypt a request. I can prepare
the 'encryption' part of the request when the device turns on and
immediately after a message is sent.


So Alice has long term credential {a, A (= e^a mod p)} and the service has
long term credential {s, S}. At the start of the communication, Alice does
not have the Service credential but we assume she can authenticate it from
a fingerprint or whatever.

There isn't much Alice can do until she knows the public key of the service
except send her own public key. We generate a nonce n_A and use it to
create a blinding function N_A. The key that we will use is (A.N_A) mod p.

Alice-> Service  [ A, N_A, Cert-of-A ]

At this point the Service can verify A is properly certified and calculate
the client ephemeral key (A.N_A) mod p. This has exactly the same
properties as a normal ephemeral DH exchange but with the additional
feature of having authenticated the source.

The Service also generates a nonce n_S and responds to Alice

Service -> Alice [S, N_S, ID, E (payload, k) ]

Where k = KDF ( e^((a+n_A).(s+n_S))) =
    KDF ((S.N_S)^(a+n_A)) =
    KDF ((A.N_A)^(a+n_S))

This is then used as the shared secret for future exchanges. ID is an
identifier for this master secret which may be a Kerberized ticket.

The protocol requires that the response be either encrypted or
authenticated with a MAC. (Or else why bother with a key exchange at all).
Since I use a key wrap with integrity checking, there is no need to provide
for a separate check (though I could add one if needed).

The DARE Message Format never uses the master key for any purpose other
than key generation which is keyed with a unique value on each use.



The exchange as I currently have it does not actually achieve the first.
The request could come from any party which is OK if this is merely for an
initial 'hello' null transaction. Is there a cheap means of providing for
this authentication that does not amount to a signature?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190406/d62f53a7/attachment.html>