[hashcash] Re: Opportunistic signatures - a proposed design
- From: Atom 'Smasher' <atom@xxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 29 Aug 2004 22:33:37 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, 29 Aug 2004, Jonathan Morton wrote:
a practical implementation of a system using shared secrets would be an
absolute nightmare on anything approaching the scale of email. if
anyone can explain a feasible (secure, trusted, invisible to end users,
etc) system of key exchange, i'd enjoy hearing about it.
I think I've already described it. Let me go over your points one by
one:
- Scalability. Each key is known only to it's singular sender and
singular recipient. There is no central authority of any kind, and no
need to send revocation notice to multiple people. Therefore it will
scale indefinitely.
=================
in a system of n users with secret keys, there needs to be n(n-1)/2 keys!
public key systems scale *MUCH* better.
if a machine gets hacked, instead of 1 key being compromised, multiple
keys get compromised. that makes a bigger mess than revoking one key; a
lot of keys have to be revoked... a lot of users have to be notified.
bear in mind, there is no central authority with the pgp PKI... there are
key servers, but they are a convenience, not an authority.
- Security. The key is sent across the wire once (in the common case),
in plaintext. This is considerably more secure than the subsequent
storage of the key on the participating computers, in today's Internet,
and I believe this is sufficient.
==================
although it's an unlikely attack vector for this application, it's
infinitely more vulnerable than sending a public key across the wire.
- Trusted. Each key is only accepted into the recipient's whitelist if
it comes with high-value hashcash *and* the recipient has already sent
mail to the sender. This establishes that a consensual two-way
conversation is in progress, which is the entire point of the exercise.
==================
if i'm a customer of a bank, how do i verify a secret key they've sent me?
verifying a public key is easy, for anyone who feels inclined to verify
it.
- Invisible. Yes, it is.
================
again, as a public key can be. the currently implemented public key
systems, except for HTTPS, suck... but that's a limitation of the
implementations, not the underlying technology.
there's no advantage to using secret keys rather than public/private keys,
but there is a nightmare of key management issues.
another practical reason to use public key, rather than secret key
authentication for email is that an email only needs to be signed once,
and any number of users can verify the signature; it even works on mailing
lists. adding one header for each recipient to whom we want to sign a
message for is a burden that is not offset by any advantage.
...atom
_________________________________________
PGP key - http://atom.smasher.org/pgp.txt
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"When a man calls an animal vicious that usually means
it will try to protect itself when he tries to kill it."
-- Rick McIntyre, "A Society of Wolves"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures
iQEcBAEBCAAGBQJBMpIHAAoJEAx/d+cTpVciZyYIAIka0lkGWRfDwQUUd/AAigXS
Kj52tDYuklw9RJ9YMKIFD0F6EX2BXZdrEEXuoYRANs46ENl23U7ESdLtgif/zrkc
6RrLvQfiRZMLBZ7DBExQ6xV2/YCdMVlXE1GlL3rovviw7GAKiEnqHyY9cgICbYKt
z/U1NgLejt6w5SqN47Wa8gZsNbm6XsqBJOPbYNpU/srDy0kOGCrmzBj8VmOeck1L
TCgdHEMzz2J6feJa705HlSl5Y3lgRU+tlH0Flmwq2TMBiT7Cx3SsuazG5GfhU1FI
oz93Tq1P/Tqx5mPpl1b0Vcjs/fP2UX7EixKptci8RCw7IggSFHVcUJLacuEWvoU=
=Lv6F
-----END PGP SIGNATURE-----
Other related posts:
