Is it possible to generate an already existing seed?

[nullius]

I do not trust - neither in someone else's god, nor in someone holding my private keys  ;D

I am reading about entropy, especially in the bitcoin discussion, but not sure what is considered a good "value"  ??? for entropy/randomness.
There is this thread from May 2017, which seems to indicate, that most modern unixoide systems have a good entropy. And of course I just checked my OSX and OpenBSD boxes, which show the expected (seemingly good) results.
How is this linked to bitcoin? Any hints?

Well put about trust.  I began writing a long post here.  Rather than much delay my reply, and to better stimulate active discussion, I hope to address your questions a bit more concisely—if much less elegantly:

On a brief skim, I see some problems with that Calomel.org page:  0. It places too much reliance on statistical tests.  As I said above, statistical testing can prove that RNG is flawed, but can never prove it to be sound.  Experts faced this problem with the Intel RDRAND/NSA BULL RUN fiasco.  Try encrypting the output of /dev/zero with AES-CBC, approximately `dd if=/dev/zero bs=1m count=1 | openssl enc -e -aes-256-cbc`, and running the statistical tests on that; all tests will pass!  1. It gives advice on tuning your software RNG and also on hardware entropy gathering, all of which must be carefully audited.  2. It is outdated.  For example, I have not kept up with the latest in OpenBSD development; but I am under the impression they completely ripped out the flawed ARC4 cipher, replaced it with some ChaCha variant (one of djb’s stream ciphers), and deprecated /dev/arandom.  The Calomel page (wrongly) recommends symlinking all other random devices to /dev/arandom.  (Not sure about these things.  I’m not an OpenBSD user.  Please double-check.)

An excellent link in my prior post to which I should have given more attention is John Denker’s Turbid.  I do not know the exact status of its software implementation; but the Turbid paper will answer many of your questions much better than I could.

I do think that most modern “unixoide” systems (as you put it) will have adequately secure kernel random devices.  (I think I may borrow that terminology from you!)  Thus my repeated advice, read() off /dev/urandom.  If you have only one takeaway from this thread, please let it be that.

How is this linked to Bitcoin?  In brief:  If your randomness generator is flawed, then you risk losing all your money.  There are people who scan the blockchain for evidence of coins they can snatch this way.  Solution:  Use a good PRNG!  Most importantly, don’t break an expertly designed and implemented kernel RNG by trying to improve it.  Most Bitcoin users don’t get their coins stolen due to a bad PRNG; this should put things in better perspective.

If you need to generate some Bitcoin keys yourself, read() off /dev/urandom.  That’s what I do; see e.g. the sources of easyseed (forum thread).  If you run Core, then let Core do its job; there are Core developers who could run circles around me on this subject, and they pay careful attention to these issues.  (I don’t trust much other Bitcoin software; most of all, I explicitly distrust the popular save-a-webpage Javascript Bitcoin tools.)

Finally, please note:  I myself am not a cryptographer.  I wish to make that absolutely clear.  I am a programmer strongly oriented toward privacy and security; and I believe myself to be crypto-savvier than most.  I trust myself to tinker with my kernel’s PRNG—mostly because I know enough to know the limits of my own knowledge, so I know which parts of the code I must not touch.  I do trust myself to choose between cipher implementations; I do not attempt to write my own cipher implementations.  Likewise, wherever I feel my knowledge may be shaky on any subject, I will say so rather than risk giving you bad information.  I have already done so in this thread.

1. Is this a good idea to generate random numbers with physical dice? I've heard that cheap gaming dice have poor quality of randomness, and if their sides are not a power of 2, you have to do some additional operations to remove bias when generating random bits.

You refer to “modulo bias”.  It is one of those subtle DIY crypto dangers of which most people are totally unaware; props to you for even knowing about it.  I will later write another post explaining this, with a little quoted code snippet for avoiding the bias.

2. Does quality of RNG that collects entropy becomes better with the system uptime - i.e. should I wait some time (while moving my mouse around and typing something?) before generating a new Bitcoin wallet after turning on my cold storage machine?

I tend to feel that way, too; but I recognize that it is a superstition, at least on properly designed and implemented system.  Your randomness generator should have two pertinent states, seeded and not seeded.  As soon as it reaches the former, it’s as good as it will ever get.⁰  Before that, it is in the latter state—and it should block, refusing to give any output.

