I count 12 different "nothing-up-my-sleeve" numbers in the examples section. If this is a list of noteworthy ones, it wouldn't be off to say there's certainly 16 believable choices, which is already 4 bits of entropy. Hardly nothing-up-my-sleeves!
Of course 4 bits is still a lot less than, say, 128 bits.
Zcash needed to come up with parameters with a proof that they weren't back doored. They invited people to participate in a complicated (from a math point of view) distributed computation where only one participant needs to not be compromised for the final parameters to be secure.
Perhaps we should do something similar for the next generation of hash functions?
And you can gain a few extra bits by combining them or applying innocuous-looking modifications (inverse, powers, basic addition/subtraction, converting to binary in different ways, etc)
When people say, “Don’t roll your own crypto,” it’s because the field is littered with footguns and (to stretch an analogy) guns in cryptography launch explosives.
> The Data Encryption Standard (DES) has constants that were given out by NSA. They turned out to be far from random, but instead made the algorithm resilient against differential cryptanalysis, a method not publicly known at the time.
The counterexamples are more interesting than the examples!
I count 12 different "nothing-up-my-sleeve" numbers in the examples section. If this is a list of noteworthy ones, it wouldn't be off to say there's certainly 16 believable choices, which is already 4 bits of entropy. Hardly nothing-up-my-sleeves!
Of course 4 bits is still a lot less than, say, 128 bits.
There's lots more to choose from. E.g. Ron Rivest used the sine function. Could have used cos, tan, log, ln, etc. (read https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number#Li...).
Zcash needed to come up with parameters with a proof that they weren't back doored. They invited people to participate in a complicated (from a math point of view) distributed computation where only one participant needs to not be compromised for the final parameters to be secure.
Perhaps we should do something similar for the next generation of hash functions?
And you can gain a few extra bits by combining them or applying innocuous-looking modifications (inverse, powers, basic addition/subtraction, converting to binary in different ways, etc)
Computerphile video discussing the mathematics around how such a number could have been used in a practical way.
https://youtube.com/watch?v=nybVFJVXbww
https://en.wikipedia.org/wiki/Dual_EC_DRBG
When people say, “Don’t roll your own crypto,” it’s because the field is littered with footguns and (to stretch an analogy) guns in cryptography launch explosives.
> The Data Encryption Standard (DES) has constants that were given out by NSA. They turned out to be far from random, but instead made the algorithm resilient against differential cryptanalysis, a method not publicly known at the time.
The counterexamples are more interesting than the examples!
Is this different from using epoch seconds as a random number generator seed?
You can try different epoch seconds until you get a seed that fits your (malicious) needs. You can also try different RNGs until your need is met.
Can someone explain to me how
> Bcrypt uses the string "OrpheanBeholderScryDoubt" as an initialization string
Given as an example, is actually an example of this?
https://security.stackexchange.com/questions/227459/why-is-t...
The initials spell out "OBSD", as a nod to the hash being first designed for OpenBSD, and they needed a 24 char / 192 bits value.
I read that too, but given the leeway that gives the chooser of the value, it doesn’t seem like an example of the topic
(I answered the stackexchange question). I agree, it is definitely picked with that intent, but it’s harder to prove.
14 character strings that abbreviate to OBSD/English is a much larger set than the traditional picks.
When a magician does this, you know it's likely a distraction, and somewhere else there is trickery going on.
As a cryptography layman this would make me more suspicious...