Re: anonymity +- credentials
Anton Stiglic wrote: - Original Message - From: Ian Grigg [EMAIL PROTECTED] [...] In terms of actual practical systems, ones that implement to Brands' level don't exist, as far as I know? There were however several projects that implemented and tested the credentials system. There was CAFE, an ESPRIT project. CAFE now has a published report on it, so it might actually be accessible. I'm not sure if any of the tech is available. At Zeroknowledge there was working implementation written in Java, with a client that ran on a blackberry. There was also the implementation at ZKS of a library in C that implemented Brands's stuff, of which I participated in. The library implemented issuing and showing of credentials, with a limit on the number of possible showing (if you passed the limit, identity was revealed, thus allowing for off-line verification of payments for example. If you did not pass the limit, no information about your identity was revealed). The underlying math was modular, you could work in a subgroup of Z*p for prime p, or use Elliptic curves, or base it on the RSA problem. We plugged in OpenSSL library to test all of these cases. Basically we implemented the protocols described in [1], with some of the extensions mentioned in the conclusion. The library was presented by Ulf Moller at some coding conference which I don't recall the name of... Is any of this published? I'd assumed not, ZKS were another company obscuring their obvious projects with secrecy. It was to be used in Freedom, for payment of services, but you know what happended to that projet. Reality caught up to them, I heard :) As Eric R recently commented, there are no shortage of encrypted comms projects being funded and .. collapsing when they discover that selling secure comms is not a demand- driven business model. Somebody had suggested that to build an ecash system for example, you could start out by implementing David Wagner's suggestion as described in Lucre [2], and then if you sell and want extra features and flexibility get the patents and implement Brands stuff. Back in '98 or so, I got involved with a project to do bearer stuff. I even went so far as to commission a review of all the bearer protocols (Cavendish, Chaum, Brands, Wagner, Mariott, etc etc). Brands came out as the best (please don't ask me why), so Stefan and I spent many a pleasurable negotiating session in Dutch bars trying to hammer out a licence. Unfortunately we didn't move fast enough to lock up the terms, and he went off to bigger and better things - ZKS. Since then, we toyed around adding tokens to WebFunds. We started out thinking about Wagner, but what transpired was that it was just as easy to make the whole lot available at once. Now we have a framework. (It's an incomplete project, but we recently picked it up again after a long period of inactivity, as there is a group that has figured out how to use it for a cool project.) The protocol only covers single phase withdrawals, not two phase, so far. Similar strategy would seem to apply for digital credentials in general. Perhaps! I don't understand the model for credentials, but if they can all be put into a block-level protocol, then sharing the code base is a mighty fine idea. There is an alternate approach, the E/capabilities world. Capabilities probably easily support the development of psuedonyms and credentials, probably more easily than any other system. But, it would seem that the E development is still a research project, showing lots of promise, not yet breaking out into the wider applications space. A further alternate is what could be called the hard-coded psuedonym approach as characterised by SOX. (That's the protocol that my company wrote, so normal biases expected.) This approach builds psuedonyms from the ground up, which results in a capabilities model like E, but every separate use of the capability must be then re-coded in hard lines by hardened coders. Do you have any references on this? The capabilities guys hang around here: http://erights.org/ http://www.eros-os.org/ SOX protocol is described here: http://webfunds.org/guide/sox.html iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymity +- credentials
- Original Message - From: Ian Grigg [EMAIL PROTECTED] [...] In terms of actual practical systems, ones that implement to Brands' level don't exist, as far as I know? There were however several projects that implemented and tested the credentials system. There was CAFE, an ESPRIT project. At Zeroknowledge there was working implementation written in Java, with a client that ran on a blackberry. There was also the implementation at ZKS of a library in C that implemented Brands's stuff, of which I participated in. The library implemented issuing and showing of credentials, with a limit on the number of possible showing (if you passed the limit, identity was revealed, thus allowing for off-line verification of payments for example. If you did not pass the limit, no information about your identity was revealed). The underlying math was modular, you could work in a subgroup of Z*p for prime p, or use Elliptic curves, or base it on the RSA problem. We plugged in OpenSSL library to test all of these cases. Basically we implemented the protocols described in [1], with some of the extensions mentioned in the conclusion. The library was presented by Ulf Moller at some coding conference which I don't recall the name of... It was to be used in Freedom, for payment of services, but you know what happended to that projet. Also, the use of Brands work would need to consider that he holds a swag of patents over it all (as also applies to all of the Chaum concepts). Yes, most of the stuff is patented, as is Chaum's stuff. Somebody had suggested that to build an ecash system for example, you could start out by implementing David Wagner's suggestion as described in Lucre [2], and then if you sell and want extra features and flexibility get the patents and implement Brands stuff. Similar strategy would seem to apply for digital credentials in general. There is an alternate approach, the E/capabilities world. Capabilities probably easily support the development of psuedonyms and credentials, probably more easily than any other system. But, it would seem that the E development is still a research project, showing lots of promise, not yet breaking out into the wider applications space. A further alternate is what could be called the hard-coded psuedonym approach as characterised by SOX. (That's the protocol that my company wrote, so normal biases expected.) This approach builds psuedonyms from the ground up, which results in a capabilities model like E, but every separate use of the capability must be then re-coded in hard lines by hardened coders. Do you have any references on this? Thanks. --Anton [1] http://crypto.cs.mcgill.ca/~stiglic/Papers/brands.pdf [2] http://anoncvs.aldigital.co.uk/lucre/theory2.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymity +- credentials
Anton Stiglic wrote: We need a practical system for anonymous/pseudonymous credentials. Can somebody tell us, what's the state of the art? What's currently deployed? What's on the drawing boards? The state of the art, AFAIK, is Chaum's credential system. The state of the art is Brands' credentials. Thanks for clearing up the record there - it was also my understanding that Brands' work was the current theoretical state of the art! In terms of actual practical systems, ones that implement to Brands' level don't exist, as far as I know? Also, the use of Brands work would need to consider that he holds a swag of patents over it all (as also applies to all of the Chaum concepts). There is an alternate approach, the E/capabilities world. Capabilities probably easily support the development of psuedonyms and credentials, probably more easily than any other system. But, it would seem that the E development is still a research project, showing lots of promise, not yet breaking out into the wider applications space. A further alternate is what could be called the hard-coded psuedonym approach as characterised by SOX. (That's the protocol that my company wrote, so normal biases expected.) This approach builds psuedonyms from the ground up, which results in a capabilities model like E, but every separate use of the capability must be then re-coded in hard lines by hardened coders. Which means, for example, that whilst the E crowd can knock up a new capability over lunchtime, it takes us about a year of hard work to get a new capability in place (we've done several - payments, messaging, trading, projects, ...). The plus side is that these capabilities are far more suited to purpose than something built over a high level platform. In summary, the state of the art would seem to be just that, an art in a state. There is no clear view as to how this will pan out in the future, to my mind. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
anonymity +- credentials
On 10/03/2003 01:26 PM, R. A. Hettinga wrote: It seems to me that perfect pseudonymity *is* anonymity. They're not quite the same thing; see below. Frankly, without the ability to monitor reputation, you don't have ways of controlling things like transactions, for instance. It's just that people are still mystified by the concept of biometric is-a-person identity, which strong cryptography can completely divorce from reputation. We agree that identification is *not* the issue, and that lots of people are confused about this. I'm not sure reputation is exactly the right concept either; the notion of credentials is sometimes better, and the operating-systems folks speak of capabilities. There are three main possibilities: -- named (unique static handle) -- pseudonymous (dynamic handles) -- anonymous (no handle all) Sometimes pseudonyms are more convenient than having no handle at all. It saves you the trouble of having to re-validate your credentials at every micro-step of the process (whatever the process may be). Oftentimes pseydonyms are vastly preferable to a static name, because you can cobble up a new one whenever you like, subject to the cost of (re)establishing your credentials from scratch. The idea of linking (bidirectionally) all credentials with the static is-a-person identity is a truly terrible idea. It dramatically *reduces* security. Suppose Jane Doe happens to have the following credentials -- Old enough to buy cigarettes. -- Has credit-card limit $300.00 -- Has credit-card limit $3000.00 -- Has car-driving privileges. -- Has commercial pilot privileges. -- Holds US citizenship. -- Holds 'secret' clearance. When Jane walks into a seedy bar, someone can reasonably ask to verify her old-enough credential. She might not want this query to reveal her exact age, and she might *really* not want it to reveal her home address (as many forms of ID do), and she might *really* *really* not want it to reveal all her other credentials and capabilities. *) There is an exploding epidemic of ID theft. That is a sure sign that people keep confusing capability -- identity and identity -- capabilities. *) There are those who want us to have a national ID-checking infrastructure as soon as possible. They think this will increase security. I think it is a giant step in the wrong direction. *) Reputation (based on a string of past interactions) is one way, but not the only way, to create a credential that has some level of trust. = We need a practical system for anonymous/pseudonymous credentials. Can somebody tell us, what's the state of the art? What's currently deployed? What's on the drawing boards? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
