2

I've implemented RSA encryption algorithm to encrypt the symmetric key used in data encryption, but the key size and the ciphertext size of RSA created a memory issue, so I searched other methods of public key cryptography for the solution. I found elliptic curve integrated encryption scheme (ECIES) and understand the theory behind it, however, I am a bit unclear that how this method be used as public/asymmetric encryption algorithm. The method computes the symmetric encryption with the key derived from the shared secret for both encryption and decryption (using the same key).

So how could it be taken as an asymmetric encryption algorithm? Or Is there any method to implement it as asymmetric encryption?

srla
  • 51
  • 5

2 Answers2

2

Meta: this isn't really a programming or development question or problem. It probably belongs on crypto.SX; you might ask for migration.

To be exact, ECIES is a hybrid public-key encryption scheme, but so are most others. For example RSA is commonly used, just as you said, to encrypt a working (per-message) symmetric key, not to directly encrypt data.

Paraphrasing the wikipedia description:

  1. (Usually in advance) Bob generates a (static) keypair and publishes the publickey authentically (for example using a certificate)

2-5. Alice generates an ephemeral keypair, derives the shared DEK, and encrypts the data, and sends it with her ephemeral publickey (edit) and destroys the ephemeral privatekey

  1. Bob uses his privatekey to derive the DEK and decrypts the data

ADDED, and expanded below, per comments: Yes the DEK is the same at both ends (notice I used 'the' meaning one and not several) and that's why this scheme works; and the part of ECIES that uses DEK for data encryption and decryption is symmetric, but all the other operations (which securely create the ephemeral shared DEK) are not.

It is vital no one besides Alice (or Bob) learns her ephemeral privatekey; if they do they can decrypt. But she doesn't need to explicitly keep it secret because she destroys it immediately after using it to send a message; that's what ephemeral means.

Let's see:

  • the recipient's publickey is public and anyone can encrypt

  • the recipient has the (static) privatekey and can decrypt

  • nobody else has Bob's (static) privatekey or Alice's ephemeral privatekey, and nobody else can decrypt

  • the recipient needs only one keypair; if there are multiple senders they can all use the same publickey but can't decrypt each other's traffic, and don't need to get the publickey secretly; for a thousand or a million senders this costs the same as or very little more than one sender

Consider the properties of a standard/traditional symmetric scheme instead:

  • the two parties must have a key (only one, not a pair) shared in advance; both must keep it secret and not share with anybody else

  • this typically requires the parties meet in advance, or use a physically secure means such as a courier to carry the key from one to the other or perhaps from a central authority to both

  • each key can only be used by one pair of parties; for multiple senders, Bob must have and manage that many different keys, and each sender (Alice, Abby, Anne, etc) must have a different key. Each sender must separately meet Bob, or they must each have a separate courier (or two), before they communicate with him. For a thousand or a million senders this becomes immensely costly

ECIES has none of these properties of a conventional or symmetric system, and all of the properties of a publickey or asymmetric system above, although it does also use some symmetric operations along with its asymmetric operations.

And that's why it sounds like (hybrid) public-key encryption to me!

dave_thompson_085
  • 24,048
  • 4
  • 34
  • 52
  • `Bob generates a keypair and publishes the publickey` 1.Bob's public key, KB:KB=kbG, where kb is private key he chooses at random: kb∈[1,n-1] `2-5. Alice generates ephemeral keypair, derives shared DEK, and encrypts data, and sends it with ephemeral publickey` 1. Generates a random number r∈[1,n-1] 2. Calculates R=rG Ephemeral keypair: r and R 3. Derives shared DEK:Se=rKB 4. Encrypt message: c=E(S;m) 5. Send c||R `6-7 Bob uses the privatekey to derive DEK and decrypts data` 6. Derive shared DEK:Sd=kbR 7. Decrypt the message:m=D(S;c) `Is the above assumption correct as per you?` – srla Jun 21 '18 at 07:14
  • In the above procedure, DEK for encryption and decryption are equal: `DEK in encryption Se=rKB` `DEK in decryption Sd =kbR=kbrG=rkbG=rKB = Se` In addition, we compute the encryption/decryption using symmetric encryption algorithm, then how is it public-key encryption? I think my visualization is somewhere wrong, could you please explain it? It would be very helpful for me. Do we need to keep r (Ephemeral Key) secret? – srla Jun 21 '18 at 07:23
  • I call that a description not an assumption, but yes that description is the same as mine and wikipedia's. The privatekey must not be exposed; added. I don't know why you can't see this, but I've expanded my answer, maybe that will help. – dave_thompson_085 Jun 22 '18 at 05:11
0

@dave_thompson_085 has explained the concept well. However, I'd like to add an example to make it clear.

Eg:

  • Alice generates Public "qA" and private key "dA".
  • Alice sends over her public key to Bob.
  • Using this public key, Bob generates a random pair of symmetric keys (R and S).
  • Bob encrypts the message with key "S" and sends over this ciphertext along with key "R" over to Alice.
  • With this "R" key, Alice can multiply her private key "dA" and generate the symmetric key "S" to decrypt the ciphertext.

enter image description here

So the message is encrypted using a symmetric key, but over the network it is asymmetric as only the public key is exchanged over the network which is used to generate the symmetric key for the receiver and the private key is used to generate the same symmetric key on the sender's side.

Shayan
  • 867
  • 5
  • 13