Systemd Will Now Use RdRand Directly If The Kernel Can't Deliver Entropy

[shmerl]

Can't Intel / AMD simply document what they made? And someone can possibly verify it.

[starshipeleven]

Can't Intel / AMD simply document what they made? And someone can possibly verify it.

It's pretty hard to verify as long as it is inside an IC and the only interface to operate it is a CPU instruction, as you have 0 access to the actual hardware doing the work, it's all behind a screen.

If they implemented it in some external module over some normal interface then yeah you could verify it.

Like (and here comes the shilling) the ChaosKey, a off-the-shelf ubiquitous microcontroller running a opensource firmware that is basically just taking measurements of the noise generated by a dumb electronic circuit that is also open hardware, and sending the entropy over USB 1.1 connection to the system.

[RealNC]

The only way to boot my system right now (Sandy Bridge) is to install rng-tools and enable the jitter entropy source.

[soulsource]

Wait a second.
Why does hashtable generation require a random seed? Are the hash functions modified every boot? If yes, what is the purpose of this, and why is it so security relevant that making it use only good quality random numbers is even an option?

[smitty3268]

Can't Intel / AMD simply document what they made? And someone can possibly verify it.

Even if they fully documented exactly what their hardware does, how would anyone know that the info released actually matches what the hardware in silicon is doing? Anyone could have messed with the design at the factory and introduced a flaw... On top of which, there are open software encryption implementations like Speck which anyone can look at, and try to find flaws in, and nobody can - yet lots of people still think there's a flaw in there somewhere and people just haven't found it yet. It's an extremely complex field and experts in it are few and far between.

The bottom line is you have to either make a choice to choose to trust them, or not. It's impossible to prove a negative.

[treba]

Wait a second.
Why does hashtable generation require a random seed? Are the hash functions modified every boot? If yes, what is the purpose of this, and why is it so security relevant that making it use only good quality random numbers is even an option?

If you know the seed of an hashmap, you can DOS it by making it save objects in the least optimal way. This is also quite dangerous for web services.

That said, it's a rather weak attack here. Most people definitely don't need to worry

[pal666]

I think it refers to quality in terms of their imagination. This entire dilemma is completely pointless, this entire process could be completely removed and absolutely nobody would notice, It is utterly unnecessary.

you are unable to think. this entire process of you trying to think could be completely removed and absolutely nobody would notice, It is utterly unnecessary

[pal666]

... should actually be this:



(change in bold)

no, in reality it shouldn't be that, reality is completely different. that parameter is function parameter and that function with that parameter existed before. when high quality was not required and randomness was not available from kernel that function returned error. now it tries to use rdrand and then prng.

[pal666]

If you know the seed of an hashmap, you can DOS it by making it save objects in the least optimal way.

if you have any say on what keys go to this container. like if you are authoring service files, but then you could dos your system anyway

[pal666]

Wait a second.
Why does hashtable generation require a random seed? Are the hash functions modified every boot? If yes, what is the purpose of this, and why is it so security relevant that making it use only good quality random numbers is even an option?

hashtables degenerate into lists if you put keys with same hash value there. so be smart and use something better like rbtrees