On Wed, May 2, 2012 at 7:00 PM, D. J. Bernstein <d...@cr.yp.to> wrote: > > also asks for submissions discussing requirements---what users actually want. > Submissions of panel proposals, white papers, lists of desiderata, etc. are > encouraged, and there are no particular length requirements.
Thank you for the invitation. I seriously considered submitting my use-cases, but I stopped when I saw that I would have to be willing to present it in Stockholm. That would be extremely fun! But I can't commit to that at this time. Below is discussion of the sort of topic that I would have wanted to submit. > Zooko Wilcox-O'Hearn writes: >> authenticated encryption can't satisfy any of my use cases! > > Of course it can! No more so than unauthenticated encryption does. Is it possible for there to be a form of "authenticated encryption" that helps with my use cases more than unauthenticated encryption does? See below... > Evidently you to want to combine it with public-key signatures, Sometimes we want to combine encryption with public-key signatures, and often we want to combine it with secure-hash-based data identification. More about that below. > which will render the secret-key authenticator useless, so for efficiency > you'd like to suppress that authenticator. Yes, and also for simplicity. It can be difficult for people to understand the integrity and access-control properties, and the addition of an unused authenticator would make it harder. > To summarize: Yes, non-cryptographic security is a disaster, but cryptography > is a disaster too. :-) :-) So, here's a question: could there be a notion of "authenticated encryption" which did help with the Tahoe-LAFS use case more than unauthenticated encryption does? The problem with the current notion of "authenticated encryption" for my use case, is that it packs too much authority into one bundle. (This is in terms of "authority analysis", which I learned from Miller-2003 ¹.) Option A: symmetric-key MAC The current notion of authenticated encryption has a single secret key which I can either give to a person or withhold from them. If I give someone this symmetric key, I empower them to do at least three things: 1. Decrypt the data, 2. Verify the integrity of the data, 3. Generate MAC tags for other data which would pass the integrity check. The fact that 3 is included in that bundle of authority means that I can't use this notion of authenticated encryption to implement any of the current Tahoe-LAFS filesystem semantics. We need to be able to grant authorities 1 and 2 while withholding 3. Is it possible to have a notion of "authenticated encryption" which empowers the recipient to do 1 and 2 but not 3? Yes! But it requires other trade-offs. Option B: digital signature The identifier of the data (the identifier of the message, channel, or file) includes a public key, and each message (or each version of the file) includes a digital signature on a secure hash of the data. This achieves the goals of granting 1 and 2 but not 3. It has significant efficiency costs and introduces security assumptions about the difficulty of some trapdoor function or other. It also means that the person who has the authority to sign a message can do so for multiple, new messages. Option C: identify the data by secure hash The identifier of the data (the identifier of the message or file) includes a secure hash of the data. This achieves the goals of granting 1 and 2 but not 3. It is very efficient and its security assumes only the second-pre-image-resistance of a hash function. It also means that the person who has the authority to sign the message can *not* sign new messages, and must know the complete message before they generate its identifier. (The strong form of that statement requires strengthening the assumption about the hash function from second-pre-image-resistance to collision-resistance.) This is a major constraint, and at first glance you might think "Well, you've just traded away all sorts of flexibility that everyone needs. Uninteresting. Next!". However, it turns out that this can also be a *useful* constraint, because it means that the data is immutable once transmitted, even to someone who has all of the secrets that the original sender had. The data is immutable with regard to its identifier, which is the secure hash of the data. Contrast with Option B, which has the same authority consequences (property 2 but not property 3) but in which the data is mutable with regard to its identifier, which is the public key. In practice, in Tahoe-LAFS, we implement Option B and Option C. (We got these ideas from Freenet, Secure File System, informally published ideas from Eric Hughes and others on the cypherpunks list, and probably other sources.) In Tahoe-LAFS, whenever you write a file, you get to choose which of those two ways to do it. The default, and the most commonly-used option is C -- an "immutable file", the identifier of which includes a secure hash of its contents. Basically, almost all files that users actually store in Tahoe-LAFS are stored in immutable form, and Option B -- mutable -- is typically used only for directories that contain pointers to a bunch of (typically mutable) subdirectories and (typically immutable) files. This technique -- immutable reference by using the secure hash of the thing in the identifier of the thing -- is also used in the "git" revision control tool (which got the idea from the "monotone" revision control tool). In git a "commit" can refer to a "blob" and to one or more other "commits". All such references include the secure hash (actually the SHA-1) of the reference target, so the references are immutable and the resulting Directed Acyclic Graph is append-only. In Tahoe-LAFS a directory can refer to other directories or files. When the references are of the immutable kind (Option C), then it has similar properties as git, above -- it generates an append-only DAG. I wonder if the DIAC project can generate new techniques for options B or C, or can shed light on the exact properties or possibilities of these Options, or can generate new Options besides these three. If not -- if DIAC is solely about Option A -- that is fine, but it is not very relevant to my current interests. Regards, Zooko ¹ Miller-2003: http://www.erights.org/talks/asian03/ _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
