posted in Technology
The security co-processor in many CPUs is insecure
www.heise.de/en/news/The-security-co-processor-in-many-CPUs-is-insecure-11411956.htmlposted in Technology
The security co-processor in many CPUs is insecure
www.heise.de/en/news/The-security-co-processor-in-many-CPUs-is-insecure-11411956.htmlYeah, this has actually been a known thing for a while. The government has been sneakily getting their hand into NIST standards and trying to ensure they have back doors in the commonly used “best practices”.
So as a result for instance, encryption based on pseudo random numbers generated with hashing algorithms are actually safer that these theoretically “actually random” numbers generated in dedicated security modules in hardware.
Replying to @Cocodapuf@lemmy.world
I’ve never fully understood the issue with pseudo-random numbers… but I do know there’s an issue. I know, for example, bad random number generators have been the surface area of attack for recovering HDD crypto wallets with old bitcoin balances on them.
Would you care to help me understand something, though?
I think a fair framing here is that pseudo-random numbers generators need a random “seed” (starting value) to produce the resulting random number. So if someone knows the initial seed, they can rerun the algorithm to reproduce the original “random” number.
I think what follows is that good pseudo-random number generators introduce complexity and obfuscation in how the seed is created. Perhaps they use current time, speaker input, mouse input, and some other seemingly “random” data source.
Given enough dimensions in the source material for the seed, surly it would create an intractable number of permutations such that the seed can not be reliably reproduced — right?
Like, let’s say you know a 10 minute interval where the seed was created — and the tool uses millisecond granularity. That’s 1000 (mili) * 60 (sec) * 10 (min) total possible values. If it’s also collecting mouse movement in a screen, that’s a huge number of possibilities with each given interval of movement. Adding more sources increases the number of possibilities exponentially.
So how are people reverse engineering seeds? This seems secure to me, for the same reason cryptographic keys using giant prime numbers is secure… there are just too many possibilities, and it would take eons to brute force the right one.
How are they doing it faster with seeds? Shitty algorithms not using enough data sources?
Replying to @partofthevoice@lemmy.zip
As another user said below, the biggest problem is making sure you’re using a good prng. There are really simple algorithms for generating “ok” random numbers, that’s the kind of thing you might get when you use a rand() function in a programming language. Those rand functions are plenty good enough for deciding dice rolls in a video game, but they aren’t robust enough for cryptography.
Outside of that, you’re correct that the next problem is the seed, and how much total entropy is in that seed. In this context, entropy means the total search space for the seed (“hello” would be a low entropy seed, “RPSTl6HF7mPo3g” would be a much higher entropy seed).
Like you suggested, sometimes your seed is a long timestamp combined with other factors, that makes for a great high entropy seed! But sometimes, like with a Bitcoin key, you want your seed to be recreatable, should you lose it. That’s when you tend to use a password as a seed. So the way that actually works, is that your key is a long string of binary bits, say 256 bits, and that string of bits is generated using your password as a starting seed. This process is the hashing algorithm. And this is where there tends to be a problem. Your hashing algorithm may produce 256 bit keys (high entropy), but whether it’s actually secure will depend on whether your seed phrase (password) is high entropy. You can create a key based on anything, it could be (should be) a phrase with more entropy than the key itself, for instance “my special long password with 1 secret word Brathrok” that’s a very long seed and it includes a word that won’t be in a dictionary, that’ll be hard to brute force, but easy to remember. Or… it could be a single word with low entropy, like “fool”, which is a good way to lose your bitcoin, so please don’t do that.