I've been experimenting with RSA encryption in python (cryptography.hazmat.primitives.asymmetric). I have the following setup: On one end is the client with the public key sending encrypted data back to the server, which holds the private key. Right now I've got one-directional encryption working, but I'm wondering how you would (or if you should) securely decrypt a message client-side. I thought about just encrypting the private key and storing it, but then the password would appear in the code and expose the key to compromise. Is there a way to securely implement this with a key exchange? Or--the most likely alternative--is this a misuse of the protocol?
EDIT: Wanted to clarify that the possible concerns here would be that using RSA in this way might expose the private key on the file system or between the server and the client.
The normal way is for the server to encrypt the reply with the client's public key and client decrypt with its private key. This requires TWO RSA keypairs -- one for the client and one for the server, and requires each end to know the other's public key.
This need (along with high cost of PKE compared to symmetric encryption) is why PKE is normally only used for authentication and/or key exchange, and a symmetric cipher is used to actually encrypt traffic.
Related
Let's say we have a client that uses asymmetric cryptography to communicate with a server. This could be SSL or just a custom encryption.
Now if we assume that the client's source code is easy to disassemble, can we extract the public key and hence send bogus messages to the server?
Anyway to avoid this? Consider that it is really hard to keep the client's source code safe.
in the following case, if privateKeyOfA is leaked, what's the security problem? Can someone decrypt the message without privateKeyOfB??
Aes.encrypt(privateKeyOfA, publicKeyOfB, message)
Aes.decrypt(publicKeyOfA, privateKeyOfB)
If not, I guess why we need privateKeyOfA here is for A's signature?
The signature is needed since the receiver must know that the message is coming from someone that he can identify. If he cannot verify the signature, this means that he doesn't know the person.
If the private key of A is compromised by a hacker, he can send messages to everybody with signature impersonating the A.
A key exchange (e.g. using DH or ECDH) would be used by A to convert privateKeyOfA + publicKeyOfB into an AES key. This same AES key can also be generated identically by B using privateKeyOfB + publicKeyOfA. All traffic between A and B would be encrypted using the same AES key.
Assuming that all public keys are known (they are public after all), then anyone who has access to privateKeyOfA can regenerate all AES keys that were generated by A to communicate with anyone. This means all traffic involving this key (messages sent or received by A, with B or anyone else) would be compromised.
But if an ephemeral version was used (like in some modes of TLS), then a new key is generated for each session, so that if 1 key is ever compromised, only this session is compromised. You can read more about forward secrecy.
If the keys are used in the way you describe, then they are not used for signature.
Wouldn't anyone else be able to decrypt it too using the public key? Or is it saying that it will be decrypted with a private key. If that's the case how could something be encrypted with one key and decrypted with another?
This is in reference to this wikipedia article.
Specifically - "In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key."
Sorry if this was a silly question.
Because it's public-private key encryption, not symmetric encryption. The plaintext is encrypted to cipher text with the public key and decrypted back to the plaintext with the private key. Trying to decrypt that ciphertext with the public key doesn't work.
I know with RSA there are a few ways you can encrypt and decrypt data, meaning you can encrypt with either the public or private key (or both), and you can also decrypt with just a private or public key, or both.
With Triple Des, do you need both key and iv to decrypt? Or can you do it somehow with just a key? (public key?)
Being a symmetric algorithm, DES (and 3DES) uses a shared secret key. It doesn't have public keys.
And IV must be known to decryptor if this IV was used during encryption.
RSA is a public-key (or asymmetric) encryption algorithm – which means that there are key pairs of public and private keys, where you encrypt with one of them and decrypt with the other.
DES and Triple-DES are block ciphers. You use them together with a mode of operation to encrypt or decrypt a message – you use the same key for encryption as for decryption. This is known as a symmetric algorithm.
Some modes of operation (all good ones) need an initialization vector, so identical plaintexts don't lead to identical ciphertexts (and sometimes other weaknesses as well). Normally this initialization vector should be send/stored together with the ciphertext, it doesn't have to be secret. Depending on the mode of operation and the usage scenario, the IV should be used only once, be random, or non-predictable.
Also, nowadays you should not use DES (it has a too small key size to be secure). Triple-DES is okay, but much slower (and not more secure) than modern algorithms like AES.
3DES is no different than any other block cipher. If you are using a cipher mode which requires an IV, and you are not including the IV in the message header, you will need it to decrypt the message.
I'm wondering why ssl encrypted data can't be cracked easily once the packets are intercepted. As i understand it when you connect to a site like facebook the browser and site agree on a cipher, what stops the sniffer from seeing what cipher they agreed to?
SSL uses asymmetric encryption, meaning the decryption key is different than the encryption key. So if you as a client encrypt your packets with the server's public key, it can only be decrypted by the private key, which remains on the server. Of course, this is a simplification of everything that happens in an SSL transaction, but that's the basis of the concept.
Imagine sending a box with an open padlock to the other side - when the other side wants to send a message, they put it inside the box, lock the padlock and send it back to you, where you use your (private) key to unlock it. Even if the intercepting party has sees the padlock, they still don't have the key.
There's a lot of ways to describe it. For me, my ah-hah moment was when I figured out that, after information is encrypted multiple times, it can be decrypted in any order.
A encrypts first, passes to B a single encrypted message [A encryption].
B encrypts the message a second time, and passes to A a double encrypted message [A encryption and B encryption]
A removes [A encryption] from the message, leaving only [B encryption], and sends the message to B.
B now has a [B encrypted] message, and knows how to decrypt it.
The sniffer sees the message encrypted three different ways: [A], [AB], and [B].
That's three message passes to exchange one message, but once it's passed and both sides have the unique information to decrypt further communication, future messages only need one trip.
If you want a simple example of how a message could be decrypted in any order, you can use XOR as a sample encryption method. For keys A and B, message M, and XOR is ^, then
M ^ A ^ A = M
M ^ A ^ B ^ A ^ B = M
Facebook signs it's package with a certificate that Facebook got from an certificate authority such as RapidSLL.
As long as you trust the certificate authorities that all certificate they issue for facebook.com do really belong to facebook.com the connection is safe.
Facebook then sends you via a signed message it's public encyrption key which you can use to encrypt your messages to be read by facebook.
Yes, the cipher is public. However, the client asymmetrically encrypts a random session key (or rather a precursor) using Facebook's public key (they verify it's really Facebook's key by checking that it is signed by someone trusted). So only Facebook (who has a private key) should be able to derive the actual symmetric keys that are used to exchange website data.
See this detailed walk-through. In that example, an eavesdropper can tell that the connection uses RSA, RC4, and MD5. But they don't have Amazon's private key, so they can't derive the session keys.
Like Derek H said, there are fundamental differences between symmetric and asymmetric encryption. Look up stuff like DH key exchange protocol and RSA cipher, they are fundamental in SSL/TLS. On the other hand, it's relatively easy to decrypt sniffed data (ROBOT attack).
If you just need to be sure your communication is secure, you can simply use SSL/TLS Server Test, there you can see if you're not using recommended algorithms or see if your SSL/TLS configuration is PCI-DSS/HIPAA/NIST compliant.