bear wrote:
>
> On Sat, 8 Apr 2006, Ben Laurie wrote:
>
>>> Well the other kind of disincentive was a credit card number. My
>>> suggestion was to use a large denomination ecash coin to have
>>> anonymous disincentives :) ie you get fined, but you are not
>>> identified.
>> The problem with that
On Wed, Apr 19, 2006 at 11:53:18AM -0700, bear wrote:
> On Sat, 8 Apr 2006, Ben Laurie wrote:
> >Adam Back wrote:
> >> My suggestion was to use a large denomination ecash coin to have
> >> anonymous disincentives :) ie you get fined, but you are not
> >> identified.
> >
> >The problem with that dis
On Sat, 8 Apr 2006, Ben Laurie wrote:
>> Well the other kind of disincentive was a credit card number. My
>> suggestion was to use a large denomination ecash coin to have
>> anonymous disincentives :) ie you get fined, but you are not
>> identified.
>
>The problem with that disincentive is that
Adam Back wrote:
> On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote:
>> Adam Back wrote:
>>> [about Brands credentials]
>>> I think they shows are linkable, but if you show more than allowed
>>> times, all of the attributes are leaked, including the credential
>>> secret key and potential
On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote:
> Adam Back wrote:
> > [about Brands credentials]
> > I think they shows are linkable, but if you show more than allowed
> > times, all of the attributes are leaked, including the credential
> > secret key and potentially some identifying
Christian Paquin wrote:
> Adam Back wrote:
>> On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
>>> Brands actually has a neat solution to this where the credential is
>>> unlinkable for n shows, but on the (n+1)th show reveals some secret
>>> information (n is usually set to 1 but doesn'
Adam Back wrote:
> On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
>>> This illustrates a problem with multi-show credentials, that the holder
>>> could share his credential freely, and in some cases even publish it,
>>> and this would allow non-authorized parties to use it. To avoid t
John Gilmore writes:
> > I am aware of, Direct Anonymous Attestation proposed for the Trusted
> > Computing group, http://www.zurich.ibm.com/security/daa/ .
>
> > DAA provides
> > optionally unlinkable credential showing and relies on blacklisting to
> > counter credential sharing.
>
> Hmm, why doe
> I am aware of, Direct Anonymous Attestation proposed for the Trusted
> Computing group, http://www.zurich.ibm.com/security/daa/ .
> DAA provides
> optionally unlinkable credential showing and relies on blacklisting to
> counter credential sharing.
Hmm, why doesn't this blacklisting get mentione
Adam Back wrote:
On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
Brands actually has a neat solution to this where the credential is
unlinkable for n shows, but on the (n+1)th show reveals some secret
information (n is usually set to 1 but doesn't have to be).
I think they shows a
John Denker wrote:
The phrase "there are no sensitive secrets today" sounds very strange
by itself, and doesn't sound much better in context.
I assume the intended meaning was more along the lines of:
== The set of things you want to keep secret has zero overlap with
== the set of things you
Hal Finney wrote in part:
... Attempts to embed sensitive secrets in credentials don't work because there
are no sensitive
secrets today. You could use credit card numbers or government ID numbers (like US SSN) but in
practice such numbers are widely available to the black hat community.
The
Ben Laurie writes:
> If I have understood your description correctly it seems to me that this
> is defeated if, rather than sharing the master certificate, the bad guy
> allows their friend to proxy to them for whatever proofs are required.
> That way they never have to give up the precious master
On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
> > This illustrates a problem with multi-show credentials, that the holder
> > could share his credential freely, and in some cases even publish it,
> > and this would allow non-authorized parties to use it. To avoid this,
> > more compl
Apu Kapadia wrote:
>
> I came across the same problem a couple of years ago (and indeed
> iterated through private/public key solutions with a colleague). The
> problem is that you can still give your private key to somebody else.
> There's no real deterrent unless that private key is used for man
Hal Finney wrote:
> Ben Laurie writes:
>> It is possible to use blind signatures to produce anonymity-preserving
>> credentials
>>
>> It seems to me quite obvious that someone must have thought of this
>> before - the question is who? Is it IP free?
>
> David Chaum did a great deal of work in
On Sat, Apr 01, 2006 at 12:35:12PM +0100, Ben Laurie wrote:
> However, anyone I show this proof to can then masquerade as a silver
> member, using my signed nonce. So, it occurred to me that an easy
> way to prevent this is to create a private/public key pair and
> instead of the nonce use the hash
I came across the same problem a couple of years ago (and indeed
iterated through private/public key solutions with a colleague). The
problem is that you can still give your private key to somebody else.
There's no real deterrent unless that private key is used for many
other purposes, th
Ben Laurie writes:
> It is possible to use blind signatures to produce anonymity-preserving
> credentials
>
> It seems to me quite obvious that someone must have thought of this
> before - the question is who? Is it IP free?
David Chaum did a great deal of work in this area in the 80s and 90s.
It is possible to use blind signatures to produce anonymity-preserving
credentials. The general idea is that, say, British Airways want to
testify that I am a silver BA Executive Club cardholder. First I create
a random number (a nonce), I blind it, then send it to BA. They sign it
with their “this
20 matches
Mail list logo