This reply has brought me to the simple question: How does Let’s Encrypt create the private key?
As this is an important step of deploying HTTPS I think that’s a question which should be asked.
So specifically:
Does the Let’s Encrypt client have it’s own implementation or does it (e.g.) use OpenSSL?
Which key length does it use for RSA certificates? 2048 or 4096bit?
Does it somehow collect additionally entropy (e.g. by letting the user enter crap into an input field or moving the mouse - although this of course is not often possible in most cases as the server often only have a terminal) to /dev/random or /dev/urandom.
More information: Understanding and Managing Entropy Usage, Entropy and Random Number Generators
The answer is going to be different for every client, of course.
The official Let’s Encrypt client can either use an already-created key pair, which you can generate under any circumstances you prefer, or it can perform the generation for you, which it will do with OpenSSL, see letsencrypt/crypto_util.py.
The Let’s Encrypt official client does not currently mix any additional entropy into the pool, so it’s a good idea to run it after the system has been up for at least a few minutes.
The key length for RSA defaults to 2048, but you can adjust up it with a command line flag.
The official Let's Encrypt client can either use an already-created key pair1, which you can generate under any circumstances you prefer, or it can perform the generation for you, which it will do with OpenSSL, see letsencrypt/crypto_util.py4.
Okay, thanks for the reply. So basically it just uses OpenSSL too.
The Let's Encrypt official client does not currently mix any additional entropy into the pool, so it's a good idea to run it after the system has been up for at least a few minutes.
Okay, good to know. But maybe that's something you can add in future versions.
The key length for RSA defaults to 2048, but you can adjust up it with a command line flag.
It might be interesting to see how good the entropy collection is for newly installed servers in a VM (maybe by instrumenting the kernel RNG and seeing exactly which measurements it took in order to seed the RNG). The answer might be very different for desktop and server systems.
I don’t want to promote unsubstantiated rumors and superstitions about entropy and RNG seeding. If you’re not sure if your system has enough entropy when generating a key (which past research showed was a real risk for some embedded systems that boot unattended with no user interface), you may be able to add more by entering unpredictable text or data into your /dev/random device, ideally from a source and over a channel that would be hard for an adversary to observe. I would say that more research is needed to confirm whether there are other common situations in which this is of real benefit.
There was a discussion about whether it would be beneficial to have the ACME server contribute entropy to the client (which could then add that entropy to the local RNG pool). I think this discussion was happening inside the ACME working group at IETF, and I don’t know what its result was.
One risk of this approach is that if the client has initialized its RNG with a completely or highly predictable state, the server would then be able to predict what the client’s private key will be. (In some models a network adversary might also be able to do this because the client with a poorly-initialized RNG may not be able to establish a crypto session to the server that successfully conceals the contents of the entropy that the server is providing: the network adversary may be able to infer the value of the session key that protected the entropy download.)
Okay, that makes sense. However I didn’t thought about getting the entropy from a server as this is unsecure by design. (You could maybe get some from https://random.org as an independent third-party, but that’s still bad as this data is send over a connection)
I thought much more about a client implementation where the user is, after the license agreement or whatever you have to agree there, asked he should type some useless characters.
LE could then use the time between the key strokes (see Keystrokes dynamics) for a entropy source.
I don’t see the Let’s Encrypt client trying to directly use its own RNG of any kind in place of the operating system’s RNG. However, if we think there are reasons why the OS RNG might be inadequately seeded, we might be able to try to find ways to seed it ourselves.
Getting entropy from a server can be better than the alternatives in some models.
On the bright side, the user has to type a little bit in order to run the Let’s Encrypt client, select options, and optionally enter a recovery e-mail address; hopefully the OS is getting something from the variable packet timings there, even on a freshly-installed and freshly-rebooted system.
We could also ask some of the hosting providers (or server OS developers) what they’re doing to try to ensure fresh instances are decently seeded, since it’s something that’s best dealt with overall at that level. The PGP experience may have misled people a bit this way: PGP was originally designed to run on systems like DOS that had no OS CSPRNG whatsoever, so your only possible CSPRNG was one that shipped inside the application. Most modern operating systems do have a supposedly decent CSPRNG that applications can simply use without doing their own entropy collection step, yet GPG and KeepassX and maybe some other applications don’t seem to trust it, maybe to their own detriment. The big risk as I understand it is not so much that an individual application would fail to collect entropy as that a key generation step could happen very early in the lifecycle of an OS boot, or on a machine that has unusually few sources of physically unpredictable events.
that should work… my Centmin Mod LEMP stack by default installs haveged to increase the available entropy on VPS/Server installs as I also play with and use ECC 256 bit SSL certificates which require a higher level of available entropy (of course this only applies to non-virtualized or non-openvz virtualized servers i.e. Xen, KVM, VMware)
OpenSSL uses /dev/urandom on the host system. We don’t think that we have expertise that would make users safer by tampering with the entropy sources for key generation instead of using OpenSSL defaults.
If users have specific requirements about entropy sources, they are definitely welcome to use daemons that seed the local kernel CSPRNG differently or modify their OpenSSL behavior to use different or additional sources. Our intuition is that nothing that we know how to do or suggest is guaranteed to make things better in this area. (If anybody thinks they have a generally-applicable improvement for key generation behavior, the OpenSSL project is a better project to propose it to.)
I believe that entropy contribution is always helpful. Even if the entropy is sent by an attacker it can’t reduce the randomness of the private key generated.
So, sending entropy from the ACME server to the lets encrypt client can help in a enviroment with very low entropy and It can’t harm if the entropy was hypothetically harmful.
@rme, that mechanism was suggested for the ACME protocol in the past (mostly to benefit embedded devices and perhaps some VM images that might have poor seeding), but I think it wasn’t incorporated in the version of the protocol that we use. If you’d like to advance that suggestion, I would suggest bringing it up in
because doing this would require protocol changes and support on both the client and server side.
@rugk, yes, and users are welcome to use it if they think it’s valuable.
The notion of the entropy pool “running dry” is not one that I think is well-supported by expert opinion. The problems that we’ve seen in the wild have had to do with CSPRNGs not being properly seeded in the first place, or being used before they were seeded, rather than with subsequently “running out” of entropy.
Okay, just asked again, becaue you replied to @AliceWonder who exactly said that and you explained something completely different (not mentioning haveged with a single word ).
how about that every PC who has a microphone installed uses this as an additional source of entropy especially since microphones have tolerance and there is defferent noises everywhere, the running PC, ppl talking, whatever it should be rather hard to do something about that.
Specifically what tends to happen is the builder of an OS image wants a separate key for every system that uses that image. So they put key generation in a "first boot" script but especially on a system with no hard drive the "first boot" can be an extremely predictable process giving the kernel little to no opportunity to gather real entropy which can lead to the keys being much less random than they should be.
One lesson from this is to try and avoid using keys generated on first boot. Much better to let the letsencrypt client generate a new key than to use one that was generated on first boot by your OS image.
Mostly we talk about servers/VMs and possibly things like embedded devices here, because all other devices should have enough entropy as they are in daily use.
And I highly doubt that you have a microphone at your server or linked to your VM…
(of course this only applies to non-virtualized or non-openvz virtualized servers i.e. Xen, KVM, VMware)
).