I have implemented Diffie–Hellman and I'm looking for a way to encrypt and decrypt messages with that key.
Diffie–Hellman key exchange is a protocol to enable both sides to agree on a key.
You can use this key for any symmetric encryption algorithm. AES is the current standard.
AES accepts 128,192, and 256 bits size keys. When you agreed on a key, make sure that your protocol cut the keys for appropriate sizes for the symmetric encryption algorithm.
Related
Is a stream cipher algorithm (Encryption) has to be always symmetric? Wikipedia has mentioned it but without a reason. This site also portrays some information about it, but not clearly why only symmetric keys are used to encrypt stream cipher but not asymmetric?
I remember that the teacher explained in class that the encryption and decryption speed of asymmetric ciphers is relatively slow, and stream encryption requires high speed, which may be one of the reasons.
You can check here, Salsa20 has 408MB/s and 4.3 cycles per byte, I do not think any asymmetric ciphers can reach this speed, you have to exchange key everytime you want to send any infomations, the same key cannot be encrypted twice in cryptography.
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?
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:
(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
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 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.
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.
I got a 15KB encrypted file (containing a long base64 string) , and a rsa private key file. I have to decrypt this file using the private key, but I am receiving an error while trying to do so with openssl.
This is the command I tried:
openssl rsautl -decrypt -inkey ./id_rsa -in encrypted_file.enc -out output.bin
The error I'm receiving is as follows:
RSA operation error 140360486789312:error:0406506C:rsa
routines:rsa_ossl_private_decrypt:data greater than mod
len:../crypto/rsa/rsa_ossl.c:391:
I would appreciate to get help how to do it right.
Thanks in advance.
RSA is not designed to encrypt (large) data, use symmetric encryption such as AES to encrypt data.
If you really need asymmetric encryption, that is separate encryption and decryption keys, use hybrid encryption. Hybrid encryption creates a Ranson symmetric key, encrypts the data with symmetric encryption, encrypts that symmetric key with asymmetric encryption and packaged the two together.
The size of the data that can be encrypted is less than the key size minus padding. To RSA encrypt a 15KB file would require an RSA key > 17,000 bits and that is currently unreasonable. Also asymmetric encryption (RSA) is orders of magnitude slower than symmetric encryption (AES).
But one question: do you really need asymmetric encryption, would symmetric encryption suffice for your needs?
Given a AES secret key, is it possible to fake a data that can be decrypt using that key? the decrypted data doesn't need to be meaningful, just want to know if can fake a encrypted data.
AES is a symmetrical cipher, i.e. the same key is used to both encrypt and decrypt data. As such, the key must be known to both ends of communication, and no one else. Authentication and key-exchange is done via public-key protocols, such as Diffie-Hellman key exchange.
Given these, if you are the third person to possess an AES key, I assume that you cannot send "fake data" to the recipient, as authentication will fail (no negotiation has taken place). If you have established such a connection, you can send whatever you want (you can encrypt gibberish and send it). If you mean to alter an encrypted packet, you can do it without decrypting it and re-encrypting it, but it's most likely to fail integrity tests (e.g. if hashes or CRC are present).
Why not use the key exchange ( like Diffie–Hellman) algorithm for the actual encryption?
(instead of using them only for key exchange)
The key exchange algorithms are rather resource intensive, and the asymmetric properties aren't needed after the initial handshake, so they only get used to exchange a key, which then gets used to encrypt the main data using some symmetric encryption scheme.