# Elliptic Curve Cryptography (ECC) Support

#25

sweet thanks for thank info… nice read

#26

by the way, another small question; how should EC keysizes be selected? is there some kind of rule of thumb like “half the size of the RSA key” or whatever to get an EC key with similar security as an RSA key with a chosen size?

#27

EC keys can be 256, 384, and 521 bits. Using 521 can break compatibility, you should choose between 256 and 384.

256 is equal to 128-bit symmetric encryption. Most of the time I use 384, but it’s just for 100% key exchange on SSL Labs, not really smart.

#28

oh there are size restrictions.
I will certainly take the highest, because it’s a site only I use anyway (prass-protected) and I am overdriving the security anyway (16384 bit RSA cert is what I use now)

but why 521? 256 is the result of 2^8 and 384 is 128+256, 521 looks kinda weird…

#29

I just use ECC 256bit it’s equivalent to RSA 3072bit

FYI, ECC needs adequate levels of system entropy on your servers too … more so if you’re on virtualized and headless VPS servers

The ECDSA digital signature has a drawback compared to RSA in that it requires a good source of entropy. Without proper randomness, the private key could be revealed. A flaw in the random number generator on Android allowed hackers to find the ECDSA private key used to protect the bitcoin wallets of several people in early 2013. Sony’s Playstation implementation of ECDSA had a similar vulnerability. A good source of random numbers is needed on the machine making the signatures. Dual_EC_DRBG is not recommended.

for my Centmin Mod LEMP stack installer I also install haveged to pop up the level of available entropy for ECDSA usage so /proc/sys/kernel/random/entropy_avail always hovers above 3900-4000 mark

Further, entropy is just a measure of unpredictability in a sequence, not an actual pool of stored bits. The larger the estimation on entropy, the more likely certain things will have unpredictable behaviors, such as a sequence of random numbers.

Again though, the Linux kernel file /proc/sys/kernel/random/entropy_avail is just an estimation. When you have an entropy pool of “4096 bits”, this just means that the random numbers being generated have the highest quality of unpredictability you can produce. As the entropy pool estimation drops, the confidence in the sequence of random numbers also drops. When the entropy pool is 0, the kernel will block at generating random data until the pool can be filled again. As you generate random data, it reduces the estimation on entropy. This is the behavior of /dev/random.

In other words, think of the entropy pool as a “crypto thermometer”. When the meter is at “full up”, the generated numbers will be very difficult, if not near impossible to reproduce, and highly unpredictable. When the meter is completely empty, generating random bits could be reproduced by a 3rd party with little knowledge of the system accurately.

#30

nah I go as far as I can. especially if I am the only one who uses it anyway.

#31

[quote=“jsha, post:21, topic:34, full:true”]
As with so many questions, the answer is: we’re trying to focus our offerings on one thing and launch that, then expand incrementally from there.[/quote]

Makes sense.

[quote=“jsha, post:21, topic:34, full:true”]
In order to offer ECDSA certs, we will need to hold another key generation ceremony, where we securely generate the signing keys in our HSM, recorded in front of witnesses.[/quote]
As I said before: this isn’t necessary: CSR’s with ECDSA public keys can be signed with a RSA private key like the current Let’s Encrypt Intermediate certificates…

This results in something like:

``````   Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
xx:xx:xx
ASN1 OID: secp384r1
``````

Signature Algorithm: sha384WithRSAEncryption
xx:xx:xx

[quote=“jsha, post:21, topic:34, full:true”]
We also need to modify our “safe key” checks to do checks that are suitable for ECC keys, and provide a method for clients to indicate whether they would like an ECDSA cert or an RSA one (a small protocol change).[/quote]
Or just offer the ECDSA certificates via custom CSR’s while only offering RSA via the normal route.

I can’t wait!

#32

This is a good point, I forgot about this. Thanks! So the main obstacle for these hybrid certs would be adding a GoodKeyECDSA function to provide similar functionality to our GoodKeyRSA function. The Baseline Requirements say:

#33

your SSL negotiation times will suffer and thus page load speeds as you go higher see https://casecurity.org/2014/06/10/benefits-of-elliptic-curve-cryptography/

• at ECC 256bit = RSA 3072bit
• at ECC 512bit = RSA 15360bit

#34

This is related to Mersenne primes. Maybe, for such a big size it’s faster than 512.

#35

well it will still be a lot faster than my 16384 bit mega-key

#36

well if it’s a site only you use, you might as well just connect to it via a VPN

#37

I dont wanna install a VPN everywhere I wanna access my cloud and stuff…

HTTPS is a LOT easier.

and well if I would put my music that I wanna listen to myself on a site that’s not secured properly I might get lawyers, coz it would be illegal sharing.

#38

I see there’s a stub already

#39

guess your usage is different, but you can still access cloud storage usually even through VPN…

I use L2TP IPSEC and OpenVPN VPN private servers for all my internet and mobile device connections and they connect fine to all my cloud servers and cloud storage services.

#40

well when I am at a work PC or whatever it’s just easier. and well I use just my PC for that stuff so this isnt uploaded anywhere but at home.

#41

Yeah when not in control of your work PC can be a bit more problematic. I work from home so all my PCs, laptops, tablets and mobile devices are setup to auto connect through my own private VPN servers to the internet. Once setup, I never have to do anything else.

#42

but well you have to setup VPN to start and for some or another reason I needed another software on my PC to connect to the VPN of an earlier workplace,a dn well I dont wannt to need to install extra software, portable and browser-services 4ever

#43

yeah i guess… although depending on OS some have native support i.e Windows and L2TP IPSEC VPN native support so no added software

ah someone bring this back to ECC talk hehe

#44

@My1 You would not the only one who would use ECDSA with RSA key.
MAy java implementation would be ready to generate ecsda csr and select the cert based on browser support.