A few comments about hash algorithms (basing off my reading the Jingle FT spec [0] just now and a discussion the Pidgin devs had a few months ago, which I don't think was brought up in the XMPP community, though I might have missed it).
1) Are there canonical text representations of hash algorithm names some place? i.e. other than it being the one described in the Bits of Binary [1] spec, how do I know that I should use 'sha1' instead of 'sha-1'? Even worse, I just checked Entity Capabilities [2] and it uses "sha-1" as the name of the algorithm!!! :( 2) The Bits of Binary spec and Jingle FT spec don't mention MTI hash algorithms, nor do they include security considerations; the text could probably be lifted from 0115. 3) BoB specifies that "[a] recipient SHOULD cache data based on the hash of the data as encapsulated in the cid.", but doesn't actually specify validation or what a client should do when hash validation should fail. I believe (Marcus, correct me if I'm wrong) that Pidgin now falls back to caching based on (bare?) JID + hash if validation fails (or is impossible), preventing poisoning of any blobs received from other clients. 4) I posted this to the Jingle list, but the Jingle FT spec defines a 'hash' attribute which is underspecified. The spec neither describes how to generate it/what the receipient MAY do with it (yes, relatively obvious), mentions that it's using SHA1, nor allows for future hash agility. 5) Should the XSF adopt hash-function recommendations and standards for all future specs? I'm thinking standardized names (*cough* #1 *cough*) as well as MTI recommendations (perhaps choosing SHA-256, as NIST recommends [3]). [0] Jingle File Transfer http://xmpp.org/extensions/xep-0234.html [1] Entity Capabilities http://xmpp.org/extensions/xep-0115.html [2] Bits of Binary http://xmpp.org/extensions/xep-0231.html [3] NIST's Policy on Hash Functions http://csrc.nist.gov/groups/ST/hash/policy.html ~Paul
signature.asc
Description: OpenPGP digital signature
