Thread

1. jstanley · 1790072957 · focus · HN ↗

   This is not the first RNG bug on Zen 2, I recall after I first got mine that some application or other would quit immediately at startup because rdrand always returned -1, i.e. all 1s. It was fixed with a microcode update.

   Do we now learn that they fixed "always generate all 1s" with "never generate all 0s"??

   EDIT: I've been unable to reproduce the problem on my CPU, FWIW. It's a Ryzen 5 3600.

   EDIT2: OK, update, I can reproduce it with rdrand16, rdrand32 is fine but rdrand16 can never generate all 0s. So my CPU does have this problem!

   1. jamesponddotco · 1790083217 · focus · HN ↗

      If I remember correctly, we had a setting in every Linux server we owned to remove CPU as a RNG seeder for the kernel because of those bugs with AMD CPUs.

      I.e., we had `random.trust_cpu=off nordrand` in `GRUB_CMDLINE_LINUX`.

      1. knorker · 1790083770 · focus · HN ↗

         Adding bad randomness can't degrade good randomness, can it?

         I thought the kernel would not replace anything just because it adds a potentially bad source.

         E.g. if you have rand source A, and xor it with rand source B, then you get, at worst, the best of A and B,

         1. teravor · 1790091728 · focus · HN ↗

            this is generally true however if an adversary is able to control a source it becomes dangerous if they can preview the results or inspect the other sources.

            1. adastra22 · 1790091977 · focus · HN ↗

               Not to the kernel random pool, no.

               1. teravor · 1790092541 · focus · HN ↗

                  this is a well known attack...

                  if your algorithm controls a source of entropy and can inspect the other sources, it can craft its source to bias the result. a fanciful attack but it means you should at least discriminate what you put into the pool.

                  1. tptacek · 1790096847 · focus · HN ↗

                     Can you link to the paper you're thinking of? Maybe people are just talking past each other here. A biased random source can't bias the kernel random pool in any straightforward kind of way.

                     1. teravor · 1790098385 · focus · HN ↗

                        I explicitly said

                            > it becomes dangerous if they can preview the results or inspect the other sources
                        

                        because the malicious source can just precompute the hash for the bias it wants.

                        <a href="https:&#x2F;&#x2F;blog.cr.yp.to&#x2F;20140205-entropy.html" rel="nofollow">https:&#x2F;&#x2F;blog.cr.yp.to&#x2F;20140205-entropy.html

                        1. adastra22 · 1790102457 · focus · HN ↗

                           You&#x27;re assuming a hash preimage attack, which would be a complete break of the cryptosystem. (Your link only works on the toy implementation given.)

                           1. teravor · 1790104580 · focus · HN ↗

                              there is no preimage attack involved.

                              while you cannot take control over the hash output you can bias it because you have multiple tries. that&#x27;s how bitcoin mining works too...

                              for cryptographic applications any bias can be engineered to be fatal in one way or another.

Unofficial Hacker News client; not affiliated with Y Combinator.