-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are a couple of things I see wrong with this systems:
1. If you are serious about the security of your encryption system make
it public so it can be tested
2. You have just told us how your client and server communicate and what
the data, even though you can't trust your encryption algorithm.
3. Now anyone who knows where these services are running could possibly
sniff your traffic and work on breaking the system
4. If you are serious about the security of your encryption system make
it public so it can be tested
5. I don't trust your system based on the fact I can't trust your
encryption algorithm
I know you only wanted an evaluation of the system, but if the
communication between client and server is dependent on an untested
algorithm your system could be vulnerable to different types of attacks.
Especially when there are more trusted algorithms that can be used and
have great utilities to code with them.
On Friday, September 6, 2002, at 12:46 PM, Bryan Ponnwitz wrote:
> I've designed an HR system for the company that I work for and part of
> the system is a server application which allows for program updates to
> be downloaded, messages to be sent to users and provides the ability to
> kick users. For this, I've developed my own protocol running on port
> 7282/tcp. Since this server is what I use for authentication, I had to
> build some encryption into the protocol so that usernames and passwords
> weren't being transmitted cleartext. My question is, how safe am I
> using this encryption? I've heard that homegrown encryption is asking
> for trouble, but it seems to me that it would be difficult to break it.
> In any case, this is the encryption method that this program will use
> since it's about to go into production, so please don't suggest
> alternatives; I'm only looking to evaluate the method I've developed.
> I've outlined my encryption methods bellow; take a look and let me know
> how tough you think it would be to crack. Any comments are welcome!
>
> -------
>
> The protocol is setup so that the first four bytes of any transfer are
> signaling data. Packets can be more than 4 bytes depending on what is
> in the signaling data, but 4 bytes is the minimum; for instance:
> EC 03 00 00 is the data you would send to the server to login. After
> the signaling data, you would have to put the length of the encrypted
> username (1 byte), the length of the encrypted password (1 byte), the
> encrypted username (varible size) and the encrypted password (varible
> size). In this case, you would have 6 + length of username + length of
> password bytes of data.
> In contrast, when the server verifies that you are who you say you are,
> it would send EA 03 00 00 to signal that your login has been accepted.
> There is no more data to send along with the signaling data so, in this
> case, the data is only 4 bytes long.
>
> If, at anytime, you send invalid signaling data to the server, you will
> be disconnected. If you send correct signaling data, but the rest of
> the data is malformed, the server will simply not respond. If you send
> invalid user credentials or try to send a request other than for an
> encryption key or to login without first logging in, the server will
> disconnect you. Until you login, the server will allow a client to send
> unlimited requests for encryption keys but will not allow you to request
> a new key once your logged in (you'll be disconnected if you request a
> new key).
>
> All text is encrypted using the following algorithm:
> enc = ((((char + E0) * 2 * E1 + 31 + E2) * E3 + (69 * E4)) * (E5 + E6) +
> (E7 * E8)) * 2 * E9
> Where enc is a Visual Basic Double (8 bytes) and char is the ascii
> character code to encrypt.
>
> For the following explanation, it's important to understand what's the
> signaling data and what is the data to be decrypted and used. This is a
> list of the signaling data I've used below and what it means.
>
> EB 03 00 00 = "Send me a key" if from a client and "Here's your key" if
> from a server. When the server sends this message, it's followed by 10
> bytes of data to be used for encryption.
> EC 03 00 00 = "This is my username and password". As always, bytes 0 -
> 3 are the signaling data, byte 4 is the length of the encrypted username
> (in bytes), byte 5 is the length of the encrypted password (in bytes),
> and the rest of the data is the encrypted username and password.
> EA 03 00 00 = "Your login has been accepted."
> BD 0B 00 00 = "Are there any updates for me to download" if from a
> client. The signaling data is followed by the name of the client
> computer encrypted. If from a server, it's an answer and byte 4 means
> "Yes" if it's a 1 and "No" if it's a 0.
> B9 0B 00 00 = Same as BD 0B 00 00, but would require Update.exe to be
> run to do the updating.
> BF 0B 00 00 = PING! ("Are you still there?")
> C0 0B 00 00 = PONG! ("Yes!")
> D3 07 00 00 = "Here's an encrypted message from an admin." The
> signaling data would be followed by the encrypted messsage.
>
> The following is a typical dialog to see between the server and client:
>
> (Connect on port 7282)
>
>> From Client: EB 03 00 00
> Send me an encryption key.
>
>> From Server: EB 03 00 00 3F DE B8 73 16 A1 D5 21 3C E7
> Here's your key. (The last 10 bytes are the key and are randomly
> generated numbers between 1 and 254.)
>
>> From Client: EC 03 00 00 70 40 00 40 AB 35 AF A0 70 42 00 40 5B BD 47
>> CA
> 76 42 00 40 7A A6 58 B0 77 42 00 40 A2 62 8C 9B 74 42 00 40 B7 5C D0 46
> 76 42 00 80 72 00 71 86 68 42 00 40 E9 07 D1 6C 72 42 00 40 E0 34 AE 67
> 76 42 00 40 B7 5C D0 46 76 42 00 40 B7 5C D0 46 76 42 00 40 28 F6 9C 6E
> 77 42 00 40 EA 23 7B A2 75 42 00 40 AD 6D 03 0C 77 42 00 40 A3 7E 36 D1
> 77 42 00 40 09 0D 8C 88 76 42 00 40 A2 62 8C 9B 74 42 00 40 84 95 25 EB
> 76 42 00 40 84 95 25 EB 76 42 00 40 28 F6 9C 6E 77 42 00 40 E0 34 AE 67
> 76 42 00 40 5B BD 47 CA 76 42 00 40 1D EB 25 FE 74 42
> This is my username and password; validate me. (usr: Bryan Ponnwitz
> pass: password)
>
>> From Server: EA 03 00 00
> Login accepted. (If the login were rejected, the client would be
> disconnected at this step instead of receiving the login accepted
> message.)
>
>> From Client: BD 0B 00 00 00 80 0E F7 A9 02 80 42 00 00 02 A5 B7 3A 82
>> 42
> 00 00 3A 4B 87 15 81 42 00 80 9E AA 0A 4D 82 42 00 80 65 9F 64 28 82 42
> 00 00 C5 E0 C2 95 7C 42 00 00 A9 0D 5B 28 7D 42
> Are there any updates this program should download for computer EdTec-1?
> (EdTec-1 is the name of my workstation)
>
>> From Server: BD 0B 00 00 00
> No. (If this were yes, you would see BD 0B 00 00 01.)
>
>> From Client: B9 0B 00 00 00 80 0E F7 A9 02 80 42 00 00 02 A5 B7 3A 82
>> 42
> 00 00 3A 4B 87 15 81 42 00 80 9E AA 0A 4D 82 42 00 80 65 9F 64 28 82 42
> 00 00 C5 E0 C2 95 7C 42 00 00 A9 0D 5B 28 7D 42
> Should I start Update.exe so it can download updates for EdTec-1?
>
>> From Server: B9 0B 00 00 00
> No.
>
> (While the client is logged on, the server will ping the client every 20
> seconds as shown below.)
>
>> From Server: BF 0B 00 00
> PING!
>
>> From Client: C0 0B 00 00
> PONG!
>
> (The client may also receive a message from an admin as shown bellow.)
>
>> From Server: D3 07 00 00 00 00 7E 25 21 0C 73 42 00 00 1E EA 13 A2 74
>> 42
> 00 00 DE 5E 63 F0 75 42 00 00 7E 79 44 08 76 42 00 00 FC 79 CF 64 6C 42
> 00 00 1E 6B F9 64 72 42 00 00 1E EA 13 A2 74 42 00 00 DE 5E 63 F0 75 42
> 00 00 DE 5E 63 F0 75 42 00 00 9E 7F 8F 42 74 42 00 00 5E 1F D6 D1 74 42
> 00 00 1E EA 13 A2 74 42
> You have received a message: "Test Message"
>
> And eventually when the client is ready to disconnect, the connection is
> just dropped, there is no "logoff" to say, just the connection being
> dropped.
>
>
> Bryan Ponnwitz
> Webmaster - Broome-Tioga Boces
> bponnwitat_private
> (607) 763-3609
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)
iD8DBQE9eRRqMtG2tK3HbY0RAoy0AJ9M7Z/HtQwCidzaJSehCyReA0q0QQCdFQUO
+9lJZSXqj+x+3WWbaKOtW6M=
=AgFV
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Sep 06 2002 - 14:26:09 PDT