4 ms·

I mean this looks like standard ECIES to me. I think it could even count as a Noise protocol, as in my understanding that protocol family subsumes most of the c

I mean this looks like standard ECIES to me. I think it could even count as a Noise protocol, as in my understanding that protocol family subsumes most of the classic Diffie Hellman based key exchanges. Reading the source the author seems to use a long-lived ECDSA key pair to sign and exchange an ephemeral ECDH key pair, then derives a symmetric AES key from that and uses that for AES-GCM. Not sure how you would do message reordering here as GCM takes care of authenticating your data and keys are not reused. If you want replay protection it's probably sufficient to either remember used keys or add a timestamp. It's a well-done example of writing such a simple protocol, I don't think the author plans to replace TLS with it and he even mentions that in the README.

tptacek 4y ago
Can you express this with Noise framework tokens? I don't think you can. Noise is fiddlier than it looks! It's not just an ordering of DH exchanges; it's transcript hashes, cipher state tracking (and reinitializing), key derivation, the whole 9. The temptation (at least for me) is to just skip to the table of handshakes and skim, but the actual protocol framework is in Section 5, where they define precisely what each of those tokens really entails. (To say nothing of: this uses signatures, and Noise does not).
- deleted 4y ago
  [deleted]
- ThePhysicist 4y ago
  Probably not, though Noise mentions that you could replace DH operations with signatures.
  - tptacek 4y ago
    Yeah, I don't mean to be coy. You can't end up with this protocol using Noise. :)
    - ThePhysicist 4y ago
      ECIES is quite fine though for most asynchronous applications, where having a signing key also makes sense as you often want to publish long-lived, signed data and build a trust chain (e.g. generate and sign session keys from a master key). I built several real-world systems based on that (e.g. [1]) and they all made it through the audits fine. I was exploring Noise-based protocols but I find it's best to rely on primitives that are supported by the Web Crypto API. 1: https://github.com/kiebitz-oss/ https://github.com/kiebitz-oss/
      - tptacek 4y ago
        ECIES is a hybrid encryption construction; Noise is a protocol. They're two different levels of abstraction. This thing we're commenting on has a protocol; it's just an accidental one, which is usually not what you want. WebCrypto doesn't provide a protocol framework, just a bunch of primitives.
- erincandescent 4y ago
  Gotta say that I generally like the Noise framework (or rather the protocols that result), but it is one of the most impenetrable specifications I've ever read I don't remember what it is specifically about it, I just remember the document being a pain to read; a bit like the original Paxos paper in that regard.
  - tptacek 4y ago
    I don't know about that. As an implementor, it is probably one of the easiest-to-follow specs I've ever worked from. You can pretty much code it from the top of the spec to the bottom; when you get to the handshake patterns section and realize that each is just a different ordering of things in an array or whatnot, it's pretty slick.
FiloSottile 4y ago
Each Write encrypts a separate "record" (in the parlance of TLS and Noise). Each of those records can be arbitrarily dropped, replayed, or reflected. Here's an example, if you do Write("Hello") Write(" the password is ") Write("password") then without a key I can make you or your peer read "Hello the password is Hello" (or "HelloHelloHello" or any composition of those messages). No Noise protocol would allow that.
- ThePhysicist 4y ago
  Oh well, I did not realize he uses it like that.
d-z-m 4y ago
> If you want replay protection it's probably sufficient to either remember used keys or add a timestamp. The replay Filippo is talking about is in the context of a single key. The remote side simply reads the nonce || message off the wire and aead.Opens it, without regard to whether or not that nonce has been used before to decrypt a previous message.

tptacek 4y ago

Can you express this with Noise framework tokens? I don't think you can. Noise is fiddlier than it looks! It's not just an ordering of DH exchanges; it's transcript hashes, cipher state tracking (and reinitializing), key derivation, the whole 9. The temptation (at least for me) is to just skip to the table of handshakes and skim, but the actual protocol framework is in Section 5, where they define precisely what each of those tokens really entails. (To say nothing of: this uses signatures, and Noise does not).

deleted 4y ago
[deleted]
ThePhysicist 4y ago
Probably not, though Noise mentions that you could replace DH operations with signatures.
- tptacek 4y ago
  Yeah, I don't mean to be coy. You can't end up with this protocol using Noise. :)
  - ThePhysicist 4y ago
    ECIES is quite fine though for most asynchronous applications, where having a signing key also makes sense as you often want to publish long-lived, signed data and build a trust chain (e.g. generate and sign session keys from a master key). I built several real-world systems based on that (e.g. [1]) and they all made it through the audits fine. I was exploring Noise-based protocols but I find it's best to rely on primitives that are supported by the Web Crypto API. 1: https://github.com/kiebitz-oss/ https://github.com/kiebitz-oss/
    - tptacek 4y ago
      ECIES is a hybrid encryption construction; Noise is a protocol. They're two different levels of abstraction. This thing we're commenting on has a protocol; it's just an accidental one, which is usually not what you want. WebCrypto doesn't provide a protocol framework, just a bunch of primitives.
erincandescent 4y ago
Gotta say that I generally like the Noise framework (or rather the protocols that result), but it is one of the most impenetrable specifications I've ever read I don't remember what it is specifically about it, I just remember the document being a pain to read; a bit like the original Paxos paper in that regard.
- tptacek 4y ago
  I don't know about that. As an implementor, it is probably one of the easiest-to-follow specs I've ever worked from. You can pretty much code it from the top of the spec to the bottom; when you get to the handshake patterns section and realize that each is just a different ordering of things in an array or whatnot, it's pretty slick.

FiloSottile 4y ago

Each Write encrypts a separate "record" (in the parlance of TLS and Noise). Each of those records can be arbitrarily dropped, replayed, or reflected. Here's an example, if you do Write("Hello") Write(" the password is ") Write("password") then without a key I can make you or your peer read "Hello the password is Hello" (or "HelloHelloHello" or any composition of those messages). No Noise protocol would allow that.

ThePhysicist 4y ago
Oh well, I did not realize he uses it like that.

d-z-m 4y ago

> If you want replay protection it's probably sufficient to either remember used keys or add a timestamp. The replay Filippo is talking about is in the context of a single key. The remote side simply reads the nonce || message off the wire and aead.Opens it, without regard to whether or not that nonce has been used before to decrypt a previous message.