Subject: Re: [Cfrg] possibly dumb question about the opus codec and padding

From: David Wagner <[email-masked]>
Date: Thu, 7 Jun 2012 18:29:35 -0700 (PDT)

Jon Callas  wrote:
>> ....The lesson is: any time you encrypt, make sure you
>> use a mode of operation that is secure against chosen-ciphertext attacks.
>> Any time you encrypt, make sure you use a mode that provides authenticated
>> encryption.  Encryption without authentication is almost always a bad
>> idea.  Sadly, many software developers are not familiar with these
>> lessons.
>
>I don't disagree, and in fact, your last sentence is pretty much what
>I'm saying.

We may be drifting, but to come back to the original topic/question:

In my opinion, as long as you choose the cipher and modes of operation
reasonably, there's nothing wrong with having some known plaintext.
There's no great harm or risk to having lots of known plaintext in the
plaintext.  If there is some security benefit from having fixed padding
(e.g., increase in security against side channels), I think the original
poster should go for it, and not let concerns about known-plaintext
stop them.

Of course, if you don't choose the cipher or modes of operation
reasonably, you've got bigger problems....

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2012 12:57:40 +0100

> reasonably, you've got bigger problems....

The situation here is that the folks doing the work are defining
an audio codec that'll be used by all and sundry, certainly
including some who do unreasonable cryptographic things.

So simply saying "use proper crypto" arguably isn't enough of an
answer, though is clearly an important part of the answer. I guess
my original question might be better stated as: other than saying
"use proper crypto," what *else* should we be saying about known
plaintext (or padding specifically) in cases such as these when
we do know that dodgy crypto will get used sometimes?

Of course, maybe the full answer is "use proper crypto, or
else suffer the consequences":-)

Note as well that it appears that a bad actor on the network
could apparently manipulate things to cause padding events
in this particular case, perhaps by throttling bandwidth so that
the codec responds when in variable bit-rate (VBR) mode. I don't
really understand the details there yet, but am trying to find out.
There is already a recommendation in the document that constant
bit rate SHOULD be used for "highly sensitive" audio, but VBR will
get used a lot I'd expect.

Ta,
S.

---

From: Steven Bellovin <[email-masked]>
Date: Fri, 8 Jun 2012 13:08:26 -0400

> else suffer the consequences":-)

I think that that really is the only answer.  If there's one thing we've
learned about crypto over the years, it's that it's a really hard field,
with many opportunities for very subtle mistakes.  "Finally, protocols 
such as those developed here are prone to extremely subtle errors that 
are unlikely to be detected in normal operation. The need for techniques 
to verify the correctness of such protocols is great, and we encourage 
those interested in such problems to con- sider this area."  This is
from the classic 1978 Needham and Schroeder paper.  It was a remarkably
prescient statement.  Maybe some day things will be understood well enough
that warnings like this aren't necessary.  That day won't be soon.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb