Re: [e-lang] Constructing capability URLs
At 10:53 PM 9/3/2002 Tuesday, Ng Pheng Siong wrote: (Pardon the crossposting.) Hi, I'm building a web app which, rather typically of web apps, constructs URLs on the fly. A URL concocted by my app looks like this: https://whatever/object?action=somethingexpiry=timevalcap=XXYYZZ The cap at the end is supposed to be a capability. ;-) Please read http://www.erights.org/elib/capability/ode/ode-protocol.html . The quotes below are from that page. From what you say later, it looks like the purpose of this last string is to be an unguessable randomly chosen number, though I don't understand the purpose of the other info you're mixing in. We call an unguessable randomly chosen number used for this purpose a SwissNumber since it has the knowledge-is-authority logic loosely attributed to Swiss bank accounts. In any case, a stringified cryptographic capability needs three parts. The first is routing hint information to help find an object to talk to that allegedly corresponds to the object designated by that capability. This routing info has no security properties beyond denial-of-connectivity issues. The other two parts provide the security: A capability is an arrow, and an arrow has two ends. There is an impostor problem in both directions. The VatID [fingerpring of public key of designated object's host] ensures that the entity that Bob is speaking to is the one that Alice meant to introduce him to. The Swiss number ensures that the entity allowed to speak to Carol is the one that Alice chose to enable to do so. If your https://whatever/; above is intended to provide authentication info as well as routing, then you indeed have something analogous to all three parts. At http://www.waterken.com Tyler Close pioneered this approach to using https URLs as cryptographic capabilities, which has since also been prototyped by Kevin Lacobie for Lotus Notes. The big advantage of this approach is that regular browsers can participate in the world of distributed capabilities, as the Waterken software amply demonstrates. The disadvantage is that the capability authenticity problem, ensuring that the entity that Bob is speaking to is the one that Alice meant to introduce him to no longer depends on just Alice Bob and Carol, but also on VeriSign or other such external CA hierarchies. This is a rather massive expansion of vulnerabilities. Worse, it concentrates vulnerabilities in a small number of massive third parties, leading to a centralization of power. One of my major objectives in this particular development effort is to make it easy to automate the blackbox testing of my app. I imagine URLs such as the above make it so: I can have code that invokes the above URL without regard to the rest of the system. I don't understand what point you're making. I'm creating the capability thusly: cap = hmac-sha1(key, /object?action=somethingexpiry=timeval) My questions: 1. Is the construction of the cap string ok? Should I stir other info in? (The expiry timeval provides the temporal information.) 2. The key is created from /dev/random. How long should it be? In my threat model, the key changes every few hours. Are you happy to have your capability URLs expire when the key does? Do you have some refresh scheme in mind so that a holder of an old URL can, prior to expiration, get a fresh one? What threat (that you care about) does this expiration protect you from? Text by me above is hereby placed in the public domain Cheers, --MarkM - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Is There a Quantum Mechanic in the House? (was: Lucky's 1024-bit post [was: RE: objectivity and factoring analysis])
At 05:52 PM 4/23/2002 Tuesday, Enzo Michelangeli wrote: [...] And if the reason for the 256 bits is the possible deployment, sometimes in the future, of quantum computers, well in that case we should stop using PK cryptography altogether. Hi Enzo! Disclaimer: I am not a quantum mechanic, and I find the whole subject, including quantum computation, deeply confusing. Also, the article I refer to -- an article in Science by the guy who came up with the original factoring result -- is an article that I haven't read, and wouldn't understand if I had. (Neither do I happen to know enough to give a proper citation.) Perhaps someone on this list can fill in some of these gaps, or let us know that I've badly misinterpreted the situation, which is quite possible. All that said, my understanding is that the plausible worst case news from quantum computing would probably not require us to give up PK crypto. My understanding is that the article I'd like to cite states something like the following: 1) Factoring is special because it's all pervasively about periodicities. The author's original factoring proposal took advantage of this in an essential way in order to show a potential exponential speedup. 2) For NP problems in general, since they are search trees with only polynomial depth to an answer but exponential fanout of choices, by using superposition, quantum computation may indeed be able to give an exponential speedup on the first phase of the search -- finding the answer. 3) The problem then is reporting the answer out. The superposition that found the answer co-exists with an exponential number of superpositions that don't. My understanding is that the paper is postulating an upper bound for search problems without peculiar special properties (like the periodicities of factoring) -- the most we can get is an order-of-square-root speedup on the problem as a whole. If the above description is approximately right, then the remaining question for PK is, can one design a PK system now whose trapdoor depends on a search problem that we can be confident cannot be transformed into one with the enabling peculiar properties? AFAIK, this question has not been examined. Btw, out of fear that quantum computation might destroy PK but not single-key, I worried about whether one could do cryptographic capabilities in such a world. http://www.erights.org/elib/distrib/captp/unibus.html is a protocol sketch of a distributed capability protocol that depends only on single-key cryptography. But I hope it will never be necessary. Text by me above is hereby placed in the public domain Cheers, --MarkM - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
