Serhat, some ideas for you... https://play.golang.org/p/7QPy5wa-9eO
On Tue, Feb 12, 2019 at 9:23 AM Damian Gryski <dgry...@gmail.com> wrote: > For more information on hash function goodness tests, check out > https://github.com/demerphq/smhasher > > Damian > > On Tuesday, February 12, 2019 at 5:23:39 AM UTC-8, Serhat Şevki Dinçer > wrote: >> >> On Saturday, February 9, 2019 at 5:23:14 PM UTC+3, Serhat Şevki Dinçer >> wrote: >>> >>> On Fri, Feb 8, 2019 at 7:42 PM Michael Jones wrote: >>> > clustering: >>> > >>> https://www.cs.cornell.edu/courses/cs3110/2014fa/lectures/13/lec13.html >>> > >>> > careful hash functions often treat short inputs specially. >>> > >>> > iterated shift-xor alone is weak in expanding the "changed bits(s)" >>> signal, at least by comparison to a) large prime multiply, b) good s-boxes, >>> c) introduction of keyed material. >>> Hm, thanks. I would like to try a particular version of this prime >>> multiplication idea wih utf8 strings. >>> I wrote for loops to find collisions (attached). It takes 3 seconds >>> and finds no collision for strings with length < 4. >>> The next step (including length=4, commented in the code) will take >>> 13+ min and 32+ gb ram, so I appreciate if anyone with sufficient RAM >>> could try that and report the result ;P >>> Thanks.. >>> >> >> I got access to a server with 64 gb ram. On it, using a Go map did not >> work, so I used a list and sorted it for identifying collisions. >> It turned out both prime and shift versions (attached) of the simple hash >> turned out to be really good for small inputs. No collisions for >> 7_918_845_952 inputs. >> This required 59 GiB of ram. For a 64-bit cryptographic hash output, the >> probability of a collision for that many inputs is about %82. >> >> What I am curious about next is >> - How further can this test be taken ? When are the first collisions for >> these simple hashes with the given code ? >> - What are their "minimum sum of colliding inputs lengths" ? >> - Is there a (smooth) trade-off between being cryptographic / >> good-bit-mixing *and* being nice on small inputs / high minimum sum of >> colliding inputs lengths ? Assume that we dont treat small inputs >> differently, and there is one general algorithm for all inputs.. >> - Can a cryptographic hash function have high minimum sum of colliding >> inputs lengths, or be nice on small inputs ? >> >> Thanks.. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
