5 ms·

> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it eas

> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc. The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that calls the lower level "wg" command instead of "wg-quick". Alternatively, you can write a script that generates a wg-quick configuration file.

zx2c4 8y ago
Exactly this. WireGuard and wg(8) are meant as building blocks. For example, the wg-quick(8) tool is a simple bash script I built out of wg(8) and ip(8) that mostly works for my use cases and those of some other folks. But if you want something more complicated, then it's supposed to be easy to build that out of the building blocks presented.
chasil 8y ago
What I am wondering is why they chose 25519. It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-1-Submissions https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...
- tialaramex 8y ago
  Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm. NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".
  - chasil 8y ago
    The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update." ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable. On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems. Android, however, cannot do that. p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway. "In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."
    - tialaramex 8y ago
      If you believe that demanding agility is "far from unreasonable" I strongly recommend taking that line rather than insisting people should use relatively untried shiny new toys out of fear of a monster that may not actually be under their beds. I don't know that WireGuard's author will agree, but you at least have a coherent argument that makes sense. Replacing 25519 with NTRU because you're terrified of a bogeyman (in the form of Quantum Computers able to run an algorithm that solves the appropriate hard problem) doesn't make sense.
      - chasil 8y ago
        I never said "instead of," although I can see in hindsight why it might be seen that way. I should have been more clear. Wireguard could have used P521 and AES-GCM with similar security, but it would be slower and equally vulnerable.
    - zx2c4 8y ago
      You can use WireGuard with rather expensive but conservative PQ primitives like Classic McEliece using the PSK feature of WireGuard, giving you hybrid PQ secrecy. The PSK feature was explicitly designed for this. The idea is that first you create a normal WireGuard tunnel. Then _through it_, so that it's authenticated, maybe even over boring old TCP, you negotiate your potpourri of experimental post quantum exchanges, maybe several of them if you don't want to trust a first round NIST submission right off the bat. Then you put the resultant key from this into WireGuard's PSK slot, and voila, now you have post quantum forward secrecy. The Noise protocol framework (on which WireGuard is based) is now looking into doing PQ authentication, so that will be interesting. But until we actually have a clue which PQ primitives to use and have spent some time working out PQ handshakes, I think it's best to keep this all separate and ad-hoc, making it possible with the simple PSK feature.

zx2c4 8y ago

Exactly this. WireGuard and wg(8) are meant as building blocks. For example, the wg-quick(8) tool is a simple bash script I built out of wg(8) and ip(8) that mostly works for my use cases and those of some other folks. But if you want something more complicated, then it's supposed to be easy to build that out of the building blocks presented.

chasil 8y ago

What I am wondering is why they chose 25519. It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-1-Submissions https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...

tialaramex 8y ago
Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm. NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".
- chasil 8y ago
  The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update." ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable. On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems. Android, however, cannot do that. p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway. "In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."
  - tialaramex 8y ago
    If you believe that demanding agility is "far from unreasonable" I strongly recommend taking that line rather than insisting people should use relatively untried shiny new toys out of fear of a monster that may not actually be under their beds. I don't know that WireGuard's author will agree, but you at least have a coherent argument that makes sense. Replacing 25519 with NTRU because you're terrified of a bogeyman (in the form of Quantum Computers able to run an algorithm that solves the appropriate hard problem) doesn't make sense.
    - chasil 8y ago
      I never said "instead of," although I can see in hindsight why it might be seen that way. I should have been more clear. Wireguard could have used P521 and AES-GCM with similar security, but it would be slower and equally vulnerable.
  - zx2c4 8y ago
    You can use WireGuard with rather expensive but conservative PQ primitives like Classic McEliece using the PSK feature of WireGuard, giving you hybrid PQ secrecy. The PSK feature was explicitly designed for this. The idea is that first you create a normal WireGuard tunnel. Then _through it_, so that it's authenticated, maybe even over boring old TCP, you negotiate your potpourri of experimental post quantum exchanges, maybe several of them if you don't want to trust a first round NIST submission right off the bat. Then you put the resultant key from this into WireGuard's PSK slot, and voila, now you have post quantum forward secrecy. The Noise protocol framework (on which WireGuard is based) is now looking into doing PQ authentication, so that will be interesting. But until we actually have a clue which PQ primitives to use and have spent some time working out PQ handshakes, I think it's best to keep this all separate and ad-hoc, making it possible with the simple PSK feature.