RTT wrote: >>> "Man in the Middle" attacks don't work if the "man in the middle" >>> don't know how to handle the encrypted data/protocol he is >>> intercepting. >> True, and how do you manage that is not happening? > > Can't be happening because the man in the middle can't generate valid > data, or alter intercepted data maintaining its validity, if he can't > break the encrypt algorithm in time to inject his packets of data.
With a stolen key that's easy. > 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. > >>> Closed standards are inheritable much more secure than >>> open standards. >> That's nothing but security through obscurity: >> http://en.wikipedia.org/wiki/Security_through_obscurity > > That's just a theoretic argument, not an undoubted reality. There are enough examples mentioned in that wiki article to prove the opposite. > >>> In this type of projects the use of the of this >>> standard is wrong. He just don't need the SSL implementation >>> complexity, nor the result slow to start communication, just to get >>> his data secure. >> I don't know what _he needs, if _you want to invent your own security >> standards feel free to do so. SSL/TLS is used and accepted >> world-wide. > > Neither do I, but I'm assuming he only need what a generic data > communication service needs in terms of security. Pass data in a way > it can't be tampered/understood, if intercepted by someone outside the > communication points. > > 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. -- 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
