[barbegal]

It would have been far better to select numbers generated by the NIST Randomness Beacon https://beacon.nist.gov/home

And whilst you can sort of selectively choose which values to take from the beacon, it should reduce the ability to add a backdoor.

[owenmarshall]

There are plenty of digits in pi.

If the hash is secure independent of s-box selection, I'd much rather bet on pi being normal than "the NIST beacon values aren't generated by AES in CTR mode" ;-)

[knodi123]

> There are plenty of digits in pi.

Yes, but

"These fears can be allayed by using numbers created in a way that leaves little room for adjustment. An example would be the use of initial digits from the number π as the constants. Using digits of π millions of places after the decimal point would not be considered trustworthy because the algorithm designer might have selected that starting point because it created a secret weakness the designer could later exploit."

[skykooler]

So why not just use the first 8192 bytes of Pi?

[fdupress]

Because they are known in advance and you could design to exploit their structure.

[owenmarshall]

> Because they are known in advance

That's the point.

The stated design - which I haven't reviewed in depth, but let's roll with it - is predicated on the use of a random s-box. Their goal is to have half zeros, half ones. That strikes me as strange, because my understanding is that confusion typically comes from balancing output bits for any given input bit.

But fine, we'll take it. I'm willing to bet the first 2^13 digits of pi are as balanced as any random number you use to bootstrap this thing.

FWIW, AIUI, totally random S-boxes typically give great non-linearity but perform poorly against differential cryptography. I'd bet that if anyone tested this one out that's where it would fail.

[ixwt]

How could this argument not be used in the same way for these "random" bytes? Is there some way to verify that these were sourced as they said? Can we also be sure they weren't chosen by generating several million bytes to find the best "random" bytes that could be exploited?

[ohvirginia]

this was not meant to create some mystery around the included s-box, though I get that it does do that.

the funny thing is the very fears that are being promoted about this are in a way, sort of exactly the weaknesses that this parameterisible family of hash function was designed to secure against.

I mean people are afraid that there's somehow malevolent design floor but that could be true in any hash function with this you can use the structure to create your own hash function but bringing your nest box which to me at least greatly reduces the idear that there's some sort of exploit that could be persisting.

anyway, that unintended mystery is not bad at all in I'm my opinion. it's fun to watch people suspect byes I got from random.

it's also flattering because I think the skill required to create some sort of crazy exploitable sbox is way above me and way above the level of skill required to create a very good hash function.

people thinking that was my plan, hear this, it does not sound like a very smart plan to spend all that effort creating one amazing exploitable sbox that looks random but then at the same time say and even encourage people to use their own sbox.

I don't feel the suspicion of the sbox being bad actually requires any defense of it, because it seems just ridiculous to me, but I do think it's interesting to point out, like, that sort of a plan suspected doesn't really make sense.

I'm not saying the people who have such suspicions are ridiculous at all. they just haven't thought it through, I think and I understand the instinct to paranoia especially directed at works in this space. I think it's a fairly appropriate instinct. you just need to think things through.

the point was by using an s-box, you can bring your own s-box, to allay (or I guess create) such fears about exploitable designs, and create your own hash function.

some thoughts about how to do that I invite in the readme. I'm not prescribing rules. pick your own, pick whatever you like. The point is you can make your own hash function that will probably be a good hash function. I definitely think you should test it with smasher, or whatever, to make sure it doesn't have any kind of flaws. I'm fairly convinced, after testing a few random boxes, you'll be highly likely to make your own good hashes with this.

[owenmarshall]

> I'm fairly convinced, after testing a few random boxes, you'll be highly likely to make your own good hashes with this.

https://www.schneier.com/crypto-gram/archives/1998/1015.html...

Read and internalize this.

[ohvirginia]

I tried to correct spelling errors here but couldn't edit somehow.

[ohvirginia]

that's a good idea. if you want to post some code turning some historical nist randomness beacon data into 1024 64-bit integers, then test it and run it against smasher using the included utilities script (to run tests in parallel) I'm happy to include the results in the readme.