4 ms·
The OCB2 authenticated encryption scheme (ISO standard) has been broken
- hkai 8y agoWhere is it used and what is under threat now?
- bradleyjg 8y agoI believe it is pretty uncommon, mostly because the inventor patented it.
- cryptonector 8y agoIn the world of cryptography, patents are the kiss of death. If you patent an algorithm and do not provide royalty free, non-exclusive, transferable, permanent grants, then no one (or very very few people) will use that algorithm. 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.
- deleted 8y ago[deleted]
- loeg 8y ago[Edit: OCB in general] is almost entirely unused due to the patents around it. Instead, people ended up using GMAC (e.g., AES-GCM mode) for the most part. (Another good AEAD alternative today is Chacha20+Poly1305, standardized in IETF RFC 8439 (née RFC 7539).)
- tptacek 8y agoIt is also virtually entirely unused because it was superseded by OCB3.
- loeg 8y agoAh, sorry for the confusion. I was referring to the entire group of OCB modes, not just OCB2. Edited my comment to reflect that.
- yuhong 8y agoThe patents are almost expired by now though.
- loeg 8y ago> The patents are almost expired by now though. 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.
- erwan 8y agoWe 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. What I find most fascinating is that OCB2 is a scheme for which there has been a security proof since 2003. I am neither a cryptographer nor up-to-date with the state of the art in cryptanalysis, but at first glance, it seems like most attacks discovered these days rely on some kind of side channel or unspecified aspects of the protocol that the implementations get wrong. Even djb (cryp.to) is spooked: https://twitter.com/hashbreaker/status/1057791485016526848 https://twitter.com/hashbreaker/status/1057791485016526848
- AnimalMuppet 8y agoSo the proof is erroneous, or it doesn't prove what it was thought to prove, or the attack uses a technique that doesn't fall within the scope of the proof - or else the attack doesn't actually work. Still terrifying. What other proofs of security and/or correctness are false and/or don't prove what we think they do?
- kpcyrd 8y agoFor anybody else wondering about the reply to that tweet: mosh is using AES-OCB, but seems to be using OCB3 from what I can tell: https://github.com/mobile-shell/mosh/blob/944fd6c796338235c4f3d8daf4959ff658f12760/src/crypto/ocb.cc https://github.com/mobile-shell/mosh/blob/944fd6c796338235c4...
- tptacek 8y agoIt would be more surprising to find open-source crypto that used OCB2 at all than it would be to find open-source crypto that was practically vulnerable to this attack. The open source patent release for OCB is younger than OCB3.
- keithwinstein 8y agoYes, Mosh definitely uses OCB3 and is apparently unaffected (just added a FAQ to the website). Still pretty scary though -- this could easily have been Mosh's first real security vulnerability and it would have sucked. We first implemented Mosh's crypto in 2011, shortly after OCB3 was released. If I had started working on Mosh six months earlier, I probably would have picked OCB2.
- kiwidrew 8y agoSo it turns out that the attack "was possible due to the discrepancy between the proof of OCB2 and the actual construction" (according to the paper). That's a scary thought. 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-verification-in-cryptography/34326#34326 https://crypto.stackexchange.com/questions/34304/formal-veri...
- hyperpallium 8y agoThis is what makes me so uncomfortable about numerical computing (e.g. CFD): how do you know you got it right? If you implement a fluid simulation, it might look right... but is it right? 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!
- kiwidrew 8y ago> This is what makes me so uncomfortable about numerical computing (e.g. CFD): how do you know you got it right? 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 "===").
- mannykannot 8y agoIt is not my field, but I would guess that in the case of computational physics, the need for the results to be realistic (conforming to conservation and thermodynamic laws, for example) would help in verification.
- pbsd 8y agoOCB2 is not a block cipher; it is an authenticated encryption scheme built on top of one. 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.
- lifthrasiir 8y ago> 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.
- bcaa7f3a8bbc 8y agoOCB2 is not a cipher, but a mode, like CBC, GCM, XTS, etc.
- erwan 8y agoEdited the title, thanks!
- tptacek 8y agoThe first thing you want to know about this is that OCB3, which supersedes OCB2 and is going on 10 years old now, is not affected by this attack. The IETF RFC for OCB is OCB3. 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.
- __s 8y agoLink to pbsd's comment: https://news.ycombinator.com/item?id=18350968 https://news.ycombinator.com/item?id=18350968