1
$\begingroup$

Most parts of public key cryptography has established standards which are in turn used in a large amount of real world applications. There is PKCS#1 for RSA based encryption and signatures and there is DSS for ECC based signatures.

But for some reason, I never came across a proper standardised form of a ECC based encryption scheme. Whenever I look at software trying to use, it usually is some homebrewed El-Gamal variant.

Am I missing something? Or is there a reason for that gap?

$\endgroup$
  • 1
    $\begingroup$ You're missing this. $\endgroup$ – DannyNiu Apr 20 at 10:49
  • 1
    $\begingroup$ Also ECIES is standardized, just no as prominently as RSA-based schemes I suppose... $\endgroup$ – SEJPM Apr 20 at 11:04
2
$\begingroup$

There is a scheme called the Elliptic Curve Integrated Encryption Scheme that has been "standardized". It is described in section 5.1 of SEC1v2. It is commonly used with EC to create an encryption scheme.

ECIES is a hybrid scheme that depends on a symmetric cipher (and a KDF and MAC algorithm) to encrypt the actual data. Generally that's fine as EC / ElGamal is very limited in what it can encrypt anyway. It is based on ephemeral-static DH, where the ephemeral private key is only used during encryption. You can see it as a delayed key agreement scheme, followed by data encryption.

There are a few problems that makes it trickier than just plain RSA encryption, disregarding the fact that most people find EC cryptography trickier anyway:

  • some validation of the public key values may be in order if decryption is automated;
  • the algorithms for the KDF, cipher and MAC are not standardized, so they need to be established in advance;
  • the ciphertext consists of multiple parts instead of one: the ephemeral public key and the actual ciphertext + MAC value.

The problem that you have to specify the symmetric cipher yourself is why I put "standardized" between quotation marks: you cannot just say that it is ECIES encrypted and expect the other party to be able to decrypt. The configuration parameters for ECIES - and possibly the parameters of the configured algorithms - need to be described.

The benefit is that the ciphertext is generally somewhat smaller and that the decryption operation is more efficient. It is also much easier to have e.g. 256 bit security for the EC keys: just use 512 or 521 bit ECC key pairs (rather than > 16 Kib RSA keys). Besides that, RSA itself is also used in a hybrid scheme since messages are often larger than the modulus minus the required overhead for the padding (PKCS#1 v1.5 or OAEP padding).

| improve this answer | |
$\endgroup$
  • $\begingroup$ Are you aware how broadly this "standard" is used? $\endgroup$ – mat Apr 22 at 20:16
  • $\begingroup$ No. Not enough I'd say. NaCL uses it, although it doesn't explicitly specify it. Bernstein is weird like that: " The crypto_box_open function verifies and decrypts a ciphertext c using the receiver's secret key sk, the sender's public key pk, and a nonce n. The crypto_box_open function returns the resulting plaintext m." $\endgroup$ – Maarten Bodewes Apr 22 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.