Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

["Kemp, David P." <[e-mail]>]

Marsh Ray wrote:
> It will not be so fun to convince reviewers that "yes we're using
> SHA-1 but not in a way that really matters."
>
> If all you need is a 64-bit checksum for data-structure-style
> hashing and indexing, use any old old-fashioned checksum algorithm.
>
> This would be simple for everyone to implement and it clearly
> communicates your design intent (that the security of the design
> does not depend on any properties of this value's calculation).

+1 in principle.

But practically speaking, do you have any suggestions for well-known non-cryptographic hash algorithms?  A quick IANA search turned up Kerberos checksums http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml, including CRC32 (4 octets), des-mac-k (8 octets), and several 16 octet algorithms including MD4 and MD5.

A search for other "hash", "mac", or "checksum" registries turned up nothing new.

It doesn't feel quite right to add a non-cryptographic checksum to the RFC 5246 registry:

      enum {
          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
          sha512(6), (255)
      } HashAlgorithm;

so even if there were such an algorithm, permitting both it and cryptographic hashes would be painful.

I don't see an alternative that satisfies both "simple to implement" and "clearly communicates intent".  My care-abouts are 1) a common interoperable algorithm and 2) bandwidth.  Computation speed is unimportant, so if everyone thinks sha256 will be cryptographically viable for the foreseeable future and SHA-1 will soon be impossible to get "approved", then sha256 truncated to 64 bits could be a reasonable MUST-support algorithm.

Dave