I'm currently developing a system to transmit data between client and server, and was wondering what the strength of the encryption I planned to use was.
My thought was to have a private/public RSA key pair and hand out the public key to each client (leaving the private key solely on the server). Each client would then generate their own AES key and RSA encrypt it. They would then AES encrypt their data and send the encrypted data and encrypted AES key to the server. The server would then decrypt the AES key using the private key, and then decrypt the data using the AES key.
now question is how to send aes key?
Related
I'm writing a module that creates a secure communication channel using ZeroMQ sockets and Pycryptodome.
The initial handshake between client and server would follow these steps :
Both parties send their public RSA key to each other.
The server generates an AES session key and a signature for that key.
The server RSA-encrypts the session key and the signature before sending it to the client. (*)
The client verifies the signature and stores the session key.
The client generates a token, generates its signature and sends both AES-encrypted to the server.
The server verifies the signature and echoes back the token.
If the token received matches the one sent, the handshake is considered successful.
I found on this thread that it was preferable to sign the message then encrypt it, rather than encrypting then signing it.
The problem is that the signature, for a 2048 bits RSA key, is 256 bytes long. The maximum encryption size for the same key is 190 bytes. This means I can't encrypt the signature as suggested in the thread.
Should I encrypt the signature with the AES session key ? Should I proceed another way ?
I know there are "standardized" key exchange protocols (ECDH for example) but they are not available in Pycryptodome yet.
Cipher: RSA PKCS1 OAEP
Signing : PKCS1 PSS w/ BLAKE2b hash
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.
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).
Is it safe to send a mobile client an AES Key and IV from the server to use for encrypting sensitive data? The key and IV would be sent using TLS. This key would be used for encrypting data from end to end.
Update:
My requirements have actually changed, so I don't need to do this, but the solution I came up with was actually to have the client send a public key to the server over tls. Then the server could encrypt the keys with that public key and send them back to the client.
It would be as secure as any data in TLS. It also depends on how much your client trusts this TLS, which may not have two sided authentication.
But basically sending the key this way doesn't add much to using TLS. If TLS is insecure then the AES key is insecure. If it isn't then the AES key is secure...but TLS was already secure. There might be a slight advantage if you'd use a ciphersuite that provides forward security (DHE_ or ECDHE_).
But mostly, if you send anything, you'd send a public key such as a PGP key. The person on the other hand still has to trust the sender of course (i.e. by validating the fingerprint) but if the TLS connection is insecure then leaking the public key would at least not break anything encrypted using it.
I would like to implement something-like-pay-TV encryption. In this system, the user has a smart card providing private key can decrypt the signal. However, I cannot find out its encryption-decryption step. Therefore, I invent some -_-!
In my system, there is a central server, a broadcast center and users. The central server generate a pair of RSA public-private key and send the public key to broadcast center. When a user want to connect to broadcast center, a request will be sent to central server. Then, the server will send the private key for user. User and broadcast center use this pair of key to encrypt-decrypt a data symmetric key (for example AES key).
Is it a good implementation if the RSA private key is used by multiple users?
RSA won't fit your needs. In RSA you would have to encrypt the data for every single user. RSA is an encryption standard with private/public keys. Each private key depends on his public key.
You can't modify RSA so that you need only one encryption. In PGP (uses RSA) for example when sending a PGP mail to five recipients, the mail is encrypted five times with different keys.
On pay TV they use conditional access http://en.wikipedia.org/wiki/Conditional_access.
By the way: do not implement your own encryption implementation. Use existing algorithms and implementations. They are proven secure.