more hiddencredentials comments (Re: Brands' private credentials)

[Adam Back]

On Mon, May 10, 2004 at 08:02:12PM +0000, Jason Holt wrote:
> Adam Back wrote:
> > [...] However the server could mark the encrypted values by encoding
> > different challenge response values in each of them, right?
> 
> Yep, that'd be a problem in that case.  In the most recent (unpublished)  
> paper, I addressed that by using R as the key for a ciphertext+MAC on the
> actual message.  

OK that sounds like it should work.  Another approach that occurs is
you could just take the plaintext, and encrypt it for the other
attributes (which you don't have)?  It's usually not too challenging
to make stuff deterministic and retain security.  Eg. any nonces,
randomizing values can be taken from PRMG seeded with seed also sent
in the msg.  Particularly that is much less constraining on the crypto
system than what Bert-Jaap Koops had to do to get binding crypto to
work with elgamal variant.

> In either case, though, you can't just trust that the server
> encrypted against "patient OR doctor" unless you have both creds and
> can verify that they each recover the secret.

The above approach should fix that also right?

> (And you're right, the AIDS example is not very compelling.  The
> slides give a better one about FBI agents, but I'm still looking for
> other examples of super-sensitive transactions where HCs would fit)

dissident computing I think Ross Anderson calls it.  People trying to
operate pseudonymously and perhaps hiding the function of their
servers in a cover service.

> Hugo Krawczyk gave a great talk at Crypto about the going-first problem in
> IPSec, which is where I got the phrase.  He has a nice compromise in letting
> the user pick who goes first, but for some situations I think hidden
> credentials really would hit the spot.

Unless it's signifcantly less efficient, I'd say use it all the time.

> > I think it would be fair to call it anonymity system, just that the
> > trust model includes a trusted server.  There are lots of things
> > possible with a trusted server, even with symmetric crypto (KDCs).
> 
> Yeah, although I think most of them would require an on-line trusted
> server.  But that just makes all sorts of things way too easy to be
> interesting. :)

Yes.  But you could explore public key based without IBE.  You may
have to use IBE as a sub-protocol, but I think ideally want to avoid
the IBE server being able to decrypt stuff.  Sacrificing the IBE
communication pattern wouldn't seem like a big deal.

Hmm well IBE is has a useful side-effect in pseudonymity systems
because it also has the side-effect of saving the privacy problems in
first obtaining the other parties key.  Other way to counteract that
is to always include the psuedonym public key with the pseudonym name
(which works for mailto: style URLs or whatever that are
electronically distributed, but not for offline distributed).

Btw one other positive side-effect of IBE is the server can't
impersonate by issuing another certificate in a pseudonyms name
because there is definitionally only one certificate.

I was thinking particularly if you super-encrypt with the psuedonym's
(standard CA) public key as well as the IBE public key you get the
best of both feature sets.

btw#2 You could probably come up with a way to prevent a standard (non
IBE) CA from issuing multiple certs.  eg. if he does that and someone
puts two certs together they learn CA private key, ala Brands
credential kind of offline double spending protection.

Kind of a cryptographically enforced version of the policy enforced
uniqueness of serial numbers in X.509 certs.  And we change the policy
to one cert per pseudonym (kind of sudden death if you lose the
private key, but hey just don't do that; we'd have no other way to
authenticate you to get a new cert in the same psuedonyms name anyway,
so you may just as well backup your pseudonym private key).

Adam