Let's assume an attacker obtains the following data:
An encrypted message
A decrypted message and he is 100% sure that this decrypted message content is the same as the encrypted message.
Is this attacker able to reproduce key and/or compromise other messages encrypted with the same key?
Related
Suppose I have a fixed message pool of 1000 messages, person A is sending message from this fixed message pool to person B using RSA.
If an interceptor also have the message pool he can precompute all the encrypted messages using B's public key. Now if he intercept A's message can he surely tell which message A has sent to B?
In this case should we use RSA only for a symmetric key exchange and then messages should be encrypted using a symmetric algorithm?
The text-book RSA encryption algorithm is deterministic. But the official RSA specifications (and also all implementations used in practice) include some (partly random) padding, so we don't actually encrypt plaintext, but pad(plaintext). So the above mentioned problem will not occur.
More details can be found in this answer https://stackoverflow.com/a/7933071/10690480
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.
In PKI if everyone knows the public key of the server does it mean anyone can decrypt the server response to the client which is encrypted by the private key which in turn can be decrypted by the servers public key as long as someone can sniff somebody else traffic by being in the middle ?
In it's simplest form, public key crypto is used for one-way communication.
If Alice has a public/private key pair, and she gives the public key out to everybody, then anyone can encrypt a message using Alice's public key that only Alice can decrypt using her private key. Alice does not use her private key to encrypt messages for others to read.
For two way secure communication, public key crypto is typically used to transmit a session key that two parties can use to communicate securely.
Let's say Bob wants to talk to Alice. With Alice's public key in hand, Bob uses it to encrypt a secret key and send it to Alice. Alice then uses her private key to decrypt the secret key. Now the secret key is known only to Alice and Bob. So they can both use the secret key with a symmetric encryption algorithm such as AES to send messages back and forth between the two of them.
One thing Alice can do with her private key is create a digital signature. Alice can compose a message, hash the message, then encode the hash with her private key. Then Alice sends the message along with the encrypted hash out publicly. Anyone who has Alice's public key can decode the hash and ensure that the hash of the message matches the encoded hash. Because only Alice could have created the encoded hash, the reader knows that Alice did in fact send that message.
No, only the private key can decrypt the data.
In the client server communication, the data is usually encrypted with a random symmetric key initiated during the start of the communication (handshake process). And all further communication is done with it. The role of the PKI is the client generates the random symmetric key, encrypts with the server public key and the server decrypts it in order to continue the session.
I have a Software that Encrypts message using AES , the random generated AES key is Encrypted by the receiver's public RSA key. now when I send the message to multiple users...
Sender Side :
Message is Encrypted by Random hashed (sha256) AES KEY
The AES key is then Encrypted many time and appended to the encrypted message using each receiver's public key.
the message has [ number for receivers, [list of encrypted keys], Encrypted message]
Receiver Side:
get the number of receivers
loop thru the appended encrypted keys and decrypt using your Private RSA. until you find the one intended for you. such that when he/she decrypt the key they get the AES Key.
3.decrypt the message using AES key.
Knowing that the key is of base 64 string which means it ends with '=', and of the length 256 because of the sha
the Question IS :
How Do i know (if I'm the receiver) that the Decrypted key using my Private RSA is correct Automatically ?
thank you in advance.
Two questions: Is the protocol you describe fixed, or might it be modified in any way? If it is fixed, which padding scheme do you use for RSA? PKCS#1 v1.5, OAEP or none at all?
If the protocol might be modified, you could use a cipher mode with authentication, such as EAX, CCM or GCM. If RSA key transport decryption fails silently, so will the authenticated AES decryption.
Use a variation of RSA-OAEP for the key transport that provides "plain text awareness" as described here: http://www.rsa.com/rsalabs/node.asp?id=2346.
There is no way to find this encrypted message belongs to which receiver.
But you can do is try to decrypt the message if the decrypt is successful then that is the Receiver
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.