Eugen forwards from FoRK:
> >Colliding X.509 Certificates version 1.0
> >1st March 2005
> >Arjen Lenstra, Xiaoyun Wang, and Benne de Weger
> >
> >http://eprint.iacr.org/2005/067
> >
> >We announce a method for the construction of pairs of valid X.509
> >certificates in which the ?to be signed? part
to have provable security!
This way of doing things would also be quite inefficient; there are
two ElGamal encryptions going back and forth (typically 2048 bits each)
for every bit of your password. I'll bet the actual paper has a much
more clever scheme which improves the efficiency and has a nice proof
of security. I'm looking forward to seeing it.
Hal Finney
need a minimum of
4 or 5 people doing it, but as I said a dozen or more would be great.
Sorry about the last minute notice; I know that most people won't see
this until too late, but if anyone sees it now and you know how to use
BT I'd appreciate your help.
Thanks!
Hal Finney
> Nikita Borisov and Ian Goldberg have released
> Off-the-Record Messaging (http://www.xelerance.com/mirror/otr/),
It looks like Ian Goldberg's site might be a more authoritative source,
http://www.cypherpunks.ca/otr/ .
One interesting feature is authentication + deniability. You know who
you ar
Ben Laurie writes:
> How do you make the payment already "gone" without using a third party?
Of course there has to be a third party in the form of the currency
issuer. If it is someone like e-gold, they could do as I suggested and
add a feature where the buyer could transfer funds irrevocably in
Michael_Heyman writes:
> Finney, Hal (CR):
> > The problem is that if the source code you are purchasing is
> > bogus, or if the other side doesn't come through, you're
> > screwed because you've lost the value of the torn cash. The
> > other side doesn't gain anything by this fraud, but they h
Enzo Michelangeli writes:
> In the world of international trade, where mutual distrust between buyer
> and seller is often the rule and there is no central authority to enforce
> the law, this is traditionally achieved by interposing not less than three
> trusted third parties: the shipping line, t
"Tyler Durden" writes:
> So my newbie-style question is, is there an eGold that can be verified, but
> not accessed, until a 'release' code is sent?
>
> In other words, say I'm buying some hacker-ed code and pay in egold. I don't
> want them to be able to 'cash' the gold until I have the code. Me
There was a brief mention of this technology at the Crypto conference.
I provided some pointers in a comment to an Ed Felten blog entry at
http://www.freedom-to-tinker.com/archives/000677.html#comments (scroll
down to the 3rd comment).
Dan Boneh et al presented a proposal for a group signature sch
tions between communicators who don't share any secrets or CAs.
I don't think "anonymous" is the right word for this, and I hope the
IETF comes up with a better one as they go forward.
Hal Finney
eap would it be possible to try verifying the signature under
different keys and see which one worked.
Hal Finney
Spam is the least of the problems for remailers when it comes to
abuse. You should be more concerned about possible liability for
illegal messages.
In a way, spam has actually made the remailer operator's life easier
as people today are used to receiving annoying and obscene email.
Ten years ago,
e server code, which will invalidate
any RPOW tokens which people have previously created. So don't go too
crazy hoarding up RPOWs quite yet.
Thanks very much -
Hal Finney
MV writes:
> Yes. They can't break a 128 bit key. That's obvious. ("if all the
> atoms in the
> universe were computers..." goes the argument).
Not necessarily, if nanotechnology works. 128 bits is big but not
that big.
Eric Drexler, in Nanosystems, section 12.9, predicts that a nanotech
base
r. The difference
I suppose is that the forwarder would be selling privacy services, hence
different ones would compete to get a good reputation. Any cheating might
be detected by insider whistle blowers or perhaps some kind of audit.
Hal Finney
15 matches
Mail list logo
