6 ms·

Is it arrogant that I feel like I've basically invented this once before? The combination of asymmetric keys for identity and symmetric rotating keys for actual

Is it arrogant that I feel like I've basically invented this once before? The combination of asymmetric keys for identity and symmetric rotating keys for actual message sending is something that's just always made sense to me, but I never bothered trying to implement this since I was usually working in a web context and "just use HTTPS", was the better solution than trying to work out a custom scheme. [EDIT] - when I think about it, the management with kernel internals is definitely something I couldn't do. Writing kernel-level drivers/software is not my cup of tea.

hyper2grams 8y ago
>Is it arrogant that I feel like I've basically invented this once before? Probably.
- hardwaresofton 8y ago
  Yeah... -- reading the wireguard paper[0] now, and my cursory analysis ("oh this is like that time that I...") of how it works/what it needed to accomplish is suuuuper naive. [0]: https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
  - pvg 8y ago
    The mathematical foundations and power/elegance (and often even simplicity) of cryptographic primitives make it really easy to get the completely wrong idea about the difficulty and disturbing fragility of actual cryptographic engineering. Happens to pretty much everyone.
rubiquity 8y ago
All right, spill the beans. Which one are you? Diffie or Hellman?
- hardwaresofton 8y ago
  Haha I didn't mean I invented the key exchange mechanism -- just that after learning how easy it was to generate asymmetric public keys (on the shoulders of multiple giants), and how it easy it was to generate symmetric AES keys randomly (on the shoulders of more giants), I envisioned building services that would deliver public keys to a central repo and communicate over regular HTTP, but using encrypted payloads, and some MITM protection. I thought this was clever, then I realized I had just "discovered" HTTPS.
  - dogma1138 8y ago
    openssl genrsa 2048? ;) But in any case drafts for TLS over HTTP (also known as aTLS) exist: https://tools.ietf.org/html/draft-friel-tls-atls-00 https://tools.ietf.org/html/draft-friel-tls-atls-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00
    - hardwaresofton 8y ago
      Thanks so much for the pointer, those two drafts are now in my reading list!
  - rzzzt 8y ago
    It's giants all the way up, shoulder on shoulder.
Ao7bei3s 8y ago
Just naive, not arrogant (it's ok & encouraged to think through things yourself, even if there already is a solution. you can't expect to come up with actually new good things on day 1.). You've described the obvious part - this is in any crypto intro course. But it's not even getting the details of that right (which is _a_ challenge) that's interesting, because that's not where wireguard innovates. Well it does actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with IKE, else it's DIY) and, in a way, HTTPS already have working schemes. wireguard shines is other areas: the simple (factor 500 smaller code than IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN) implementation, ifaces instead of xfrm policies (for IPSEC. though that's not entirely far, you can have VTI's. they just don't scale well we've found.), the lessons learned wrt crypto agility (tl;dr: don't), implicit source verification, the beautiful DOS cookie implementation (feels nicer than TA key), that servers are silent/invisible unless you know their public key (cant provoke any response packets without), all connections are p2p. To name a few. Read the Wireguard paper. It's short and very approachable.
- tialaramex 8y ago
  > lessons learned wrt crypto agility (tl;dr: don't)" This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint. We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all. In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby. The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.
todd8 8y ago
I've had this feeling frequently in the past. Many years ago, when I was just learning computer science related concepts, I would be repeatedly surprised to see solutions discussed for which I had already had an inkling. It would usually turn out that my ideas weren't really novel or perhaps weren't really workable. With more experience and education this changed, and I've had an enjoyable career problem solving problem and inventing. Inventive minds like yours will often have insights that aren't original, but over time and with more practice, some of these will be original and practical and valuable, and you will more often have the satisfaction of making important discoveries.

hyper2grams 8y ago

>Is it arrogant that I feel like I've basically invented this once before? Probably.

hardwaresofton 8y ago
Yeah... -- reading the wireguard paper[0] now, and my cursory analysis ("oh this is like that time that I...") of how it works/what it needed to accomplish is suuuuper naive. [0]: https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
- pvg 8y ago
  The mathematical foundations and power/elegance (and often even simplicity) of cryptographic primitives make it really easy to get the completely wrong idea about the difficulty and disturbing fragility of actual cryptographic engineering. Happens to pretty much everyone.

rubiquity 8y ago

All right, spill the beans. Which one are you? Diffie or Hellman?

hardwaresofton 8y ago
Haha I didn't mean I invented the key exchange mechanism -- just that after learning how easy it was to generate asymmetric public keys (on the shoulders of multiple giants), and how it easy it was to generate symmetric AES keys randomly (on the shoulders of more giants), I envisioned building services that would deliver public keys to a central repo and communicate over regular HTTP, but using encrypted payloads, and some MITM protection. I thought this was clever, then I realized I had just "discovered" HTTPS.
- dogma1138 8y ago
  openssl genrsa 2048? ;) But in any case drafts for TLS over HTTP (also known as aTLS) exist: https://tools.ietf.org/html/draft-friel-tls-atls-00 https://tools.ietf.org/html/draft-friel-tls-atls-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00
  - hardwaresofton 8y ago
    Thanks so much for the pointer, those two drafts are now in my reading list!
- rzzzt 8y ago
  It's giants all the way up, shoulder on shoulder.

Ao7bei3s 8y ago

Just naive, not arrogant (it's ok & encouraged to think through things yourself, even if there already is a solution. you can't expect to come up with actually new good things on day 1.). You've described the obvious part - this is in any crypto intro course. But it's not even getting the details of that right (which is _a_ challenge) that's interesting, because that's not where wireguard innovates. Well it does actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with IKE, else it's DIY) and, in a way, HTTPS already have working schemes. wireguard shines is other areas: the simple (factor 500 smaller code than IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN) implementation, ifaces instead of xfrm policies (for IPSEC. though that's not entirely far, you can have VTI's. they just don't scale well we've found.), the lessons learned wrt crypto agility (tl;dr: don't), implicit source verification, the beautiful DOS cookie implementation (feels nicer than TA key), that servers are silent/invisible unless you know their public key (cant provoke any response packets without), all connections are p2p. To name a few. Read the Wireguard paper. It's short and very approachable.

tialaramex 8y ago
> lessons learned wrt crypto agility (tl;dr: don't)" This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint. We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all. In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby. The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.

todd8 8y ago

I've had this feeling frequently in the past. Many years ago, when I was just learning computer science related concepts, I would be repeatedly surprised to see solutions discussed for which I had already had an inkling. It would usually turn out that my ideas weren't really novel or perhaps weren't really workable. With more experience and education this changed, and I've had an enjoyable career problem solving problem and inventing. Inventive minds like yours will often have insights that aren't original, but over time and with more practice, some of these will be original and practical and valuable, and you will more often have the satisfaction of making important discoveries.