3 ms·
My response to Linus: I'm OK with this as a starting point. If a jitter entropy system allow us to get pass this logjam, let's do it. At least for the x86 ar
by tytso 7y ago
My response to Linus:
I'm OK with this as a starting point. If a jitter entropy system allow us to get pass this logjam, let's do it. At least for the x86 architecture, it will be security through obscurity. And if the alternative is potentially failing where the adversary can attack the CRNG, it's my preference. It's certainly better than nothing, in that in that very worst case, "security through obscurity" is better than "don't block, because blocking is always worse than an guessable value being returned through getrandom(0)". And so if these are the only two options, I'm certainly going to choose the former.
That being said, I'm still very worried that people with deep access to the implementation details of a CPU might be able to reverse engineer what a jitter entropy scheme produces. For that reason, I'd very much like to see someone do an analysis of how well these jitter schemes work on an open, simple architecture such as an RISC-V iplementation (you know, the ones that were so simplistic and didn't have any speculation so they weren't vulnerable to Specture/Meltdown). If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA.
In the long term (not in time for the 5.4 merge window), I'm convinced that we should be trying as many ways of getting entropy as possible. If we're using UEFI, we should be trying to get it from UEFI's secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on.
After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn't problem in practice. We need to get back to that place where in practice, we've harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security.
(The above is a lightly edited almagamation of https://lore.kernel.org/r/20190930033706.GD4994@mit.edu https://lore.kernel.org/r/20190930033706.GD4994@mit.edu and https://lore.kernel.org/r/20190930131639.GF4994@mit.edu https://lore.kernel.org/r/20190930131639.GF4994@mit.edu)
- pjc50 7y ago> "don't block, because blocking is always worse than an guessable value being returned through getrandom(0)". It seems that this fight has continued for so long because both possible answers are valid here, depending on the exact use case of the system as a whole(+)? Have we got an interface which lets you properly specify the paranoia vs. best-effort choice yet? (+) e.g. the SSH server running on your lightbulb may accept that it's not exposed to the internet and therefore not subject to targeted attack, but it's really inconvenient to sit in the dark, so the security-availability tradeoff is worth it. > most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security. Was it ever? It seems that phishing the admins has always been the easiest way.
- justincormack 7y agoIf your lightbulb is running ssh not telnet it is assuming some source of entropy, or it may as well be running telnet. There has been some work on hardening handshakes on protocols where randomness might not be available that it could look at.
- derefr 7y agoDoes that really need to be true? Protocols with fixed keys can skip Diffie-Hellman, right? As such, is there an option to configure OpenSSH such that it has a fixed authorized_keys, and does the authentication handshake in the opposite order: first establishing that it can talk to the client by decrypting the messages the client is sending; and then parsing the client’s auth commands from said decrypted stream, where one SSH AUTH message might be “auth me using the very key we’re conversing over.” If there is, I’m surprised IoT devices don’t go for it. If there isn’t... why not?
- shandor 7y ago> As such, is there an option to configure OpenSSH such that it has a fixed authorized_keys At least you can override the default functionality with your own by utilizing the "authorized keys command". It basically allows you to create your own authorization scheme instead of the default "key in file means access granted"
- tialaramex 7y agoNo, you can't do this in SSH, it would be a radical re-design. I'm not completely certain that it's impossible to make this secure, but it's definitely very easy for it to get done in a way that's insecure.
- tialaramex 7y agoNow I'm in front of an actual PC let's explain a bit more It's absolutely critical in SSH that we end up with a unique session ID which will be the output of a cryptographic hash function (these days maybe SHA-256) but obviously the input to that function must be secret. Everything in the higher level parts of SSH assumes that there is a secret unique session ID. The session ID stays the same for the lifetime of a connection, although you can run key agreement itself again if the connection is long-lived or moves a lot of data so that it's unwise to keep using the same symmetric keys. If you do any variant of DH obviously this session ID is the end result of the first DH key agreement process and so it'll be different every time because you're using random numbers. But if you want to add a "fixed asymetric keys" mode you're going to need to agree a secret session ID for each new connection... somehow. At some cost you could pick at random and send it from one party to the other, but then we're exactly back where we started about how we're assuming we have a good source of entropy. If we just pick any fixed value it might as well be 0000 0000 0000 0000 and so on then obviously a bad guy can break everything and we should have just used telnet.