<div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of my hold ups here is what to call this exchange.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am trying to tweak this to get the desired properties. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Every message should be authenticated under the sender's key.  <br></div><div class="gmail_default" style="font-size:small">* The communication should not create a non repudiable proof of the involvement of either party</div><div class="gmail_default" style="font-size:small">* All communications after the first request to be encrypted</div><div class="gmail_default" style="font-size:small">* Enable pre-calculation of the exchange on the client side to the greatest extent possible</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice-> Service  [ A, N_A, Cert-of-A ]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Service also generates a nonce n_S and responds to Alice</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Service -> Alice [S, N_S, ID, E (payload, k) ]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Where k = KDF ( e^((a+n_A).(s+n_S))) =</div><div class="gmail_default" style="font-size:small">    KDF ((S.N_S)^(a+n_A)) = <br></div><div class="gmail_default" style="font-size:small">    KDF ((A.N_A)^(a+n_S)) <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div>