Show HN: Beamsplitter – a new possibly universal hash
1–10 of 51 posts
Re: Show HN: Beamsplitter – a new possibly universal hash
#2can someone ELI5 why this is useful over existing hash functions?
Re: Show HN: Beamsplitter – a new possibly universal hash
#3> The default S-box
> This was obtained from random.org by requesting 8,192 random bytes, as were all S-boxes tested so far.
Re: Show HN: Beamsplitter – a new possibly universal hash
#4Looks interesting! What is meant by a “universal family”?
Re: Show HN: Beamsplitter – a new possibly universal hash
#5can someone ELI5 why this is useful over existing hash functions?
god forbid existing hash function gets broken suddenly, another unbroken hash function with similar properties would be welcome
Re: Show HN: Beamsplitter – a new possibly universal hash
#6> The default S-box > This was obtained from random.org by requesting 8,192 random bytes, as were all S-boxes tested so far. https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
Yes, this is definitely not great.
Re: Show HN: Beamsplitter – a new possibly universal hash
#7> The default S-box > This was obtained from random.org by requesting 8,192 random bytes, as were all S-boxes tested so far. https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
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.
Re: Show HN: Beamsplitter – a new possibly universal hash
#8What's an S-box (substitution-box)?
Re: Show HN: Beamsplitter – a new possibly universal hash
#9can someone ELI5 why this is useful over existing hash functions?
This is how I feel when people start talking about cryptography. Definitely feel my university underprepared me on this topic. :(
Re: Show HN: Beamsplitter – a new possibly universal hash
#10> The default S-box > This was obtained from random.org by requesting 8,192 random bytes, as were all S-boxes tested so far. https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
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.
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" ;-)