
The OCB2 authenticated encryption scheme (ISO standard) has been broken - erwan
https://eprint.iacr.org/2018/1040
======
tptacek
The 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
Link to pbsd's comment:
[https://news.ycombinator.com/item?id=18350968](https://news.ycombinator.com/item?id=18350968)

------
erwan

        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.
    

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)

~~~
kpcyrd
For 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/944fd6c796338235c4...](https://github.com/mobile-
shell/mosh/blob/944fd6c796338235c4f3d8daf4959ff658f12760/src/crypto/ocb.cc)

~~~
keithwinstein
Yes, 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.

~~~
loeg
What reasons lead you to select any OCB variant in 2011? Not trying to be
snarky -- I am genuinely curious, given the patent landscape at that time and
lack of any open source grant.

~~~
keithwinstein
Reasonable question!

(1) OCB has long had a patent grant for GPLed software
([https://github.com/mobile-shell/mosh/blob/master/ocb-
license...](https://github.com/mobile-shell/mosh/blob/master/ocb-
license.html)), 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.

~~~
loeg
Thanks! The details really help me understand the options available and why
the choice was made. I appreciate your taking the time to answer the question
thoroughly.

------
kiwidrew
So 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-
veri...](https://crypto.stackexchange.com/questions/34304/formal-verification-
in-cryptography/34326#34326)

~~~
hyperpallium
This 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
> 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 "===").

------
pbsd
OCB2 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
> 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
OCB2 is not a cipher, but a mode, like CBC, GCM, XTS, etc.

~~~
erwan
Edited the title, thanks!

------
hkai
Where is it used and what is under threat now?

~~~
loeg
[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
It is also virtually entirely unused because it was superseded by OCB3.

~~~
loeg
Ah, sorry for the confusion. I was referring to the entire group of OCB modes,
not just OCB2. Edited my comment to reflect that.

