ECC-Based Encryption / Decryption

In this section we shall explain how to implement elliptic-curve based public-key encryption / decryption (asymmetric encryption scheme based on ECC). This is non-trivial and usually involves a design of hybrid encryption scheme, involving ECC cryptography, ECDH key exchange and symmetric encryption algorithm.

Assume we have a ECC private-public key pair. We want to encrypt and decrypt data using these keys. By definition, asymmetric encryption works as follows: if we encrypt data by a private key, we will be able to decrypt the ciphertext later by the corresponding public key:

The above process can be directly applied for the RSA cryptosystem, but not for the ECC. The elliptic curve cryptography (ECC) does not directly provide encryption method. Instead, we can design a hybrid encryption scheme by using the ECDH (Elliptic Curve Diffie–Hellman) key exchange scheme to derive a shared secret key for symmetric data encryption and decryption.

This is how most hybrid encryption schemes works (the encryption process):

This is how most hybrid encryption schemes works (the decryption process):

Let's get into details how to design and implement an ECC-based hybrid encryption scheme.

ECC-Based Secret Key Derivation (using ECDH)

Assume we have a cryptographic elliptic curve over finite field, along with its generator point G. We can use the following two functions to calculate a shared a secret key for encryption and decryption (derived from the ECDH scheme):

This is what exactly the above two functions calculate, directly following the ECDH key agreement scheme. In the hybrid encryption schemes the encapsulated ciphertextPubKey is also known as "ephemeral key", because it is used temporary, to derive the symmetric encryption key, using the ECDH key agreement scheme.

ECC-Based Secret Key Derivation - Example in Python

The below Python code uses the tinyec library to generate a ECC private-public key pair for the message recipient (based on the brainpoolP256r1 curve) and then derive a secret shared key (for encryption) and ephemeral ciphertext public key (for ECDH) from the recipient's public key and later derive the same secret shared key (for decryption) from the recipient's private key and the generated earlier ephemeral ciphertext public key:

The code is pretty simple and demonstrates that we can generate a pair { secret key + ciphertext public key } from given EC public key and later we can recover the same secret key from the pair { ciphertext public key + private key }. The above code produces output like this:

It is clear from the above output that the encryption key (derived from the public key) and the decryption key (derived from the corresponding private key) are the same. This is due to the above discussed property of the ECC: pubKey * ciphertextPrivKey = ciphertextPubKey * privKey. These keys will be used for data encryption and decryption in an integrated encryption scheme. The above output will be different if you run the code (due to the randomness used to generate ciphertextPrivKey, but the encryption and decryption keys will always be the same (the ECDH shared secret).

The above demonstrated mechanism for generating a shared ephemeral secret key, based on a ECC key pair, is an example of KEM (key encapsulation mechanism), based on the ECC and ECDH.

ECC-Based Hybrid Encryption / Decryption - Example in Python

Once we have the secret key, we can use it for symmetric data encryption, using a symmetric encryption scheme like AES-GCM or ChaCha20-Poly1305. Let's implement a fully-functional asymmetric ECC encryption and decryption hybrid scheme. It will be based on the brainpoolP256r1 curve and the AES-256-GCM authenticated symmetric cipher.

We shall use the tinyec and pycryptodome Python libraries respectively for ECC calculations and for the AES cipher:

The above example starts from generating an ECC public + private key pair for the message recipient: pubKey + privKey, using the tinyec library. These keys will be used to encrypt the message msg through the hybrid encryption scheme (asymmetric ECC + symmetric AES) and to decrypt is later back to its original form.

Next, we encryptmsg by using the pubKey and we obtain as a result the following set of output: { ciphertext, nonce, authTag, ciphertextPubKey }. The ciphertext is obtained by the symmetric AES-GCM encryption, along with the nonce (random AES initialization vector) and authTag (the MAC code of the encrypted text, obtained by the GCM block mode). Additionally, we obtain a randomly generated ephemeral public key ciphertextPubKey, which will be encapsulated in the encrypted message and will be used to recover the AES symmetric key during the decryption (using the ECDH key agreement scheme, as it was show before).

To decrypt the encrypted message, we use the data produced during the encryption { ciphertext, nonce, authTag, ciphertextPubKey }, along with the decryption privateKey. The result is the decrypted plaintext message. We use authenticated encryption (GCM block mode), so if the decryption key or some other parameter is incorrect, the decryption will fail with an exception.

Internally, the encrypt_ECC(msg, pubKey) function first generates an ephemeral ECC key-pair for the ciphertext and calculates the symmetric encryption shared ECC key sharedECCKey = ciphertextPrivKey * pubKey. This key is an EC point, so it is then transformed to 256-bit AES secret key (integer) though hashing the point's x and y coordinates. Finally, the AES-256-GCM cipher (from pycryptodome) encrypts the message by the 256-bit shared secret key secretKey and produces as outputciphertext + nonce + authTag.

The decrypt_ECC(encryptedMsg{ciphertext, nonce, authTag, ciphertextPubKey}, privKey) function internally first calculates the symmetric encryption shared ECC key sharedECCKey = privKey * ciphertextPubKey. It is an EC point, so it should be first transformed to 256-bit AES secret key though hashing the point's x and y coordinates. Then the AES-256-GCM cipher is used to decrypt the ciphertext + nonce + authTag by the 256-bit shared secret key secretKey. The produced output is the original plaintext message (or an exception in case of incorrect decryption key or unmatching authTag).

The output from the above code looks like this:

original msg: b'Text to be encrypted by ECC public key and decrypted by its corresponding ECC private key'
encrypted msg: {'ciphertext': b'b5953b3082fcefdbde91dd3c03cf83dde0822c19be6ae906a634db65115295e7cbcd7a1a492d69ba5be91990c70d8df9dc84360cf554f155ef81ce1f0ad44bd9fdabbc5f960517089262b3390e61b37610012bee4e6bcae335', 'nonce': b'9d55f4b5c87fff773d0457f3b23a953e', 'authTag': b'5c9d339778925aa4e44f43252a28681d', 'ciphertextPubKey': '0x21dbc985b625f2a42d0f86fc234b49b55477928bae73dfac73bafd9bed50abe70'}
decrypted msg: b'Text to be encrypted by ECC public key and decrypted by its corresponding ECC private key'

Enjoy the above example, play with it, try to understand how exactly it works, try to change the underlying ECC curve, try to change the symmetric encryption algorithm, try to decrypt the ciphertext with wrong private key.