because the message, after being encrypted isn't the same. There's a new vector generated each time the message is getting encrypted but that doesn't impact the decryption. you should be able to get your decrypted message without any issue.
Hello Sir, If I want to mention this project in my resume can you help me with it's description point i.e. how we are doing things here in short or if there is some sort of project report is there can you give us ????
That would be true if the applications communicate in both ways. If we only communicate in one way (sender-receiver) The sender needs to have the public key and the receiver needs to have the private key from the same pair as the sender's. But if we have a communication in both ways, then we need to have two keypairs (KP1 and KP2) the first application should have the Private key from KP1 and the Public key from KP2 and the second application should have the Public key from KP1 and the Private key from KP2. The process then becomes Encrypt with pub key from KP1 > decrypt with priv Key from KP1> read message > encrypt reply with pub key from KP2 > send > decrypt message with priv key from KP2.
@@amirunakmald868 you can use as many key pairs as you need in your application. One key pair is used to encrypt and decrypt messages. If you want to send messages between 3 entities you will need to use 3 different key pairs. In the video I have created a single key pair but in that case you will use around tripple the attributes used in the video
Nice educational video! I'm wondering how it would work if we are sending and receiving messages between two clients. I'm guessing the client application would do the encryption and decryption on its end and not the server? The server would just maybe store and publish these encrypted messages between the two clients. But how would the server even send the private/public keys to the different clients in a safe way?
That's a good question. You can in fact use a server that would store the public keys. So whenever client A wants to talk to client B they'll get the public key of client A from the server encrypt the message and send it to client B. And if client B wants to talk to client A, they can request the public key of client A from the server and then encrypt it before sending them. This requires the client to generate a keypair, keep the private key and send the public key to the server to be stored. Notice that I am talking about the public key which is safe to share since the message will only be decrypted by the client who generated the public key. One more secure way is that in your application, you have a predefined keypair between clients and servers and then you can generate AES keys and send them between clients using the predefined encryptions. There are many other ways and you can make combinations between different encryption methods based on your need and based on how secure you want your app to be.
Thanks for your explanations for saving our time to read the document and to piece all the puzzle together!
Thanks man. This is quiet helpful.
greetings from brazil! thanks bro
Very professional video, thank you sir!
Sir I want to give my own message as an input so the project would be able to give correct output, and how implement these
Thanks for your wonderful explanation.. can I get the code as a compressed file??
Why is the response body different from the one that's received from postman getSecretMessage?
because the message, after being encrypted isn't the same. There's a new vector generated each time the message is getting encrypted but that doesn't impact the decryption. you should be able to get your decrypted message without any issue.
Hello Sir, If I want to mention this project in my resume can you help me with it's description point i.e. how we are doing things here in short or if there is some sort of project report is there can you give us ????
Awesome
I have a question, to send and receive encrypted messages, we need to know the private key and public key in both sides, right?
That would be true if the applications communicate in both ways. If we only communicate in one way (sender-receiver) The sender needs to have the public key and the receiver needs to have the private key from the same pair as the sender's.
But if we have a communication in both ways, then we need to have two keypairs (KP1 and KP2) the first application should have the Private key from KP1 and the Public key from KP2 and the second application should have the Public key from KP1 and the Private key from KP2.
The process then becomes Encrypt with pub key from KP1 > decrypt with priv Key from KP1> read message > encrypt reply with pub key from KP2 > send > decrypt message with priv key from KP2.
@@WhiteBatCodes hi so this tutorial is on one way communication right?
@@amirunakmald868 yes! It's one way. If you want a secure bidirectional communication, you'll need to use two key pairs.
@@WhiteBatCodes sorry but simple yet important question, can RSA algorithm do that?
@@amirunakmald868 you can use as many key pairs as you need in your application. One key pair is used to encrypt and decrypt messages. If you want to send messages between 3 entities you will need to use 3 different key pairs.
In the video I have created a single key pair but in that case you will use around tripple the attributes used in the video
Nice educational video! I'm wondering how it would work if we are sending and receiving messages between two clients.
I'm guessing the client application would do the encryption and decryption on its end and not the server? The server would just maybe store and publish these encrypted messages between the two clients.
But how would the server even send the private/public keys to the different clients in a safe way?
That's a good question. You can in fact use a server that would store the public keys. So whenever client A wants to talk to client B they'll get the public key of client A from the server encrypt the message and send it to client B. And if client B wants to talk to client A, they can request the public key of client A from the server and then encrypt it before sending them. This requires the client to generate a keypair, keep the private key and send the public key to the server to be stored.
Notice that I am talking about the public key which is safe to share since the message will only be decrypted by the client who generated the public key.
One more secure way is that in your application, you have a predefined keypair between clients and servers and then you can generate AES keys and send them between clients using the predefined encryptions.
There are many other ways and you can make combinations between different encryption methods based on your need and based on how secure you want your app to be.
@@WhiteBatCodes wow! Thank you! 🙏