Regarding the use of secp256r1 and x25519?

Question

I'm implementing some protocol using some 3rd party repository (Private Join and Compute), and the repo only supports built-in curves in FIPS modules (P-224, 256, 348 and 512) in openssl when creating EC group:

StatusOr<ECGroup::ECGroupPtr> CreateGroup(int curve_id) {
  auto ec_group_ptr = EC_GROUP_new_by_curve_name(curve_id);
  // If this fails, this is usually due to an invalid curve id.
  if (ec_group_ptr == nullptr) {
    return InvalidArgumentError(
        absl::StrCat("ECGroup::CreateGroup() - Could not create group. ",
                     OpenSSLErrorString()));
  }
  return ECGroup::ECGroupPtr(ec_group_ptr);
}

(EC_GROUP_new_by_curve_name is in openssl/crypto/fipsmodule)

My questions:

• Can I modify the code to replace built-in curves by X25519 for my protocol? My protocol uses it for ECDH.
• If not, what's the concern except that X25519 is not FIPS verified?
• Or, simply speaking, in what use case I should use secp256r1/k1 and what for X25519?

Seascape

Note SECG secp256k1 is a different curve from secp256r1 (aka X9 prime256v1 and NIST P-256) and was not in FIPS186-4 or FIPS140-2, or -3 to date; it is added to FIPS186-5/SP800-186 (finalized last month) as an option "for blockchain-related applications" and will presumably appear in SP800-140C for FIPS140-3 in due course. – Mcclimans

Ah, finally you've got a popular question that gets answered and then it is closed as off topic. Would you mind if I migrate it to stackoverflow? – Johannessen

@MaartenBodewes No problem! I don't know how to transfer the question to stackoverflow so thanks for doing this :) – Seascape

Answer 1

Can I modify the code to replace built-in curves by X25519 for my protocol? My protocol uses it for ECDH.

Well, of course you can. However, it is not just a question of changing the parameters. The calculation and encodings of X25519 are also different.

If not, what's the concern except that X25519 is not FIPS verified?

FIPS verified is specific to implementations, so to say that an algorithm is not "FIPS certified" makes no sense. Of course, FIPS implementations are only verified if they make use of NIST standardized algorithms, and X25519 is not one of those. NIST has been looking to quantum-safe algorithms instead. There were some hints that X25519 could be included in NIST SP800-56A, but that hasn't materialized.

Or, simply speaking, in what use case I should use secp256r1/k1 and what for X25519?

Both have a security margin of about 128 bits, but it is easier to create a secure implementation of X25519, e.g. with regards to public key validation and side channel attacks. X25519 is also relatively performant. X25519 seems to run 50% faster on my system, although - to be honest - the openssl speed ecdh command was all over the place.

Johannessen

In particular OpenSSL implements the Bernstein et al versions as different algorithms EVP_PKEY_{X,ED}{25519,448} not different EC_GROUPs within (X9/Weierstrass) EVP_PKEY_EC. – Mcclimans

Same for Java, just helped with an implementation of that. – Johannessen