# ECC 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 public key**, we will be able to **decrypt** the ciphertext later by the corresponding **private 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):

**calculateEncryptionKey**(pubKey) --> (sharedECCKey, ciphertextPubKey)Generate

**ciphertextPrivKey**=*new***random***private key*.Calculate

**ciphertextPubKey**= ciphertextPrivKey * G.Calculate the ECDH shared secret:

**sharedECCKey**= pubKey * ciphertextPrivKey.Return both the

**sharedECCKey**+**ciphertextPubKey**. Use the**sharedECCKey**for symmetric encryption. Use the randomly generated**ciphertextPubKey**to calculate the decryption key later.

**calculateDecryptionKey**(privKey, ciphertextPubKey) --> sharedECCKeyCalculate the the ECDH shared secret:

**sharedECCKey**= ciphertextPubKey * privKey.Return the

**sharedECCKey**and use it for the decryption.

The above calculations use the same math, like the **ECDH** algorithm (see the previous section). Recall that EC points have the following property:

(

***a****G**) *= (**b*****b****G**) ***a**

Now, assume that * a* = privKey,

***

**a****G**= pubKey,

*= ciphertextPrivKey,*

**b*****

**b****G**= ciphertextPubKey.

The above equation takes the following form:

pubKey * ciphertextPrivKey = ciphertextPubKey * privKey =

**sharedECCKey**

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**:

Run the above code example: https://repl.it/@nakov/ECC-based-secret-key-derivation-in-Python.

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:

Let's examine this full **ECC + AES hybrid encryption** example:

Run the above code example: https://repl.it/@nakov/ECC-based-hybrid-encryption-decryption-in-Python.

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 **encrypt** `msg`

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 **output** `ciphertext`

+ `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:

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.

Last updated