zx2c4: every time i send you something, i expect to hear back from you. if i dont hear back from you, then something bad has happened,and i should start over with a new handshake. my way of hearing back to you might be in the natural sense -- i send a TCP SYN, you send me back a TCP ACK -- or it might be the case that you actually just have nothing to send back to me. you got my message just fine, but really just cant think of anything to say back to me.

zx2c4: also, btw, when you're not using the payload parameter in a message, it's just set to empty, because the authentication tag used by it is still important for the protocol.

zx2c4: pretty unlikely that somebody would design a protocol inadvertently that way

zx2c4: one thing to keep in mind is that Noise isn't a single ready-made protocol for every application designer to take. its instead a protocol framework for protocol designers to use. knowing explicitly what the payload param gives you in each message is really important, so that you dont screw up and put your stuff somewhere it shouldnt be. there are legitimate protocol use cases for using the payload parameter early on during the handshake. its

zx2c4: this is not the case of the "null mode" in IPsec, which is obviously a complete disaster with no good justification

zx2c4: there are valid use cases of sending information in the clear in the payload parameter. for example, perhaps you want to use it to advertise which aspects of the protocol are valid for subsequent messages. or you want to send a certificate along to authenticate yourself. the payload parameter certainly shouldnt be confused with transport messages, which are what are allowed after the handshake completes

zx2c4: its not an "unsecured mode" because this isnt a "mode"

zx2c4: but there's certainly not any "null-ciphering" and this is only a misunderstanding of what the specification says

zx2c4: noise defines several different handshakes. wireguard uses Noise_IKpsk2, which is 1-RTT. But there are other noise handshakes, some of which are 0-RTT, 1-RTT, 2-RTT, 1.5-RTT, and so forth. each handshake message can optionally contain a payload -- to contain things like, say, certificates or other data. the question is at which stage of the handshake do you use the payload parameter? if you do it too early in some, you get zero confidentiality. so

zx2c4: a null cipher mode? it doesnt...

zx2c4: im guessing deedbot will send me a otp now

zx2c4: if you guys wind up using wireguard for part of your infra and want to support wireguard for a year, i'm always looking for large donations, etc. not sure if that's what deedbot is for exactly but that would be quite the nice deed

zx2c4: we've been going at it for a while here

zx2c4: i havent compiled a list of Name+WrittenReview. maybe i should do that ☟︎

zx2c4: then in the acknowledgement of the paper, a few others arementioned who reviewed it while it was being written

zx2c4: its in a much better place than just raw md5

zx2c4: so it's received quite a bit of scrutiny

zx2c4: blake2 came from blake which went through the sha3 contest as a finalist

zx2c4: but anyway, the world has learned quite a bit since md5

zx2c4: seems like there are many places and interesting ways to optimize at this point. lots of neat creative work coming out. but that with aes and whatnot, we're in a pretty good place in terms of symmetric crypto

zx2c4: things like RSA boil down to number theory problems. but that's in a sense scarier than the set of problems that good block ciphers tend to boil down to. because it means that those primitives have lots of _structure_, and generally structure is something that can be exploited. just look at all the amazing and fantastic attacks on things with structure. so just boiling down to a [currently considered] "hard problem" doesn't provide as much solace ☟︎

zx2c4: found a vuln!

zx2c4: by only using a limited subset of constructs which are known to be constant time

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

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

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: - 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: - denial of service resistance. as mentioned, you should be able to put this on the outer edge of a network

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: 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: 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