4 ms·
Our crypto design is this - 1. The sender generates an AES-256 key for the transfer. 2. The receiver sends a public key to the sender. 3. The sender encrypts t
by tashmahalic 15y ago
Our crypto design is this -
1. The sender generates an AES-256 key for the transfer.
2. The receiver sends a public key to the sender.
3. The sender encrypts the AES key with the public key, and sends to the receiver.
4. The receiver decrypts the AES key.
5. The sender then sends all the bytes, encrypted with AES.
The point of using the AES key is that it's faster to encrypt/decrypt. The point of using the public/private keys is to get that key to the receiver in a secure way.
The transfer has a session key from our server so each peer can validate the identity of the other peer.
How's that sound?
- chacham15 15y agoIf those steps are all of the protocol, this is vulnerable to a man in the middle attack. The way that that is done is by having Eve intercept the public key sent to the sender and instead sends his own. Then the sender sends Eve the AES key and Eve sends the recipient her own AES key accomplishing the man in the middle attack.
- tashmahalic 15y agoMy understanding is that if the public key is transmitted from the receiver to the sender through our server instead of directly, that should be secure to MITM. This assumes that peer connections to our server are secure (SSL). Does this meet with your understanding?