Hot answers tagged

87

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 ...


81

ECDHE suites use elliptic curve diffie-hellman key exchange, where DHE suites use normal diffie-hellman. This exchange is signed with RSA, in the same way in both cases. The main advantage of ECDHE is that it is significantly faster than DHE. This blog article talks a bit about the performance of ECDHE vs. DHE in the context of SSL.


64

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. ...


55

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,...


54

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 ...


26

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 ...


17

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


16

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. ...


15

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 ...


14

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, ...


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

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 ...


11

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, ...


10

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) (...


10

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 ...


10

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 ...


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

Since the algorithms are in a state of flux, I find that using an ssh-audit tool (available on Github) 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+, Dropbear SSH 2013.62+ (gen) ...


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

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 ...


8

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

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 ...


8

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 ...


7

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-)...


7

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 -...


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 ...


7

An elliptic curve is a point in a bi-dimensional space, hence it has two coordinates (usually called X and Y) which are values in some field. In the case of P-192, the field consists in integers modulo a prime p of length 192 bits (p lies between 2191 and 2192). The curve points are the (X,Y) pairs that fulfil the curve equation (Y2 = X3 + aX + b for two ...


7

As per X.509, no problem. You can mix algorithms at will. Each signature is independent. (X.509 includes a special provision for when a CA uses DSS and issues a certificate that also uses DSS with the same group parameters, in which case the issued certificate may omit the group parameters. This is called "parameter inheritance". This is never used in ...


6

in GPG, for security, one would stay away from brainpool, and nist curves. edDSA, montgomery and edwards curves are fine. ed25519 is luckily being deployed without subrterfuge for now. Although it is just for signing/certifying/authentication. Encryption will follow. the mailing lists on ietf.org are brilliant places to start, and checking cryp.to as well....


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