Disclaimer: I'm definitely no crypto expert I've never even looked at the 0mq implementation. But I *have* spent a lot of time studying the original reference implementation. So that might be worth something.
Then again, it probably isn't much. It's been months since I looked at the handshake part of the protocol. I know Pieter at least planned some changes from the reference implementation. I don't remember what they were off the top of my head, or whether they were ever implemented. It seems like one of those changes was to include the public key with every packet (at least for the handshake) so you'd know right away who was on the other side. I never saw a crypto expert weigh in on whether this was a good idea or not. Either way, "knowing" who's on the other side (because you know their public key) is one of the big selling points for the entire protocol. At that point, your system's busted wide open with no good way to tell the good guys from the bad guys. Is that a serious concern? Is it really the worst danger? Beats me. (more inline) > > On 12/15/2017 02:39 PM, Luca Boccassi wrote: >> As far as I remember (haven't looked at the code in a good while) the >> session keys are not derived from the public keys. Surely no one would have made *that* change to the protocol. > Not derived from, but the key exchange used to arrived as a secret that > an observer can't infer is dependent on the keys being secret from an > observer. > > I'm worried the math the does that hiding might break if both sides use > the same keys. Mathematically, I think the biggest risk would be nonce collisions in one of those bits that's encrypted with that shared long-term key. I'm pretty sure that, if an attacker can ever capture 2 messages encrypted with the same private key/nonce pair, then it's pretty easy to get the private key. > Seems not to be an immediate concern, I won't be adding encryption right > away, and if I later do, I can probably use unique keys throughout the > system just to be safe. That's your best bet. > Mortals should not design cryptography, Exactly. > and something so odd as doing a > D-H key exchange with oneself (effectively what I am considering) is > probably dangerous. It definitely seems dubious. For your specific use-case, you could probably get by with a simplified version of the CurveCP handshake. They don't need to swap public/private keys, since those are already known at each end-point. Exchanging short-term session keys in that scenario seems like it ought to be significantly simpler/safer. Then don't worry about zeromq's encryption layer. Just encrypt each message using NaCl's cryptobox functions. I *think* that's really just communications protocol. Then again, you already said it: "Mortals should not design cryptography." > Thanks, > > -kb > > Regards, James _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
