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

[Ben Laurie]

On Wed, Apr 25, 2012 at 7:17 PM, Zooko Wilcox-O'Hearn <zooko at zooko.com>wrote:

> 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" ².)
>

This is exactly what I thought you meant.



> 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.
>

OK, but that is not the confusing part of the post. The confusing part is
where you say "this is no use for Tahoe" but then don't go on to say why!
I'd really like to see some flesh on the claim...

Alternatively, its not confusing at all, and what you're saying is that
authenticated encryption does not directly provide a way to, for
example, "authorize
you to check the integrity of a file (ciphertext) without authorizing you
to read it". OK, but so what? That's not a property of authenticated
encryption, as formally defined. If you want some other system, then you
... want some other system. This just seems like an uninteresting truth to
me.



>
> 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.
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120426/389ae775/attachment.html>