ECC Encryption / Decryption
Last updated
Last updated
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.
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) --> sharedECCKey
Calculate 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, b = ciphertextPrivKey, 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.
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.
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.