Hot answers tagged

103

You are misreading Bernstein and Lange's advice (admittedly, their presentation is a bit misleading, with the scary red "False" tags). What they mean is not that some curves are inherently unsafe, but that safe implementation of some curves is easier than for others (e.g. with regards to library behaviour when it encounters something which purports to be the ...


70

No, longer is not better. Let me explain. In symmetric cryptography, keys are just bunches of bits, and all sequences of bits are valid keys. They have no internal structure. Provided that you use decent algorithms, the best possible attack on a key for symmetric encryption is brute force: the attacker tries all possible keys until he finds the right one. ...


61

Key strengths, and their equivalences, become meaningless when they reach the zone of "cannot be broken with existing and foreseeable technology", because there is no such thing as more secure than that. It is a common reflex to try to think of key sizes as providing some sort of security margin, but this kind of reasoning fails beyond some point. Basically,...


55

To add a bit of information on what @CodesInChaos says: When you use ECDHE instead of DHE, you may obtain the following advantages: Better performance. ECDHE is faster, for a given security level; @CodesInChaos points to an article which gives figures; see also this answer for why elliptic curve offer better performance. Smaller messages. An ECDH public ...


37

There's a slide deck on NIST by Rick Andrews, Senior Technical Director and Distinguished Engineer of Symantec, titled Symantec’s View of the Current State of ECDSA on the Web (published 2015) providing great insight: What is holding back the market for ECDSA certs? Legal/IP concerns were not allayed by the 2003 NSA-Certicom license Distrust in ...


29

There might be a bit of confusion here between "RSA Laboratories", the organization that edits the PKCS standards, and RSA, the cryptographic algorithm. PKCS#1 is one of the PKCS standards, thus edited by RSA Laboratories; it talks about the algorithm RSA, and only about the RSA algorithm. In particular, there is no such thing as a "PKCS#1 format" for ...


25

I see two main reasons why you might not want to use ECC: Practical reason: communication necessarily involves two parties, the sender and the receiver. ECC can be used only if both sender and receiver support it. As you noticed, existing, deployed implementations are not necessarily up to it yet; if you use an ECC public key, people may send you messages ...


25

