@SEJPM I think you mean ‘most people who hadn't already given up in disgust appear to have been placated by Teresa's post’, which is full of platitudes and warm fuzzy wording while still doing almost nothing to address the problems. The one part they seem to have begun to claim to address is about the license.
But it doesn't even address the substantive issue with the license!
The broader point is that the company is systematically taking away agency from the communities, rather than distributing agency to the communities. The post at meta.stackexchange.com/q/344491 says nothing specific about a process for adopting license changes. It only says we will label the licenses (good) and we're looking at a process (just placating).
And even the labeling is only partly good, because nobody realized that the change was made until 1.5 years after the cutoff they picked unilaterally!
So SE.inc gets half marks for one of the five conditions I suggested.
While we are at things I discover: this question is about an article that highlights a dangerously practical attack against a deployed system, and comes from a RAID 2018 conference that entirely flew below my underpowered radar.
If the same nonce is used across different messages under the same private key, the private key can be easily revealed.
However, let's consider another scenario.
Two private keys, x1 and x2, are used with the same pair of nonces, k1 and k2. Thus, for each pair of signature (r,s) and hash messag...
@kelalaka A quick Google search and read gives me this gem:
"Once the cryptographic random-number generator (CRNG) has been initialized, reads from /dev/random and calls to getrandom(..., 0) will not block and will return the requested amount of random data"
So it blocks... initially. For the user, this will probably mean that it doesn't block.
It would be weird if it could be initialized, used and then block once I guess :P
Ah, my usual typos. Please read: Also, that hashing is not a function. For example in "Les poules du couvent couvent" the last two words have very different pronunciation and meaning.
I believe that Linux's blocking pool has outlived its usefulness. Linux's CRNG generates output that is good enough to use even for key generation. The blocking pool is not stronger in any material way, and keeping it around requires a lot of infrastructure of dubious value.
That is a huge claim
If two different users run stupid programs like gnupg, they will starve each other.
Seriously, my linux still blocks when using the JVM multiple times. That means that users can deliberately stall other persons programs even if they only can run on a certain % of CPU power.
In other words, you could stall a Java application server that uses TLS.
The question is: why do applications still use /dev/random. It should only be used for e.g. long term private keys / special cases.
If everybody would use /dev/urandom as they should, then obviously there is no need to unblock /dev/random.
@MaartenBodewes After the 5.6 change, /dev/random is actually better. (Probably. I haven't checked the source code.) The descriptions say that /dev/random behaves identically to /dev/urandom after initialization.
/dev/urandom, though, still doesn't block before gathering enough initial entropy. So it's unsafe on near-boot-time programs lacking something like RDRAND.
That said, I don't trust that this change won't be reversed or be replaced with something else bad. I'm still going to advocate getrandom instead for a number of reasons.
@FutureSecurity Huh? According to the documentation "By default, `getrandom()` draws entropy from the `urandom` source (i.e., the same source as the `/dev/urandom` device).
There was mailing list talk about "fixing" getrandom so that it doesn't block even if you don't set GRND_NONBLOCK. I think it was dropped, but I don't read the mailing list. Hopefully they didn't quietly do something like that and not document it.
Woah. They really do use the output of initialized urandom for /dev/random. The relevant function is only a few lines long. (And could be reduced to 3 significant lines.)
If you read from /dev/urandom now before it's ready then it will just write to log and return inadequate results. (Same as before 5.6. But I think the logging part is still relatively new.)
Hu, that's kind of tricky. So now you're better off using /dev/random all of a sudden? I hope not...
However, for most systems I presume the init scripts will already use /dev/random, so I guess it is unlikely that urandom is not initialized yet.
In that case they might as well block though. Hmm.
We had tons of discussions about randomness at the Java Card forum too. Very tricky stuff, especially if you have "user friendly" names for the random number generators.
If the same nonce is used across different messages under the same private key, the private key can be easily revealed.
However, let's consider another scenario.
Two private keys, x1 and x2, are used with the same pair of nonces, k1 and k2. Thus, for each pair of signature (r,s) and hash messag...
