On Tue, 14 Dec 2010, Bob Beck wrote: > I wonder a lot about the motives of the original sender sending that message.
Ignoring motive, and looking at opportunity: We have never allowed US citizens or foreign citizens working in the US to hack on crypto code (Niels Provos used to make trips to Canada to develop OpenSSH for this reason), so direct interference in the crypto code is unlikely. It would also be fairly obvious - the crypto code works as pretty basic block transform API, and there aren't many places where one could smuggle key bytes out. We always used arcrandom() for generating random numbers when we needed them, so deliberate biases of key material, etc would be quite visible. So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material: 1. Ensure that key bytes somehow wind up as padding. This would be pretty obvious, since current IPsec standards require deterministic padding. Our legacy random padding uses arc4random_buf(). 2. Arrange for particular structures to be adjacent to interesting data, like raw or scheduled keys and "accidentally" copy too much. 3. Arrange for mbufs that previously contained plaintext or other interesting material to be "accidentally" reused. This seems to me the most likely avenue, and there have been bugs of this type found before. It's a pretty common mistake, so it is attractive for deniability, but it seems difficult to make this a reliable exploit. If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting :) 4. Introduce timing side-channel leaks. These weren't widely talked about back in 2000 (at least not in the public domain), but have been well researched in the years since then. We have already introduced countermeasures against the obvious memcmp() leaks using timingsafe_bcmp(), but more subtle leaks could still remain. If anyone is concerned that a backdoor may exist and is keen to audit the network stack, then these are the places I'd recommend starting from. -d
