[hashcash] Re: Opportunistic signatures - a proposed design

Atom 'Smasher' wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

i already let signed email bypass any filtering, if i have the public
 key in my keyring.

i'm currently working on a formal standard for including OpenPGP key
 information in an email header. when that happens, an MUA can offer
the user an option to accept the key, and accept any message signed
with that key. it really shouldn't be *that* difficult to build the
UI smarts into an app, if the key management is handled
intelligently.


well, I'm on the opinion that the user should never ever see there is a
key unless they have a specific security need to do so.  Think about the
most successful systems with encryption today: SMTP/TLS and HTTPS

the reason they are successful is because the user just uses them.  They
don't futz with keys, they don't manage a key ring, it just works
because it does.  If it doesn't work right, you call your local geek and
maybe they can make things get better again.

what ever system we build in, should have zero interface required as one
of the founding principles.  It can be done, yes the keys are not very
secure but, once you're owned, it doesn't matter if you have a pass
phrase whether it's default, stored somewhere on the system, or in your
head.  If you don't own your own system, it's gone.

once you're comfortable with a concept, plus the knowledge that if you need to add more key security you can, a zero user interface baseline is really not all that scary.

in the meantime, only geeks will allow signed messages to bypass
further checks. i think that signatures and hashcash serve different
purposes, and to that extent the technologies are complimentary... if
i have your key in my keyring you can sign a message and it won't be
subject to filtering... but if i don't know you, then hashcash will
do the same thing. also, i may not want to sign an email with my key
(maybe i'll want to deny later that i authored it)... in that case,
hashcash is more valuable.

the whole point behind signatures (in this context) is to indicate automatically that the message is from someone I know. Not from someone pretending to be someone I know but actually someone that I know and have exchanged e-mail with in the past. That's it. End of requirements (sort of). It's not to have any greater level of meaning. That's for someone else's concern. It's just "it says it's from Joe, does it look like his signature?"


anyway, OpenPGP is a perfectly viable protocol for signing email...
no need to reinvent that wheel. of course, if people are signing on auto-pilot (no password protected keys) then keys should be small...
they'll be stolen by viruses, not password protected and there
should be several avenues of plausible deniability... the purpose is
to "prove" to a filter, not to a court, who authored an email. of
course, if one is handling outbound email for a large bank and they
want to discourage phishing, then a large key is a good idea (with
certain obvious and non-obvious precautions).

well, here's the question how fast can you for someone's key if it's a small number of bits. After all, that's what all of our techniques boil down to. If I use a public key system with 256 bits, how fast can spammer fake being me? What's a reasonable lower floor?

now, if we add the requirement that we want to also encrypt e-mail in transit, again, what's the size of the organization that can regenerate my key, how long would take, etc.

mind you, if we use the Russian dolls model of encryption (weak outside, strong inside) then it wouldn't matter so much because if you truly wanted to protect your contents, you would protect your contents explicitly. I'm mostly thinking about envelope level protection.

---eric


Other related posts: