[tahoe-dev] “On the limits of the use cases for authenticated encryption”

Zooko Wilcox-O'Hearn zooko at zooko.com
Wed Apr 25 18:17:18 UTC 2012


Hi Ben! Glad to have you posting to this list.

I believe you're the architect of one of those libraries I mentioned
-- Keyczar, which doesn't offer an unauthenticated encryption feature
at all in its API. (As well as, of course, the author of several other
good technical ideas and tools that I like.)

On Wed, Apr 25, 2012 at 6:50 AM, Ben Laurie <ben at links.org> wrote:
>
> For case 1, presumably authenticated encryption can (and probably is) be used as part of the protocols, so I don't get it.

I think I see the misunderstanding. By "authenticated encryption", I
didn't mean any system that guarantees both integrity and
confidentiality. I meant a specific abstraction, in which a single
algorithm, or a single layer of the system, provides confidentiality
and integrity, predicated upon knowledge of a single key which is
known to both endpoints. It is this abstraction that is formalized by
papers like Bellare-2000-“Authenticated Encryption: Relations among
notions and analysis of the generic composition paradigm” ¹, and which
is provided by modes like OCB mode, ciphers like Phelix, and libraries
like Keyczar. (See, for example, Wikipedia's definition of
"Authenticated Encryption" ².)

The thing that I find interesting is that this abstraction is of no
use in building the Tahoe-LAFS access control semantics. That is: we
started with the notions of symmetric encryption (AES in CTR mode),
public key digital signatures, and secure hashes (collision-resistant,
pre-image resistant, second-pre-image resistant, and pseudorandom),
and built the Tahoe-LAFS semantics out of those three things. The
addition of authenticated encryption (in this sense) to that toolkit
would not have helped. In fact, we were aware of authenticated
encryption at the time and chose not to use it.

As another perspective, if someone were to write something
Tahoe-LAFS-like semantics using Keyczar, that person wouldn't benefit
from the automatic MAC-checking feature built into the Keyczar API.
They would still need to develop some of their own protocol, using
some algorithms that are not provided by the Keyczar API, such as
secure hashing.

I think I'll update my Google+ post to clarify that when I write
"authenticated encryption" in that post, I mean this particular
abstraction.

Regards,

Zooko

¹ Bellare-2000-“Authenticated Encryption: Relations among notions and
analysis of the generic composition paradigm”:
http://cseweb.ucsd.edu/~mihir/papers/oem.html
² https://en.wikipedia.org/wiki/Authenticated_encryption says
"Authenticated Encryption (AE) is a block cipher mode of operation
which simultaneously provides confidentiality, integrity and
authenticity assurances on the data."

I hate to cite Wikipedia as an authority (note that the definition is
too narrow and excludes Phelix, and what's the meaning of listing
"integrity" and "authenticity" separately?), but for better or worse a
lot of people follow it and I don't know of a better authority to use
for this purpose.


More information about the tahoe-dev mailing list