Unfortunately, the Linux random/urandom system is not designed this way.  I am strongly critical of this.  Violating what I said above, the one time you should avoid using urandom instead of random is during or soon after the boot sequence.  urandom will give output, even when the generator as a whole has never been properly seeded.  This is only a concern if you run Linux.

0. I here wholly omit discussion of recovering from state compromise.  In the context of a kernel RNG of a running system, I am of the school of thought that this is somewhat ridiculous:  An attacker who can read your kernel’s internal state can probably grab your keys from userspace, too.  However, I may consider this opinion in view of Meltdown and Spectre; thanks for giving me the impetus to think it over.

[1714317824]

1714317824

[1714317824]

1714317824

[1714317824]

1714317824

[Spendulus]

1. Is this a good idea to generate random numbers with physical dice? I've heard that cheap gaming dice have poor quality of randomness, and if their sides are not a power of 2, you have to do some additional operations to remove bias when generating random bits.
......

Sixteen side dice are available and enable quick and easily producing random numbers.

Any computer library random function has serious defects.

Side note.
It's likely possible to build a random generator with basic electronic parts, such that it's all out in the open and can be examined.

[nullius]

Sixteen side dice are available and enable quick and easily producing random numbers.

Any computer library random function has serious defects.

Side note.
It's likely possible to build a random generator with basic electronic parts, such that it's all out in the open and can be examined.

This is wrong.  “likely possible”?  Is that how you give cryptography advice?  Is it, or isn’t it?  Can you do it?  Have you done it?  What can you demonstrate about the security properties of the results?

Back up one moment.

I could explain why I trust my system’s CSPRNG, in terms which reduce to my security assumptions about the properties of certain things (such as hash functions).  It may come out a bit muddled, and much less rigorous than a professional cryptographer would do.  But I could explain in some detail why I think my computer’s CSPRNG is secure.  (It would be a waste of my time and readers’ time; read something rigorous by an actual cryptographer if you want that level of detail.)

Can you explain what you said?  You made a positive assertion of “serious defects”.  Can you identify what they are?

This is an important question.  What you said encourages homebrew.  In crypto, almost invariably that results in a festival of foot-shooting.  (Are those hexadecimal gaming dice really well balanced?  Are you sure?  Also, are you aware of the research literature finding biases in actual flips of actual coins?)  Worse, you waved your hands and said it’s “likely possible” to cook up some homebrew electronic randomness gadget.  For anybody who lacks deep expertise in both maths and physics, this is a guaranteed security disaster.  (I linked to John Denker’s site.  He’s a physicist.  He has enough knowledge to design his own stateless random symbol generator based on thermodynamic noise in analogue circuits—still not using any home manufacture, either; just an ordinary computer soundcard.  I don’t have that knowledge; I am pretty sure that you don’t, either.)  Worst of all, deterring people from reliance on a good CSPRNG is sending them in the wrong direction.  That’s bad advice!

Also, I should emphasize, you said “library functions”.  I spoke above about the kernel, which has access to the hardware and can seed its PRNG until it contains not less than 256 bits of unpredictable interal state.  “Use /dev/urandom”.  I am not here saying that library functions are flawed!  Some are excellent; but they, too, must be seeded from somewhere—that is, from the kernel via the random device.

[Spendulus]

Sixteen side dice are available and enable quick and easily producing random numbers.

Any computer library random function has serious defects.

Side note.
It's likely possible to build a random generator with basic electronic parts, such that it's all out in the open and can be examined.

This is wrong.  “likely possible”?  Is that how you give cryptography advice?  ....

This is an important question.  What you said encourages homebrew......

You certainly covered a lot of ground in that response. At this moment my time is short so let me cover a couple of points.

A. Anything that can be construed as encouraging home-brew is wrong.

B. Dice cannot be the "home-brew" of which you warn against.

C. When I mentioned making random generators, I had basic transistor theory in mind. Google quickly enough shows people have done it many times. Here 'ya go.

https://makezine.com/projects/really-really-random-number-generator/

What I was getting to here is the idea that this is all out in the open, like open source code. Anyone can examine it, and let's say anyone can connect a test probe anywhere in the circuit.  What you see is what you get. You can criticize it and find flaws, then the circuit can be revised and improved. But still it's all totally out in the open.

Now on the contrary, say that I encapsulate and miniaturize this circuit, and sell it to you. In fact you don't know what is inside that black box.

Similarly you don't know what is inside the "black box" of your CPU. Not without some serious lab work, and even then I would argue that you know in part only.