[Microid] MicroID hashing algorithm(s) and normalization
Peter Saint-Andre
stpeter at jabber.org
Wed Dec 6 11:13:16 EST 2006
Eran Sandler wrote:
> HMAC needs an underlying hashing function such as SHA256 or (the already
> problematic) MD5 and SHA1.
> It has the additional value of a secret key but it is still as strong as the
> underlying hashing function.
Sure. In Jabber we recently specified the use of hmac-sha256.
> As far as I understand HMAC, the key is needed in both places, the place the
> generates the hash and the place that creates it to verify it.
> This means it will raise problems in distributing this key in a secure
> manner and will make it harder for implementers of microid and validation
> implementers.
Er, yes. In our Jabber use case, the key is something shared within a
particular trust domain.
> I think that by using just a hashing algorithm it should be fine and make
> the code a lot easier to write for implementers.
> The one thing we do need to give thought to is being able to replace the
> hashing algorithm when (or if) it is not considered safe for usage anymore
> (like SHA1 and MD5).
Yep. We could do SHA256 to start but eventually even that may be found
insecure.
> For that we will need the ability to describe the hashing function used,
> just like Yaniv previously suggested, i.e.:
>
> <meta name="microid"
> content="sha256:openid:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>
>
> or, more correctly presented (after discussing it with Yaniv :-) ):
>
> <meta name="microid"
> content="openid:sha256:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>
>
> So that the data being hashing will be first, and then we will have the
> hashing algorithm.
That's fine by me. But we do need to think about the data definitions.
I'm thinking especially of OpenID. For example, how do we clearly
differentiate between a regular old HTTP URL and an OpenID URL (the
latter is simply an instance of the former, but how to we know that
programmatically)?
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ibiblio.org/pipermail/microid/attachments/20061206/618cb936/attachment.bin
More information about the Microid
mailing list