With a stolen key that's easy.
Sure, and this is exactly what SSL try to circumvent.
But not so easy if the encrypt key is not a fixed value, but a variable
one. The attacker will need to stole the client or server code and
reverse engineering it too.
This is also valid for SSL.
No, the difference is that SSL is able to detect the man in the middle.
Usually the certificate includes some information like the domain
name or IP address, so even if the attacker used a stolen certificate
peer verification would fail and the connection won't be established.
Man in the middle attacks intercepts data in a transparent way, in the
"middle of the line" and in a ongoing communication . The "in the
middle" IP address is not even a variable for the peer verification.
I'm not replying to you, Arno, to be impertinent. Far from that. It's
just my opinion that a symmetric keyed algorithm, such as AES or
Blowfish, with a clever time volatile salt added to the key, is enough
for this case in particular.
The weak point here is key delivery. Keys should be changed very
frequently. How do you make sure that keys are not stolen and
received by the right people? They should never be hard coded in the
application. SSL negotiates a unique symmetric key per session, so even
if the key was found by brute force it can be used only to decrypt a
single SSL session.
True, but you can also have you own key exchange method too.
And you would reply, so why not use the already available SSL protocol
that do exactly that?
Because everyone know how it works, and if I'm going to develop my
Client and Server, I don't need to use something that is public available.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
