from Hacker News

A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

by Fethbita on 3/25/24, 7:30 AM with 48 comments

• by notfed on 3/27/24, 5:39 AM

  > The use-case is a user and a “service-provider” (of some kind, in my case a device). The device only responds to requests, performs computations in a separate computing environment and is, in this particular case, connected by USB port. There is sensitive information involved. The device, however, does not have storage capability...

  I think you're over-describing your use case, to the point that it's unclear what you're really saying. I read your "Introduction" section several times, and I don't understand if you're just saying "the use case is an authenticated key exchange" or something different. That makes it hard to judge the protocol.

  > Device gets authenticated

  > The device, however, does not have storage capability

  These two requirements are contradictory. How do you "authenticate" a server that has a different identity each time you interact with it?

  > [The protocol] is built on top of a Diffie-Hellman Key Exchange

  Why not just use Diffie-Hellman? What else is this offering?

• by crotchfire on 3/27/24, 5:25 AM

  This is Noise NK, possibly with differences in the hashing details which I did not check:

  https://noiseprotocol.org/noise.html#interactive-handshake-p...

  I encourage you to use their hashing details. They're battle-tested.

  Wireguard uses Noise IK, which is NK plus a static public key for the initiator which is encrypted to the agreed-upon-session-key without adding additional round trips. Your protocol and Noise NK omit the parts related to the initiator's static public key, because it has none.

• by pclmulqdq on 3/26/24, 8:05 PM

  I think this protocol is correct-ish* when you make the strong assumptions you have made about the device, but I also don't know why you would use it. Normally, you would prefer to both have unique device public keys for domain separation (preventing re-use of IVs, etc.) combined with the ability to verify that the device public key is actually the public key of a legitimate device. Otherwise, you could have a non-legit device conduct a MITM attack by running this protocol (if you trust the device to provide its identity PK) with the user and the device separately or you could have a counterfeit device created when sk_identity is eventually exfiltrated (if you set the identity PK as the same number for all devices at the factory - see what happens with DRM). Using some sort of device ID with a database mapping IDs to PKs also doesn't give you counterfeit protection the way a certificate does - a counterfeiter can re-use an ID. You also can't rotate your identity keys if you use this scheme.

  Most cryptosystems today offer flexible-enough primitives that you can come up with a lot of different possible ways to do things like this. Whether they are useful is a different story.

  IMO you should probably do something more normal, and just store the certificate chain with the device programming.

  *After about 10 minutes of analysis, so YMMV taking my word for it.

• by mike_d on 3/26/24, 7:10 PM

  I think this depends on a lot of assumptions about the capabilities of what is otherwise described as an absolutely dumb featureless device.

  If the device lacks access to storage it cannot store any state. How do you ensure the RNG isn't initialized to the same value every time? I'm not sure how that impacts some of the assumptions about security here.

• by thadt on 3/26/24, 9:21 PM

  On a cursory glance, this looks rather quite a bit like a Noise [1] pattern. One rather nice aspect of Noise is that there is a good reference chart for which security properties one should expect from different combinations - saving time on proofs.

  [1] https://noiseprotocol.org

• by dzdt on 3/26/24, 11:20 PM

  Rolling your own crypto routines of any variety is in the same category as representing yourself in a murder trial.

• by jonahbenton on 3/26/24, 6:32 PM

  This seems to be the use case for a user communicating with a confidential computing/enclave abstraction.