# How does the encryption/decryption process work? [duplicate]

I am not referring here to the process of Public Key exchange, but rather the process of encryption or decryption itself after the Public/Private keys have been generated. For instance, using Diffie-Hellman algorithm we ended up getting both Public and Private Keys of size 512 Bytes. How are we supposed then to use the Public Key to encrypt a given plain text message "Hello World!" and the Private Key to decrypt it?

• You would have to encode the message "Hello World!" into the plaintext space of Diffie-Helman and then encrypt it. But, in fact, things are not even done like that, because messages use to be longs and public key encryption uses to be slow, so, you would rather encrypt the message with some block cipher and use the asymmetric scheme to encrypt the key of this block cipher... Aug 16 '16 at 1:57
• I just realized that you are talking about Diffie-Hellman, not about ElGamal, so now I think I'm not getting the point of your question. Do you want to know how to use the exchanged key to encrypt? Because you are not supposed to use the Diffie-Hellman's public key to encrypt messages. Aug 16 '16 at 12:54
• @Vitor : Yeah exactly. I will truly appreciate that :) Aug 16 '16 at 14:57
• The question is too broad, I would rewrite it in such a way that it is specific to any protocol that involves diffie hellman for key agreement. Aug 18 '16 at 12:29

Diffie-Hellman does not generate public and private keys. It generates an agreed number in such a way that:

1. An eavesdropper cannot work out what number has been agreed upon.

2. A man in the middle can either know the agreed number which party $A$ is using and the agreed number which party $B$ is using, or ensure that the agreed number which party $A$ is using is the same as the agreed number which party $B$ is using, but not both.

No encryption is involved in Diffie-Hellman and Diffie-Hellman does not generate encryption keys.

Of course one of the main uses of an agreed number would be to do encryption with it – or rather, with a key derived from it. But that is nothing to do with Diffie-Hellman per se.

To that extent, your question is "How, given a number, do I turn it into an encryption key and use it?" – to which the answer is, "In any way you like".

Diffie-Hellman is a key agreement protocol. It is used to establish a secret value (master secret) which is identical at the parties involved in the key agreement.

This value is then put through a Key Derivation Function (KDF) to derive one or more symmetric keys, such as AES keys, that are also identical for the parties involved. These keys can then be used to encrypt messages and to protect the integrity and authenticity of the messages between the parties. Sometimes the value is truncated or put through a one way function such as a hash function instead of using a well defined KDF.

The actual symmetric cipher, mode of operation and method of generating the authentication tag are not part of the key agreement protocol; basically they can be anything at all.

It is impossible for other parties to retrieve the secret value that has been agreed upon.

Then again, it is important to note that Diffie-Hellman does not authenticate the parties themselves. This should be performed as part of the protocol using different primitives such as signature generation functions. It's important that the public values used for the key agreement are also verified at some point in the protocol.

Diffie-Hellman key exchange uses one party's private key and the other party's public key to generate a shared secret value, this is done through either exponentiation or multiplication modulo a prime, depending on the algorithm and type of key. There are other methods of creating a shared secret, such as the infamous algebraic eraser.

The shared secret could be used directly as a symmetric key, however this is neither recommended nor done in practice, because there is not an even distribution of entropy in the shared secret, and sometimes bits can be strongly biased.

The shared secret is hashed before being used as a key, or be processed with a specific key derivation function like HKDF, or the PRF used in TLS.

• Thanks for your answer. I would like to stress again that I would love to have a deep explanation of how the actual encryption process occurs rather than the key agreement protocol whether it's a public/private keys system or a hybrid system with shared session keys Aug 16 '16 at 5:30
• @user-x220 Session keys have nothing to do with this. You also wrote, Diffie Hellman is used to create a pair of private/public key, which is just not the case - DH is a key exchange protocol and not a public key encryption scheme. In this field, correct context, naming and notation are really important.
– tylo
Aug 16 '16 at 10:09
• @tylo : I might did a mistake without paying attention. The key-exchange protocol itself doesn't matter. What do matter is the encryption process, like how a plain text "Hello World!" message like that get encrypted into something like "+%\$lk23-**-/?09" using for instance the public key? Aug 16 '16 at 15:03
• @user-x220 I think you're confusing some concepts. There is no public key in this context. The key exchange algorithm ensures both parties have a secret. This secret is deterministically converted into a key. Now both parties have the same key. This key is used to encrypt and also decrypt, using a symmetric encryption algorithm. This symmetric encryption algorithm can be any algorithm you choose. A common choice is AES. AES takes a block of 16 bytes, a key of 16,24,or 32 bytes, and produces 16 bytes of ciphertext. These blocks are typically chained together in some manner. Aug 16 '16 at 21:55