zx2c4: fiat-crypto also has a 64bit one, but the HACL* one was faster

zx2c4: our two x25519 C implementations (32bit and 64bit) are actually generated by theorem proving software, so that we're sure they dont contain any errors ☟︎

zx2c4: another advantage of DH over RSA is that ECDH allows for really short and sweet keys

zx2c4: which can take entropy from trngs bla bla

zx2c4: (i've got a project going on right now to rewrite that actually)

zx2c4: in otherwords, the kernel's built-in RNG

zx2c4: or some combination of the above

zx2c4: when the RNG is backdoored, the ephemerals are compromised, but not necessarily the statics

zx2c4: for example, when your static longterm keys are compromised, but the ephemeral keys have not been compromised, since they're erased/renewed every 2 minutes

zx2c4: key compromise impersonation is what happens when somebody steals your private key, and then can impersonate anybody else _to_ you

zx2c4: - authentication in the first message, so that unauthenticated packets arent replied to, hence ensuring things are stealthy

zx2c4: so for the handshake we want these properties in 1-RTT:

zx2c4: - wireguard doesnt expose any state to the administrator. there's either an interface or there isnt. theres no concept of "connection". with a very simple timer state machine, we're able to completely hide all details from the sender side

zx2c4: - wireguard isn't chatty. when you're not sending traffic, it shuts up and you cant tell its there

zx2c4: KEMs like RSA are more complicated to implement in as few round trips as DH-based protocols

zx2c4: ive got some more design properties to enumerate if you'd like, but i can answer your direct questions too

zx2c4: asciilifeform: i agreed to stick around for 2 hours. worry not. :P

zx2c4: - the whole cryptokey routing table thing is very important for making things extremely simple. it pairs the identity of a public key with the ip address someone is allowed to be inside the tunnel. no fancy security marks or whatever from ipsec bloat

zx2c4: asciilifeform: oh cool. i havent seen this ill take a look

zx2c4: - ease of system administration. since its interface-based, things like iptables and whatnot work as you'd expect.

zx2c4: - extremely simple configuration interface. short base64 25519 pubkeys you can paste around through any means. simple config files. everything happens on the interface level.

zx2c4: indeed. i guess you could call the property 'stealthiness'

zx2c4: - denial of service resistance. as mentioned, you should be able to put this on the outer edge of a network

zx2c4: - no dynamic memory allocation. all the memory used by wireguard should be allocated at configuration time, not in response to incoming packets.

zx2c4: - minimal state machine, as mentioned above, which means 1-RTT: if something goes wrong with a message being dropped, the solution is always to just "start over the protocol", since it's only 1-RTT. this saves amazing amounts of complexity ☟︎

zx2c4: - silent to unauthorized packets. if you dont know there's a wireguard endpoint there and don't have credentials to talk to it, you can't get it to respond to anything. so, you cant scan for endpoints. this makes it a good thing to put on the outer edge of your network.

zx2c4: then on top of that i wanted a few nice properties:

zx2c4: to make something that would make this all possible

zx2c4: wireguard is supposed to be implementable using simple algorithms with as small of a state machine as possible, so that the code size and complexity is kept at a minimum. in otherwords, it aims to be easily auditable so that people can actually read it and feel confident that it doesnt have horrible vulnerabilities. with massive codebases and highly complex designs like openvpn or ipsec, this obviously isnt possible. so with wireguard i was trying

zx2c4: are you interested in learning about the security properties i had in mind when designing wireguard?

zx2c4: it's small, minimal, has the flexibility to be exactly what i needed and nothing larger. makes conservative choices. fits into the security model i was aiming for with the implementation properties i was looking for. i was also involved with noise from very early on, so several concerns and needs i had with wireguard got factored into noise. and since noise is a very interesting framework, it's now receiving much needed academic attention in

zx2c4: hello. mircea_popescu asked me to come here for two hours to field some questions about wireguard from you all. i'm not very familiar with this channel or the community in it, but i am happy to talk to whomever about wireguard. so let's start the timer now?