For one value, yes…. But for 8 different keys having stupidly low numbers? They either had a seriously faulty RNG, or more likely were hand creating the keys.
And the only reason to make a key that short is if you were trying to give them to someone who shouldn’t have them, and needed to avoid any sort of digital trail, even copy and paste… so you would obviously just memorize them.
Memorizing a bunch of 384 bit keys is basically impossible… But memorizing a couple dozen numbers? Child’s play.
Considering keys like this are usually copied and pasted anywhere they might need to be manually entered… There is zero reason to make them small enough to be human-readable, unless that’s your actual intended use.
Anyone in a position where they are responsible for generating a root key for a certificate authority, 100% knows how to generate a key in their sleep.
The only explanation is that it was made easy intentionally, not lazily.
I’m willing to sacrifice about 10 % of the range by re-rolling if the number generated has too low/high value or low entropy (for example if its GZ compression is shorter than original). The range should taper off too, for instance if 2¹²³+1 is the technically lowest number possible, it should still have a 99% chance for a re-roll, so there’s no “hard” lowest possible number. I don’t want to be in the “front line”.
Someone must have used getRandomNumber().
hey now!
4 is just as random as 29833638292F9373638292926262141414331252526283994040218 is
For one value, yes…. But for 8 different keys having stupidly low numbers? They either had a seriously faulty RNG, or more likely were hand creating the keys.
And the only reason to make a key that short is if you were trying to give them to someone who shouldn’t have them, and needed to avoid any sort of digital trail, even copy and paste… so you would obviously just memorize them.
Memorizing a bunch of 384 bit keys is basically impossible… But memorizing a couple dozen numbers? Child’s play.
You underestimate the power of laziness and incompetence, I think
Considering keys like this are usually copied and pasted anywhere they might need to be manually entered… There is zero reason to make them small enough to be human-readable, unless that’s your actual intended use.
“I need a 384-bit key… I have no idea how to generate one… oh, screw it… 4”
Anyone in a position where they are responsible for generating a root key for a certificate authority, 100% knows how to generate a key in their sleep.
The only explanation is that it was made easy intentionally, not lazily.
If that’s what they needed, just remember an equation that turns easily remembered numbers into a 384 bit key.
Lol. So random xd
I’m willing to sacrifice about 10 % of the range by re-rolling if the number generated has too low/high value or low entropy (for example if its GZ compression is shorter than original). The range should taper off too, for instance if 2¹²³+1 is the technically lowest number possible, it should still have a 99% chance for a re-roll, so there’s no “hard” lowest possible number. I don’t want to be in the “front line”.
Of course, here the RNG was clearly compromised.