hi guys,

First let me start by saying that I am by far not a crypto guru. I just
happened to get caught up in the need to secure a TCP session
using both authentication and encryption, and I'm slowly studying
the matter.
The situation is as follows:

There are two programs, one the client and the second is the server.
These two tiers communicate using some protocol over TCP.
The goal is to provide an authentication mechanism based on a
password/passphrase, and then have the traffic between the two
encrypted so that anyone sniffing it will not be able to figure it out.
The idea is to not only secure the traffic, but making sure only the
appropriate user can use the server (it is designed to be used by
only one person at a time).
So far, that is the problem, now to my idea, which I have no way
of judging if is even secure.

Let's take the assumption that the server knows the correct
password. For the sake of argument, it is encrypted using MD5
and stored locally on the server in some file.
We'll also assume that when the TCP connection is established,
the first command to the server should be of the following format:

PASS <encrypted authentication string>

Now, what I thought to do was that when the password is entered
by a user, it is automatically hashed using MD5 (and thus, the
entered password is not kept), and then sent to be the auth
string, BUT, after having been encrypted ITSELF, so that no1
can sniff it and try to brute force it.
How to encrypt the pass ? Well, the first obvious thought I had
was to use the hash itself to encrypt itself again, using XOR.
When my brain switched on, I realized that anything XORed
with itself becomes zeroes, so, no point there.
The solution is to add another string to it, so that the password
hash doesnt XOR with itself and give 0.
A good string to add is for example a UTC time, which is just
the seconds elapsed from epoch (in Unix).
However, if any1 were to sniff this, he would know that the first
octets are numbers, and have a pretty good estimate on the
time (since he sniffs traffic that passes right after the time was
taken from the OS). So if the padd time is for example 1000000,
it would likely be 1000001 or something of the sorts when the
traffic passes through the network. Knowing a few characters
that you can XOR the traffic with will let you find a part of the
hash, and that means reducing the number of possiblities left
by a LOT
So, after I realized THAT won't work as well, I tried to think of
a way to padd the beginning of the hash with something that
is NOT guessable.
The idea is to take the password, add the time string to it, and
use MD5 on that. What we get is a different hash, which we
cannot guess in advance (we dont know the pword).
We use say half of the chars from this new hash, we concatenate
to that our password hash, and send that over the network,
XOR encrypred with the password hash.

so for example:

password hash: e4uerhgergh1
time+password hash: th894ht4er38

we would send: th894h e4uerhgergh1 (without the space)

XORed with e4uerhgergh1 (since the XORing hash is smaller in
length, we will tile the XORing..).

The server receives this, and knows that the first 6 chars should
be dumped (we used 6 pads) and takes the rest and decrypts
them using his stored password (but making sure to start from
the 7th char of the hash).

This is just the auth part, and the hash can be used for encryption
later on.

Now the attack ideas. Since the only way to check if a correct
password has been entered is to initiate a connection, I see
little possibility that any bruteforce can be done on this model.
After all, if you cant try at least a few thousands of attempts per
second, you really can't bruteforce...

The big question is, are there any ways of cryptoanalysis that
can somehow work on the encrypted info passed to the server?
I mean, if the password is good, MD5 will give a good hash,
and using the time+pass, you really do get a padding which cannot
be guessed (or so I think hehe).


Any guru here wanna comment on this model ? sugget ways
to attack it ?
It might not be THE way I choose to do this, since I'm hoping on
using SSL or TLS, but still...

Thanks in advance, and my apologies for the long message,
Lord Soth

Hi Lord Soth,

hopefully I did not misread your post but here are some attacks that come to mind right away.

#1. Even though the time is hashed and concanted lets say
strcat (*timehash, *passwordhash) . Given the person is sniffing he can still find a relation that the first 6 chars are just pseudo because the password hash will always be the same anyways.

Suggestion: Take the time hash and scramble it using some maths with the second hash. Then have the time hash concatenated with that scrambled version. when the server recieves it have the server code take the first 6 chars and do the reverse scramble (Decryption) with those chars and get a resulting password hash.

#2. Given they can sniff out this information in the first place means it will be insecure. Reason for this is the person can simply do a replay attack. Log what was sent to the server (the hash sent) and simply send that exact hash to the server and mimic your sends. Hence, pointless ruitine.

Suggestion: Use public key setup and exchange block cipher keys which will then be used as the tunnel to exchange the password hash.

Hopefully I did not misread what you wrote , good luck on your authentication system. -Sab

This is what I'd suggest as well. Assuming the attacker can't do a man-in-the-middle attack, do a Diffie-Hellman key exchange. You could use a block cipher at this point to transmit the hash; another possibility is to send a MAC of the password. A MAC is a keyed hash; that is, you can't verify the hash unless you know the key. See Schneier for details or drop me a note.

Schneier is definately on my next book list

In fact, now I'm reading Scott Oaks' Java security (the client was
written in java, by yours truly..).
The other part is a linux daemon written in C, so, at the minimum
I will have to read a book such as "Applied Cryptography".
Anyways, if I run into more trouble, I'll be sure to drop you guys a
note.

Thanks in the meantime...

LS

You can find a pirated online copy here:

h**p://www.geocities.com/condor60ro/document/0471128457/ewtoc.html

According to section 18.4 on MACs, this construction using a hash function H and a key K is secure (comma means concatenate):

H (K, H (K,M))

You have to have some kind of random nonce to prevent replay attacks; I suggest generating a random key during the key exchange.