RTT wrote: >> 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.
Without the certificate(s) and private key(s) he may intercept transparently as long as he likes. When he wants to decrypt the session on the fly he has to go thru the handshake process on behave of the victim by presenting the stolen certificate(s), acting as a proxy server. > >>> >>> 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? Exactly. > Because everyone know how it works, That's the point, bugs in proprietary protocols are usually not found as fast as bugs in public protocols (by the good guys). > and if I'm going to develop my > Client and Server, I don't need to use something that is public > available. Of course you can, I just doubt that it's more secure than properly implemented SSL/TLS. -- Arno Garrels -- 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
