views:

111

answers:

3

I'm not a cryptography expert, I actually only have a little bit of experience using it at all. Anyways, the time has come where one of my applications demands that I have some encryption set up. Please note, the program won't be managing anything super critical that will be able to cause a lot of damage.

Anyways, I was just trying to see if this scheme that I'm using is common and if there are flaws (of which there may be completely stupid & horribly flawed design, that's why I'm asking).

Ok, I have a client -> server communication. The Client I can hard code in the public portion of a 2048-bit RSA key. When the client wants to initiate a secure connection, he sends his username, md5 hash of his password, and a hash of a random UUID, all of which has been encrypted against the server's Public Key. The server receives the information and decrypts using its private key. Checks the database to see if his login + pass work & if they do, create a new entry in the "Sessions" table in the DB. This includes a SessionID, UID (user ID), and the UUID hash. Using the corresponding session ID's UUID as the keyphrase, the server will then send back a message that has the Blowfish encrypted word "Success!" + a random UUID (this message is Digitally Signed so we can determine if it came from the server or not). From that point on, when the client sends info to the server, it will be with a plaintext sess_id & include a Blowfish encrypted message, using the corresponding Session ID's blowfish secret (stored encrypted in the DB) as the key to encrypt / decrypt.

Specifically, I am curious as to whether this system "should work" or if anyone notices that it's glaringly obvious that a vulnerability exists, such as MITM.

A: 

From that point on, when the client sends info to the server, it will be with a plaintext sess_id & include a Blowfish encrypted message, using the corresponding Session ID as the key to encrypt / decrypt.

If you're sending the session id in plaintext, and using it as the encryption key, how is that secure?

I see no reason why you can't use standard SSL authentication and let the library implementer worry about the handshaking.

Draemon
Crowe T. Robot
Ok, that's clear then. I still think SSL would be easier.
Draemon
You're right, SSL will be easier and more secure. After further investigation (I had no idea that this is exactly what SSL does (more or less)), I've decided to go ahead and use SSL for the project. Thanks for your advice.
Crowe T. Robot
+2  A: 

Just use SSL or DTLS, IKEv2, HIP, EAP or some suitable standard protocol. Don't try to invent your own crypto protocols, nobody has enough expertise to do this on their own. Your protocol doesn't have nearly enough entropy in it, so far as I can see, so your resulting keys will be pretty weak.

Andrew McGregor
Thanks for the response. I will be using full blown SSL for this project vs. my own rolled solution. I simply didn't know this is what SSL was / implementation (enterprise architecture wise) details well enough to go with it from the start. Now that I know that the way I was going to do it is way less than secure, I'll stick to good ol' SSL.
Crowe T. Robot
+2  A: 

Issues I can see off the top of my head (although you have left out most of the details, which is where the devil famously resides):

  • If you're using a UUID generator rather than a real cryptographic RNG, it likely has insufficient entropy. Don't discount this - in the real world, the favourite way of covertly weakening an encryption system has been to weaken the RNG;

  • Your initial RSA encryption sounds like it is susceptible to a small-exponent attack, and potentially other creative attacks. There's too much structure there to be comfortable;

  • It sounds like there's numerous opportunities for replay attacks;

  • What block cipher mode are you using with Blowfish?

I recommend using TLS/SSL - it's had a lot more friendly eyes looking at it for a lot longer than anything you build yourself ever will.

caf
Thanks for your very well laid out thoughts on this, especially the part concerning PRNG entropy. That's part of what I was concerned about specifically, but didn't know how that's referred to technically before you said it. Never knowing what SSL truly was, I did go about creating a system which is very similar, yet rolled myself, which like you said is almost always less secure. Moving forward, I will implement SSL encrytion rather than my own rolled solution. Thanks for the advice.
Crowe T. Robot