On 6/29/10 2:27 PM, Dave Cridland wrote: > On Tue Jun 29 21:12:46 2010, Paul Aurich wrote: >> 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!!! :( >> >> > There's an IANA registry, which we've generally used in recent protocols: > > http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml
Yes, I think it's best for us to use the names from that IANA registry, and to grandfather older usages. > Slightly awkwardly, this relates to X.509 defined hashes, so would be > tricky to update, but an IETF standards action could probably change > that if needs be. (And would have support, I think). What do you want to update there? The hash function names, or the name of the registry? >> 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]). > > There's several uses for hash algorithms - some use-cases demand that a > preimage attack be impossible, some don't, for example. The safest > option for us is to pick a single algorithm - this also has the > advantage of simplifying implementation requirements. > > I've said before in IETF-land that a single spec of "this is the sane > MTI security algorithm" would be useful. Perhaps the XSF could show them > how it's done. However, such a spec is no substitute for hash agility, because we'll need to update the MTI recommendation in the future. Peter -- Peter Saint-Andre https://stpeter.im/
