[sugar] [PATCH] services/presence/: identify Buddies by "key ID" (pubkey hash), not whole key.

[Morgan Collett]

Simon McVittie wrote:

> services/presence/: identify Buddies by "key ID" (pubkey hash), not whole key.
> 
> This allows us to create Buddy objects as soon as we see a contact on the
> server. For contacts not on trusted servers, or seen in anonymous MUCs, we
> create a Buddy identified by JID instead (so we have some way to talk
> about the anonymous contact within the Sugar API).

Sounds good.

> The concept of "trusted server" means a server which we trust to validate that
> users with a keyID as the username part of their JID do in fact have that key.
> Currently we just pretend that olpc.collabora.co.uk does this - in future, the
> school servers will do this validation by using key rather than password
> authentication.

Security by hand-waving :)

> I'm assuming here that the key-ID is "sufficiently unique" across all
> trusted servers. It's a SHA-1 of the public key, so basically the
> same strength as GnuPG key fingerprints and git object hashes.
> (Actually, for hysterical raisins, it's a SHA-1 of Base64(public_key) -
> we should probably change this before we ship.)

A lot of crypto out there relies on hashes of keys. If the key is random
(enough), then the hash should be good enough not to collide. At least,
not in predictable ways...

Why though is it a hash of the base64? In theory the base64s have the
same entropy as the keys, but the crypto stuff should be happening in
binary land unless we get into XML.

If changing it will break the mesh for everybody at some point "before
we ship", sooner's better than later.

In http://www.nist.gov/sha, NIST states:
"Federal agencies should stop using SHA-1 for digital signatures,
digital time stamping and other applications that require collision
resistance as soon as practical, and must use the SHA-2 family of hash
functions for these applications after 2010."

We probably won't have a NIST-blessed replacement for SHA before 2012.
Nevertheless, we need to allow for changes along the way.

> The actual function used for the key-ID can be changed (if it
> is, old and new versions of Sugar will be incompatible, but that's not
> really a problem yet) so if any crypto gurus want to specify something
> different, now would be a really good time. As currently implemented, its
> output must be short enough to put in the JID (for which a hex SHA-1 is
> somewhat long already).

IMO we need to allow for some algorithm agility here. Breaking the mesh
at any stage is going to be very unpleasant - for the users^Wkids
especially.

For the unique identifier stuff, could we at some future point do a
'keyid2/' (or some other prefix) meaning that this is an identifier in a
different space?

Anyway, the patch looks good.

Morgan