The OCB2 authenticated encryption scheme (ISO standard) has been broken
eprint.iacr.org
eprint.iacr.org
Also, Internet cryptosystems generally don't use OCB at all, despite its elegance and performance, because of IPR issues.
The second thing you want to know (and you want to know it waaaaaay less than the first thing) is that this breaks authentication, not confidentiality; you can't use the attack to directly "decrypt" OCB2 messages, just to forge messages derived from a leaked plaintext/ciphertext pair.
This is a big deal for crypto people, though; see 'pbsd comment for more.
We present practical attacks against OCB2
an ISO-standard authenticated encryption (AE) scheme.
OCB2 is a highly-efficient blockcipher mode of
operation. It has been extensively studied and widely
believed to be secure thanks to the provable security
proofs.
Our attacks allows the adversary to create forgeries
with (almost-known) single encryption query.
Still terrifying. What other proofs of security and/or correctness are false and/or don't prove what we think they do?
mosh is using AES-OCB, but seems to be using OCB3 from what I can tell:
https://github.com/mobile-shell/mosh/blob/944fd6c796338235c4...
(1) OCB has long had a patent grant for GPLed software (https://github.com/mobile-shell/mosh/blob/master/ocb-license...), so the Rogaway patents were a non-issue even in 2011. (Of course there are other patents on authenticated encryption, e.g. IBM's Jutla patents. I understand why OCB gets singled out because of the Rogaway patents, but my understanding is that all AE modes, and perhaps most computer programs in general, likely implicate some patent.)
(2) The crypto experts told us that OCB was the best AEAD mode and that if we are going to put all our eggs in one basket, we should pick OCB. I am pretty happy with the choice and with the lack of traditional cipher negotiation in Mosh.
(3) Implementation quality strongly favored OCB. At the time, OpenSSL had no AE modes at all, so we probably would have had to vendor and ship an implementation of something not-OCB, or use a non-AE construction. I understand OpenSSL had a lot of pain implementing GCM in a robust way over the subsequent years -- if we had depended on OpenSSL or tried to use its AE modes, we would have inherited that pain.
Given our position of wanting to pick one mode and lock it in (which seems to have paid off), I don't think we could have made a better choice in 2011 than AES-OCB. I might make the same choice today, but would look harder at the other available AE modes in OpenSSL.
I wanted to learn a little bit more about progress towards verified implementations (i.e. deriving the implementation automatically from its proof) and found a nice summary here:
https://crypto.stackexchange.com/questions/34304/formal-veri...
Of course, there's proof assistants etc that can construct an implementation, but even in this cryptography context, where it's desperately worth it, they're too difficult/too much work.
Unless you really understand the maths deeply, it's difficult to be sure you got it right (and even if you do). Especially when it's not easily decomposable into independently verifiable modules.
The funny thing is, when you write straightforward code, and try it a few times (even, enshrine those as "tests"), you will feel that it is right. But there's not really that much certainty that you really did get it right.
Leading me to believe the crucial thing isn't how difficult it is to get it right, but how much it matters. Software "bug reports" are ubiquitous. Not so for cryptography!
Indeed. Lack of associativity and distributivity when working with floating point numbers gives the whole thing a feeling of spooky witchcraft.
It's precisely the same feeling that I get from Javascript and PHP's weird notions of equality ("==" vs "===").
The scary thing here is not so much the error in the proof, which does not have many repercussions beyond OCB2, but that it went 14 years without being discovered. This despite the OCB2 paper, which introduced XEX, being highly influential. Every time something like this happens, confidence on the security of all "provably secure" schemes is undermined.
Put in an other way, provably secure schemes only guarantee what had been proved.
Sometimes an inventor can make a little bit of money from a crypto patent, but to do it you need to get an organization like the U.S. DoD to pay for it, and that's not easy.
It's a lot easier to use one's cryptographic innovations to burnish one's reputation and leverage that into very high consulting rates, say, or founding a startup.
(Another good AEAD alternative today is Chacha20+Poly1305, standardized in IETF RFC 8439 (née RFC 7539).)
No they aren't? The two recent patents are from 2011 and 2012 (filed 2007 and 2011) -- which by my IANAL read -- means they don't expire until 2027 and 2031.
And even if they were nearly expired, it's just not significant or responsive to my comment. They have been under patent for most of their lifetime, they're still under patent; hence they have seen little use when viable alternatives exist.