I’m sure I don’t need to remind anyone what this is about…
The latest news: Theo now says that it is probable that NetSec was indeed contracted to insert backdoor code into OpenBSD, but after a month of review and changelog archeology, there is still no sign that they succeeded or even attempted to push tainted code into the tree.
The audit (which is still ongoing) did uncover one serious bug, but there is no reason to believe that it was planted deliberately. This relates to CBC mode, an encryption protocol in which each block of plaintext is combined with the ciphertext of the previous block before encryption to make it harder to attack ciphertext blocks individually.
If I understand Theo’s message correctly,
- It used to be common practice to use the last ciphertext block from one message as IV for the next message. This seemed like a good idea at the time, because the alternative is to generate a random IV for each new message, which requires a strong, fast PRNG, and strong, fast PRNGs didn’t grow on trees back when this scheme was devised. By reusing the last ciphertext block from the previous message, a costly random IV was only required for the very first message.
- This practice was discovered to be a bad idea because in n – 1 out of n cases (where n is the block size in bytes), the last plaintext block of any message encrypted with a block cipher contains somewhat predictable padding.
- The flawed IV logic was replicated in several parts of the OpenBSD source tree, and the fix was implemented in some of them, but not all.
- The person who implemented this flawed logic was at that time a NetSec employee, but he had been involved in the development of OpenBSD’s IPSec stack for years before he was hired, and, as previously mentioned, he was only following common practice.
- The same person implemented the obvious fix (generating a new, random IV for every message) once the attack was discovered.
- The person responsible for those parts of the tree in which the fix was not implemented is one of the people fingered by Perry, but his tenure started after Perry had left and ended before the attack was discovered.
- Anyone with any amount of experience in a large F/OSS project, or any large software development effort for that matter, can tell you that this kind of oversight is the rule rather than the exception. Although there is no evidence that he did not intentionally “forget” to fix his code, it is far more likely that he simply did not realize that the fix that had already been committed did not extend to his own code, or that he wasn’t paying attention, and nobody else noticed.
My bounty still stands, and I will even relax the requirements a bit: you are not required to show that OpenBSD is still exploitable, only that it was exploitable on December 11, 2010 (the date of Perry’s email to Theo).
AFAIK there is no requirement for IVs to be random, they just should not repeat. Provable security can be attained just by using a counter. IIRC, Practical Cryptography also recommends a simple counter that must never overflow and is reset for every new session key. IKE is perfectly aware of this session key life time and will negotiate new keys on demand.
I’m not sure what you mean by “requirement”; CBC will still work if you use your mother’s maiden name as IV, but it’s obviously not a good idea. I’m not sure a counter is a good idea either, since a counter, by definition, is highly predictable. A good PRNG, by definition, is not. OpenBSD uses arc4random, which is not cryptographically strong but has the advantage of being very fast.
You are, I believe, wildly incorrect in this post. There is a crypto weakness in OpenBSD’s old CBC code related to IV’s and called an “oracle”. It is not, as you imply, a “padding oracle”. The issue with OpenBSD’s code — and it was a common issue at the time it was first identified in OpenBSD — is that IVs were predictable. When IVs are predictable AND attackers can coerce a target into encrypting a block of known plaintext (the “oracle” here), they can use that capability to conduct on-line dictionary attacks against previous blocks.
This is a slow and not particularly interesting attack, unlike the CBC oracle that involves padding, which is devastating.
I explained this point in some detail here:
http://news.ycombinator.com/item?id=2029640
Two points:
1) I wrote this under the assumption that the IV is supposed to be secret, which it isn’t, and I knew it isn’t (blame sleep deprivation), so yes, my description is “wildly incorrect”, but
2) I fail to see how this invalidates the rest of my post, since the exact nature of the bug is not important. Feel free to just ignore everything after “bad idea” in the second bullet point.
Another important correction: the first of the two developers I mentioned was not a NetSec employee, but received funding from NetSec to continue his work on OpenBSD’s IPSec stack. This is a very important distinction (I’ve been in that position myself, with FreeBSD and OpenPAM).
Finally: this is actually old news, but it only recently surfaced in my inbox, and I didn’t check the date too closely.
The vulnerability that actually existed in the OpenBSD tree simply doesn’t matter in the real world. A CBC padding oracle would matter a great deal. The reason it’s worth pointing this out is, the CBC IV mistake made by OpenBSD is virtually certain not to be deliberate; what would be the point?
OK, conceded, while the nature of the bug is not important, its severity is.