cryptoIDs

[Trevor Perrin]

Hi cryptography,

I haven't posted here much, but I've got an idea I'd like to try to win 
some converts / draw some criticism for.  There's a paper, code, and other 
stuff here: http://trevp.net#cryptoID.  Here's the gist:

The goal is a system for encrypted & authenticated person-to-person 
communications (email, voice, IM, etc.).  It should be simple for people to 
use, and easy for developers to plug into everything.

Such a system would address two problems:
  - public-key distribution (how does Bob get Alice's public key)
  - private-key management (how does Alice deal with her private key - keep 
it secure yet accessible, recover from compromise, etc.)

The PKI approach is to use certs for the 1st, and, I guess, smartcards for 
the 2nd.  Instead, I think people should use fingerprints for the 1st and 
certs for the 2nd.

Fingerprints would work well for key distribution since they're small 
pieces of data, like phone numbers or email addresses.  Users already know 
how to handle these by exchanging them on business cards, writing or 
speaking them, looking them up in directories, etc..  Similarly, software 
already has address books to store these things, so it would be easy to add 
another field for the fingerprint.  Software would inform you when 
something authenticates to a known fingerprint (a blinking indicator next 
to a "pet name"[1], for example) .

One problem: fingerprints are large, thus not very user-friendly.  But that 
can be fixed, somewhat:  if you use the "hash extension" technique from [2] 
and base32 encoding, you can get 20 character fingerprints with a 
reasonable security level (for example: to generate a fingerprint with a 
security level of 120 bits requires a computation of ~15 seconds; if talk 
of "generating" a fingerprint sounds strange see [2] or [3]).  These 
fingerprints (call them "cryptoIDs") would look like:
   erbtr.isnx6.4fcuj.5yymj
   frqtp.3jbrt.ukued.ngwwe

Not as short as one would like, but much better than the usual hex-coded 
SHA-1.  There's other problems with doing things via fingerprint, but 
you'll have to see the paper - I'm trying (though failing) to be brief :-).

Anyways, for private-key management people should use certs - store your 
root key (i.e. the key that matches the fingerprint) in a safe place (for 
most people, this would be with their employer or a commercial service; but 
the security-conscious can do whatever they want).  Then have your root-key 
issue you short-lived certs for use on your cell-phone, email client, web 
browser, etc..

You could use PGP subkeys, X.509 proxy certs, or SPKI certs for this.  But 
all of them are either excessively complicated for this, lacking in 
features, or both.  So I designed a certificate format just for private-key 
management.  It's SPKI-like but a little simpler and I think does a couple 
things better.


I'm eager for feedback, off-list or on.  Nothing here is that novel, but to 
me this seems a powerful, yet fairly simple, blend of techniques.

Trevor

[1] http://www.erights.org/elib/capability/pnml.html
[2] http://research.microsoft.com/users/tuomaura/CGA/
[3] http://trevp.net/cryptoID/cryptoID.html#3.3.1





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com