1 Answer
1

Mostly yes: usual cryptographic operations, including hashes, are defined using operations on integers and bit vectors, not Floating Point Numbers.

I think the main reason is that in cryptography, we need different computers (e.g. the one that hashes a file to protect its integrity, and the one that verifies the integrity) to get the exact same result, and that is hard to ascertain for Floating Point operations.

Historically, computers used different format and precision for representing Floating Point numbers, and that would cause huge portability problems.

Nowadays virtually every recent CPU with FP support (which is only a tiny fraction of the CPUs manufactured) can use at least one of the 32-bit, 64-bit or 128-bit format of IEEE 754, so this is slightly less a concern than it was. But still, many computer languages and dialects give no way to precisely control rounding, or to efficiently convert arbitrary information as found in a generic file into FP format and back. It remains a mess to even get exactly the same result for FP addition on two machines programmed in different languages. Further, I would not bet that the same program using 128-bit arithmetic allays gives the same result on two different x86 PCs with built-in FPU when even multiplication is involved, much less division (maybe some designs differ by one LSbit in some edge case). Notoriously the result for transcendentals (e.g. $\sin$) differ.

There are a few uses of FP in the implementation of some cryptographic algorithms, or even hashes. I have seen an implementation of MD5 using 80-bit FP for accumulating the length of the input, to workaround the lack of 64-bit integer variables. It is not unusual that an implementation of multiple-precison integer arithmetic uses FP, more or less extensively.

An example where FP is put to heavy use in something reminiscent of a hash is Poly1305-AES for generic computers with IEEE floating point; that's a message authentication code which can be turned into a hash by making the key a public constant. Notice the caveat that it will not work on x86 computers running Linux, because GCC (at least, historically) did not support the required FP format.

One correction to that last paragraph (but it's a big one): Poly1305-AES with a fixed public key is not a cryptographically secure hash function; it is trivial to create preimages (not to mention collisions and second preimages). Note that this is not a criticism of Dan Bernstein's work; he never claimed that it was a hash.
–
ponchoMay 26 '12 at 13:53

@fgrieu: Thanks for the detailed response. Now I understand it better :)
–
Neon FlashMay 26 '12 at 17:08

Using double leads to funny effects like "Arithmetic on double variables is also required to be round-to-nearest; this means that, on computers that support global rounding modes, poly1305aes_53 will not work with programs that set rounding modes other than round-to-nearest", which sounds problematic to me, since some stupid libraries mess with rounding modes.
–
CodesInChaos♦May 27 '12 at 11:44