Ofnuts wrote:"it then encrypts it using the user hash": encrypts how? And what is the user hash?
Ofnuts wrote:If one end can find the current date-time necessary to decrypt what is sent by the other, then some snooper can, too.
Ofnuts wrote:What good does the out-of-order packet dropping? How do you recover from missing packets?
Ofnuts wrote:Why so much trouble when you can use the field-proven SSL?
GearsGod wrote:when the user had signed up, a user-specific hash was created only known by the server and user programs
GearsGod wrote:just because they have the date-time means nothing without the secrete hash also used to encrypt (key=users hash / salt= current date and time)
GearsGod wrote:it ensures that reply attacks are useless, so capturing a packet and then resending it wont do any good
GearsGod wrote:I could, but true legit SSL cost money
GearsGod wrote:and I know it sounds bad but I am cheap as junk and I also wish to maybe one day provide an alternative to secure traffic.
A better question is why not go through the trouble of trying something new?
Nothing now standard was programmed easily.
wavic wrote:Why you are trying to invent the wheel?
There are two major ways to encrypt the traffic - asynchronous and synchronous. Pick one and just use it.
Users browsing this forum: No registered users and 1 guest