Question

We have a custom built program that needs authenticated/encrypted communication between a client and a server[both in Python].

We are doing an overhaul from custom written Diffie-Hellman+AES to RSA+AES in a non-orthodox way. So I would be very interested in comments about my idea.

Prequisites: Klient has a 128bit RegistrationKey which needs to remain a secret during the authentication – this key is also the only shared secret between the server and client.

1. Client contacts the server over an insecure channel and asks the servers RSA PubKey
2. Client then queries the server:
   [pseudocode follows]

       RegistrationKey = "1dbe665ac7a944beb67f106f779e890b"
       clientname = "foobar"
       randomkey = random(bits=128)
       rsa_cp = RSA(key=pubkey, data=randomkey+clientname)
       aes_cp = AES(key=RegistrationKey, data=RegistrationKey+rsa_cp)
       send(aes_cp)

3. Server then responds:
[pseudocode follows]

       # Server decrypts the data and sees if it has a valid RegistrationKey, if it does...
       clientuuid = random(bits=128)
       sharedkey = random(bits=128)
       rsa_cp = RSA(key=privkey, data=clientuuid+sharedkey)
       aes_cp = AES(key=randomkey[got from client], data= rsa_cp)
       send(aes_cp)

Now both sides know the "clientuuid", "sharedkey" which the client can use later to authenticate itself. The method above should be secure even when the attacker learns the regkey later since he would have to crack the RSA key AND man-in-the-middle attacks(on RSA) should stop the auth. from completing correctly.
The only possible attack method I see would be the case where the attacker knows the regkey AND can alter the traffic during the authentication. Am i correct?

---

I really want to hear your ides on what to add/remove from this method and If you know a much better way to do this kind of exchange.
PS! We are currently using Diffie-Hellman(my own lib, so it probably has flaws) and we have tried TLSv1.2 with PreSharedKeys(didn't work for some reason) and we are CONSTRICTED to http protocols since we need to do this in django. And because we are doing this in http we try to keep the request/answer count as low as possible(no sessions would be the best) - 1 would be the best 🙂

If you have any questions about the specifics, please ask.

So, you crypto/security geeks, please give me a helping hand 🙂

Answer 1

Don’t re-invent the wheal, use HTTPS.

The server can issue certificates to the client and store them in the Database. Clients can be distributed with the server’s self-signed certificate for verification. The server can verify clients by using Apache’s HTTPS Environment Variables.