Hi Willy, Thierry > Le 6 mars 2017 à 18:34, Willy Tarreau <[email protected]> a écrit : > > On Mon, Mar 06, 2017 at 06:30:34PM +0100, [email protected] wrote: >> On Mon, 6 Mar 2017 14:54:44 +0100 >> Emmanuel Hocdet <[email protected]> wrote: >>> xxh64 is not a fingerprint class algorithme, sha256 should be use. >> >> >> Hi Manu, >> >> My choice is driven regarding these hash algorithm elements: >> >> - The repartiion of the hash (and the collision risk) >> >> - The execution time. >> >> I choosed xxh64 because it is very quick, the repartion is good and the >> collision risk is low. Obviously sha1 is better because the collision >> risk is very low, but is very slow. So I prefer xxh64. > > Yep and also in the end we only keep 32 or 64 bit of the resulting hash, > we're not doing crypto here. The typical use case is to have a reasonably > good indication whether two very large cipher lists are similar or not > without storing them.
For that we need to avoid collision, it's the propriety of cryptographic hash. xxhash collision risk is low but absolutely not negligible. False positif is a wound and the real usage of this fingerprint is out of control. For the speed, we are in a ssl connection environnement, i doubt that this is a significant argument. For the code: ssl->msg_callback_arg is considering as ssl internal. It should be a very good think to avoid internal structures/undocumented call usage to try to control the beast or limit painful compatibilities. In this case SSL_set_ex_data and SSL_get_ex_data will do the job. I will try to fix the patch, it breaks my compile environment. Manu
