[Adam and I are taking this discussion off-list to spare your inboxes, but
this message seemed particularly relevant. Perhaps we'll come back later if
we come up with anything we think will be of general interest.]
-J
On Tue, 11 May 2004, Adam Back
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 10 May 2004, Adam Back wrote:
After that I was presuming you use a signature to convince the server
that you are authorised. Your comment however was that this would
necessarily leak to the server whether you were a doctor or an AIDs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 10 May 2004, Adam Back wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 9 May 2004, Adam Back wrote:
and seeing that it is a completely different proposal essentially
being an application of IBE, and extension of the idea that one has
multiple identities encoding attributes. (The usual attribute this
Several things:
* Using the output to seed MD5 for the next block exposes that part of the
state of the RNG. Might be better to use half the MD5 output as seed for the
next block, and the other half as output data.
* Your RNG takes input from an attackable source. I can significantly reduce
(Re: my paper at http://eprint.iacr.org/2002/151/ )
Stefan Brands wrote:
- The system is subject to a simple attack. The problem lies with the
multiplication of the hashes. Let's take the Chaum blinding as an
[...]
(For our readers at home, that was the vulnerability I mentioned in
(Re: my paper at http://eprint.iacr.org/2002/151/ )
Let me first point out that Dr. Stefan Brands noted an insecurity in
my system which would allow malicious users to obtain issuer signatures on
arbitrary documents.
This is due to the fact that users aren't prevented from using
I've submitted a pre-print of my anonymous credential system to the IACR
ePrint server. Thanks to all of you who responded to the questions I posted
here while working on it. I'd love to hear feedback from any and all before I
sumbit it for publication; particularly, I want to make sure I
I'm working on designing the programming projects for a data security class.
What do you think of this one?
I love its intrinsic irony, but can we actually get away with requiring it for
a university class? I mean, Elcomsoft really is in court for this. My
University is unfortunately not
Well, I got such a good response from my last technical question that I'll try
again :)
If it's actually secure, it'll go really well with my credential system.
Trent generates primes p,q. He publishes n=pq and some random value g.
Trent calculates a and a' such that aa' = 1 % (p-1)(q-1) and
Maybe you could say more about the details of your credential system.
Such a system built on Wagner blinding might be very interesting.
I've been thinking it would be nice to post my entire paper here (and
maybe on sci.crypt.research) before sending it off to the journals. What are
the
But actually another solution is much simpler, which is to do blinding
as just h * g^b, without a y factor. That works fine as long as the
bank is known not to be misbehaving. Ben's paper shows how the bank
can use a ZK proof to show that it is raising to the same power k every
time,
In his paper on Lucre (2nd defence against marking):
http://anoncvs.aldigital.co.uk/lucre/
Ben Laurie gives this as a (possibly patent-free) blinding technique,
where h is the message, and g is the public generator:
r = blind(h) = h^y * g^b (mod p)
To sign,
s =
In Applied Cryptography, p. 87 (2nd ed., heading Bit Commitment Using One-Way
Functions) Schneier specifies that Alice must generate 2 random bit strings
before hashing, and then send one along with the hash as her commitment:
commitment = H(R1, R2, b), R1
Then she sends R2 and her bit to
Ian Grigg wrote:
[...]
SSL for commerce is readily in place without batting an eyelid these days.
Costs are still way too high. This won't change until
browsers are shipped that treat self-signed certs as being
valid. Unfortunately, browser manufacturers believe in
cert-ware for a
Ian Grigg wrote:
[...]
SSL for commerce is readily in place without batting an eyelid these days.
Costs are still way too high. This won't change until
browsers are shipped that treat self-signed certs as being
valid. Unfortunately, browser manufacturers believe in
cert-ware for a
On Thu, 30 May 2002, Ian Grigg wrote:
[...]
And, in practice this is how it goes. No thief ever bothers
to do an MITM, even over *un*encrypted traffic. They simply
hack into the machines and steal it all. That's why there
has never been a case of CCs sniffed over the net and being
used to
17 matches
Mail list logo