TL;DR: There is nothing technically wrong with ECC; in fact it has better bandwidth and server CPU load than RSA (but higher CPU load on browsers, thanks @CodesInChaos), but for historical reasons it just sorta never got adopted. Disclaimer: I work for Entrust Datacard Entrust is one of the publicly-trusted CAs, and we have separate publicly-trusted PKIs (...


21

This seemed to be the command you want: openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650


19

The main culprit is NSA Suite B -- or, rather, people who read that document as something that it is not. NSA Suite B says that NSA uses curves P-256 and P-384. Some people have chosen to interpret that as "don't use any other curve". P-521 (aka "secp521r1") is not one of these curves, hence its removal. There is nothing wrong with P-521, except that it is, ...


18

The current challenge in building a quantum computer is to aggregate enough "qubits", entangled together at a quantum level for long enough. To break a 1024-bit RSA modulus, you need a quantum computer with 1024 qubits. To break a 160-bit elliptic curve, which has a "similar strength" (with regards to classical computers), you need something like 320 qubits. ...


16

The limiting factor for an attacker using a quantum computer is the number of qubits they can keep entangled long enough to perform a calculation. The qubits required to crack RSA keys are estimated to be 2•bits while ECC is roughly 6•bits, but RSA keys are generally much longer so they end up taking more qubits; roughly 3x on the low end (2048 vs 224) and ...


16

It's uncommon to see a signature by a root certificate using ECDSA, because most root certificates contain RSA public keys, not ECC public keys. Moreover, because root certificates must be installed on client devices, updating certificates and/or adding new certificates has its logistical challenges. But, as Mike Ounsworth points out in his answer, there ...


15

I'm not satisfied with my previous answer that lead to confusing assumption about compression method used in ed25519, so I will try one more time for those who won't to jump on EC (Elliptic Curve further) math to be able to understand why EC keys is so short to compare with RSA keys. Since my English is far from perfect, I better drop here IMHO pretty good ...


15

Currently, RSA is still recommended as a gold standard (strong, wide compatible) ed25519 is good (independent of NIST, but not compatible with all old clients). Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones. Frankly, ...


14

When software (browsers, Web servers...) supports elliptic curves at all, you can more or less expect support for the two curves given in NSA suite B, i.e. the P-256 and P-384 curves which are specified in FIPS 186-3. These are the same curves as the "secp256r1" and "secp384r1" which you list. The 15 standard NIST curves (from FIPS 186-3) are actually a ...


13

The NIST has "defined" 15 "standard curves", specified in FIPS 186-4. Actually, they did not define them themselves; they inherited them from SEC. These 15 curves aggregate into 3 groups: The P-* curves work in a "prime field" (point coordinates are integers modulo a prime p). The B-* curves work in a "binary field" (point coordinates are values in GF(2m)). ...


13

The equivalent data for ECDSA, or any ECC including ECDH, is the public point value and a specification of the curve used. In practice for interoperability people use one of the curves identified by a standardized OID (NIST, SECG, etc) and mostly only the two "blessed" by NSA Suite B, namely nistp256 and nistp384, although the ASN.1 formats (and openssl ...


13

Since the algorithms are in a state of flux, I find that using an ssh-audit tool (available on Github) (here's a more recent fork) to be extremely useful. Example output of a current but secured SSH settings is given below: # general (gen) banner: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 (gen) software: OpenSSH 6.7p1 (gen) compatibility: OpenSSH 6.5+, ...


12

There is nothing more secure than "secure". An attacker who can break it upfront, because it has "only" 128-bit security, is an attacker who has way more available computing power than all computers on Earth taken together (even including smartphones and coffee machines). It is implausible that such an attacker would swoop down so low as to bother breaking ...


11

It is a quirk of OpenSSL. The ecparam command is meant for handling EC parameters -- namely, the definition of a curve to play on -- and allows the generation of a private key as a secondary feature. You can use the -noout command-line argument to suppress the production of the encoded EC parameters themselves: $ openssl ecparam -name secp256k1 -genkey -...


11

An elliptic curve is defined over a finite field of size q for some integer q. Each curve element is a point and has two coordinates X and Y, which are curve elements. The "size" of the curve, which is the important parameter for its cryptographic strength, is close to q. It can be shown that the total curve size n is such that |n - (q + 1)| ≤ 2*sqrt(q) (...


11

Right, welcome to a crypto-nerd battle. Let's try and break this down. Key length: ed25519 is from a branch of cryptography called "elliptic curve cryptography (ECC)". RSA is based on fairly simple mathematics (multiplication of integers), while ECC is from a much more complicated branch of maths called "group theory". In short: ECC keys can be much shorter ...


10

CHOOSING AN ALGORITHM AND KEY SIZE SSH supports several public key algorithms for authentication keys. These include: rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in ...


9

Like it was said by @Tom Leek secp256r1 is P-256, secp384r1 is P-384 and secp521r1 is P-521. They are all part of the NSA suite B. A Wikipedia article has a list of all implementation of curves. So the most common clients are: OpenSSL/LibreSSL offers support for 28 curves including P-256, P-384 and P-521 they do not support Curve25519 and (Ed448-)...


9

Currently, ECC is supported in GnuPG 2.1 beta. You can compile it from source and see for yourself that the following curves are supported: nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1


9

I'd say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it's also supported in every modern crypto library. In the same time, we should push forward adoption of non-NIST curves like Curve25519, which will be fully rigid, less prone to implementation errors and may become nice alternative for those who need faster solutions than secp521r1.


8

"ECDHE" means that the key exchange will use the Diffie-Hellman algorithm (over elliptic curves) with freshly generated DH elements; the last "E" stands for ephemeral. So while DH produces a shared key, it will work with randomly produced values, and nothing in DH will ensure authentication: the client has no way to know whether the DH public key it sees ...


8

You do not encrypt with ECDSA; ECDSA is a signature algorithm. It so happens that an ECDSA public key really is an "EC public key" and could conceptually be used with an asymmetric encryption algorithm that uses that kind of key; e.g. ECIES; or it could also be used as one half of a key exchange algorithm like ECDH, resulting in a "shared secret" than can ...


7

By statute and out of tradition, the NSA operates in hidden ways. So the exact reasons of why the NSA did something or did not cannot be rigorously known. However, one can make some guesswork. A first thing to note is that suite B is meant for interoperability: it is a deliberately small list of algorithms and features with the official purpose of being ...


Only top voted, non community-wiki answers of a minimum length are eligible