Is this encryption method secure?

[ScratchCat]

I am working on a project in python which requires communication via sockets. This communication will contain sensitive data such as passwords, location data etc.

In order to encrypt the communication I am using a combination of RSA and AES from the pycryptodome module (the active fork of pycrypto) to exchange keys and perform the encryption.

 

The system runs as follows:

1. Form insecure socket connection

2. Client generates RSA keys and sends public key over unsecure network to server

3. Server receives key and generates two 32 byte hex strings from os.urandom , one for the AES key another for the initialisation vector.

4. Server encrypts these keys with the public RSA key and sends them back to the Client.

5. Client receives and decodes both keys.

6. Communication signals are then sent using AES-GSM    plaintext --> encrypt -----(socket transfer) ----- decrypt ---> plaintext

 

If the socket fails such as due to a tempoary network failure the entire algorithm will be run again.

 

Would this be secure in general cases i.e. no use of Shor's algorithm to break the RSA key?

If not where are the issues and how can I fix these?

 

Edit:

Replaced above method with certificate chain based validation and key exchange.

Edited October 23, 2017 by ScratchCat
Update

[JacobFW]

No, a man in the middle attack can intercept the public key, send his own public key to the server, and just decrypt, then reencrypt the data between the server and client, with neither of them aware of what's happening.

 

Encryption does require some sort of information that both clients know at the beginning.  For symmetric encryption it's the PreShared Key.  For Assymetric, it's the Certificate authority.  The operating system comes with the certificates of known and trusted certificate authorities, and those are used to establish a secure channel.

[ChalkChalkson]

7 minutes ago, ScratchCat said:

I am working on a project in python which requires communication via sockets. This communication will contain sensitive data such as passwords, location data etc.

In order to encrypt the communication I am using a combination of RSA and AES from the pycryptodome module (the active fork of pycrypto) to exchange keys and perform the encryption.

 

The system runs as follows:

1. Form insecure socket connection

2. Client generates RSA keys and sends public key over unsecure network to server

3. Server receives key and generates two 32 byte hex strings from os.urandom , one for the AES key another for the initialisation vector.

4. Server encrypts these keys with the public RSA key and sends them back to the Client.

5. Client receives and decodes both keys.

6. Communication signals are then sent using AES-GSM    plaintext --> encrypt -----(socket transfer) ----- decrypt ---> plaintext

 

If the socket fails such as due to a tempoary network failure the entire algorithm will be run again.

This is a pretty standard setup. os.urandom is generally considered crypologically secure, and the pycrypto implementations of AES and RSA are very wide spread thus probably pretty decent. If you want to go all in in terms of security, you might want to use DHEC or RSAEC instead.

7 minutes ago, ScratchCat said:

Would this be secure in general cases i.e. no use of Shor's algorithm to break the RSA key?

Even Shor's algorithm uses NP computing times, so if you go for 2048+ RSA you should be fine on that front.

 

In  the end the most important thing is your implementation, small errors in the implementation can open up attack vectors, for example a back-channel analysis can often be done if not specifically protected against. In general I'd say try to avoid handling passwords and other sensitive data yourself, try to check out googles and facebooks token based systems, they are mostly plug and play, and if the data you can get through those is sufficient they take a lot of burden from you

[ChalkChalkson]

6 minutes ago, JacobFW said:

No, a man in the middle attack can intercept the public key, send his own public key to the server, and just decrypt, then reencrypt the data between the server and client, with neither of them aware of what's happening.

An MITM attack on the client side is VERY hard to protect against unless you can have preshared keys specific to every single client, and that is pretty unrealistic for a small operation unless you send a key via email or the like in which case you pretty much just offload to problem to an unknown third entity 

[JacobFW]

4 minutes ago, ChalkChalkson said:

An MITM attack on the client side is VERY hard to protect against unless you can have preshared keys specific to every single client, and that is pretty unrealistic for a small operation unless you send a key via email or the like in which case you pretty much just offload to problem to an unknown third entity 

Not really.  That's a fairly realistic scenario, at pretty much both ends of the spectrum.  On one end at the higher security levels, you have the private keys being generated inside a Faraday cage inside a vault by a computer not hooked up to any network.  Both the people who work for the Certificate authority and the people who are buying the certificate are present.  The keys are generated, stored on a hard drive which is then given to the buyers, who then take it to their own server.  On the other hand (this is not as common anymore) you have people who meet and share their PGP keys in person so they can safely transmit files between each other.  

 

It's all about channels of communication.  If we restrict ourselves to only trying to establish a secure channel via digital means, then security is just a myth.  There is too little information to provide proper authentication.  When you buy a computer or a windows install disk/drive which again, comes preloaded with certificates, that is a physical channel of communication.  

[ScratchCat]

16 minutes ago, JacobFW said:

No, a man in the middle attack can intercept the public key, send his own public key to the server, and just decrypt, then reencrypt the data between the server and client, with neither of them aware of what's happening.

 

Encryption does require some sort of information that both clients know at the beginning.  For symmetric encryption it's the PreShared Key.  For Assymetric, it's the Certificate authority.  The operating system comes with the certificates of known and trusted certificate authorities, and those are used to establish a secure channel.

Establishing something akin to a certificate system is outside the scope of this problem and preshared keys would not be feasable either, at least for now.

[ChalkChalkson]

4 minutes ago, JacobFW said:

It's all about channels of communication.  If we restrict ourselves to only trying to establish a secure channel via digital means, then security is just a myth.  There is too little information to provide proper authentication.  When you buy a computer or a windows install disk/drive which again, comes preloaded with certificates, that is a physical channel of communication.  

Yeah, I agree, it is more secure if you preshare keys even via the postal services (like banks often do), however, if I want to buy a new program or the like and I have to wait for a letter to arrive you can be pretty certain I'll be going to a competitor, just for the convenience.

[JacobFW]

19 minutes ago, ScratchCat said:

Establishing something akin to a certificate system is outside the scope of this problem and preshared keys would not be feasable either, at least for now.

Then you'll have to get creative, but the principle still stands, there must be some kind of known quantity for a secure channel to exist.

 

14 minutes ago, ChalkChalkson said:

Yeah, I agree, it is more secure if you preshare keys even via the postal services (like banks often do), however, if I want to buy a new program or the like and I have to wait for a letter to arrive you can be pretty certain I'll be going to a competitor, just for the convenience.

Absolutely correct.  But there is a difference between building a secure system from the ground up, versus using one in today's internet age.  Using our computers we can establish a secure channel (maybe not military grade security, but almost certainly good enough for everything else).  So securely downloading some other program is not out of the question.

 

But there's also the PR factor.  It's bad enough trying your damnedest to design a program to be secure and releasing it to the public, only for hackers to starting finding bugs in it.  If you release a product to the public with a known and critical security flaw, it will be found and it will utterly destroy, not just your company, but your own name, and your career in the security industry is over.

Edited October 17, 2017 by JacobFW
forgot a word

[ChalkChalkson]

1 minute ago, JacobFW said:

But there's also the PR factor.  It's bad enough trying your damnedest to design a program to be secure and releasing it to the public, only for hackers to starting finding bugs in it.  If you release a product to the public with a known and critical security flaw, it will be found and it will utterly destroy, not just your company, but your own name, and your career in the security industry is over.

Actually disagree with you here. Mostly because OP seem to be focussed on building a program which has "good enough" security, not a program that is "secure" otherwise this would be a terrible place to post to. 

And in fact MITM attacks are so powerful, that the only way to get around it is 2 factor authentication. 

Speaking of which a possible other solution that can be done with moderate effort and is not terribly inconvenient is either using email as a second factor (as is so common in the industry) or much better sending an SMS to a mobile phone number setup at registration.

However this is still vulnerable to an MITM attack at signup, but hey if someone can do that, they can do pretty much anything

[ScratchCat]

13 minutes ago, ChalkChalkson said:

Actually disagree with you here. Mostly because OP seem to be focussed on building a program which has "good enough" security, not a program that is "secure" otherwise this would be a terrible place to post to. 

And in fact MITM attacks are so powerful, that the only way to get around it is 2 factor authentication. 

Speaking of which a possible other solution that can be done with moderate effort and is not terribly inconvenient is either using email as a second factor (as is so common in the industry) or much better sending an SMS to a mobile phone number setup at registration.

However this is still vulnerable to an MITM attack at signup, but hey if someone can do that, they can do pretty much anything

The program is just an experiment, most of the code is just simulating users anyway and it is available to anyone who wants to poke holes in it.

I may just add the option to use set preshared encryption keys rather than establishing them at run time for users who would can obtain keys for the server and for the clients securely.

 

 

Thank you to everyone who posted.

[ChalkChalkson]

Just now, ScratchCat said:

The program is just an experiment, most of the code is just simulating users anyway and it is available to anyone who wants to poke holes in it.

I may just add the option to use set preshared encryption keys rather than establishing them at run time for users who would can obtain keys for the server and for the clients securely.

 

 

Thank you to everyone who posted.

Could  you post a link? I would love to try to break it  

All jokes aside, you sparked my interest.

[ScratchCat]

Just now, ChalkChalkson said:

Could  you post a link? I would love to try to break it  

All jokes aside, you sparked my interest.

https://github.com/Scratchcat1/AATC

It's currently a large mess and a work in progress. The funny thing is that the Telegram bot portion seems most secure right now.

And yes, I know all passwords are stored in plaintext, that is also one of the many issues still ;).

Be warned: It can spawn more processes than chrome if you mess with the settings .

[leodaniel]

24 minutes ago, ChalkChalkson said:

And in fact MITM attacks are so powerful, that the only way to get around it is 2 factor authentication. 

Not really, you need just a trusted 3. Party, like a certificate authority... or a pre shared key... it's basically what you solve with SSL/TLS... you have a trusted 3. Party. Then you can check if the given message really comes from your server and was not intercepted. This of course requires, that you can trust the certificate authority... if thats the case, you re save  

 

By the way, two factor authentication has nothing to do with transmission security  

[ChalkChalkson]

3 minutes ago, leodaniel said:

Not really, you need just a trusted 3. Party, like a certificate authority... or a pre shared key... it's basically what you solve with SSL/TLS... you have a trusted 3. Party. Then you can check if the given message really comes from your server and was not intercepted. This of course requires, that you can trust the certificate authority... if thats the case, you re save  

 

Yeah, as I said, a trusted 3. party will solve the issue (I think I said offloading the problem to a 3. entity). But getting a certification agency to add you with your keys is pretty expensive and probably outside the scope of OP

And btw, don't forget, that an MITM attack can fake the certification agencies public key if a certain set of conditions apply. 

I assume big companies get around that issue by presharing the public keys of the authorities 

[leodaniel]

Just now, ChalkChalkson said:

Yeah, as I said, a trusted 3. party will solve the issue (I think I said offloading the problem to a 3. entity). But getting a certification agency to add you with your keys is pretty expensive and probably outside the scope of OP

Getting an SSL certificate can be free with let's encrypt... there is no reason why not to use SSL/TLS!

[ChalkChalkson]

1 minute ago, leodaniel said:

Getting an SSL certificate can be free with let's encrypt... there is no reason why not to use SSL/TLS!

True, but AFAI can tell OP is mostly righting this as an exercise in writing cryptographic code. I even recommended he should offload the entire process to an entity like Google

[leodaniel]

 

Just now, ChalkChalkson said:

True, but AFAI can tell OP is mostly righting this as an exercise in writing cryptographic code. I even recommended he should offload the entire process to an entity like Google

Then I agree.. it's fine for learning  just don't use it with real sensitive data  

[ScratchCat]

14 minutes ago, leodaniel said:

 

Then I agree.. it's fine for learning  just don't use it with real sensitive data  

 

16 minutes ago, ChalkChalkson said:

True, but AFAI can tell OP is mostly righting this as an exercise in writing cryptographic code. I even recommended he should offload the entire process to an entity like Google

It's just as an exercise, I'll leave it so that I or anyone who wants to add those features can do so in the future.

Though if I have time I shall look into adding it.

[ChalkChalkson]

5 hours ago, leodaniel said:

Getting an SSL certificate can be free with let's encrypt... 

Btw I did not know that service, every time I had to right code like that myself the solution was getting to the largest possible organisation  

[leodaniel]

25 minutes ago, ChalkChalkson said:

Btw I did not know that service, every time I had to right code like that myself the solution was getting to the largest possible organisation  

Of course it depends, you should not use a free SSL/TLS certificate for certain use cases, there are some benefits to paid ones (like Organization Validation, Extended Validation, liability protection,...), but generally speaking IMO there is no excuse in 2017 for not using SSL/TLS 

[ChalkChalkson]

32 minutes ago, leodaniel said:

Of course it depends, you should not use a free SSL/TLS certificate for certain use cases, there are some benefits to paid ones (like Organization Validation, Extended Validation, liability protection,...), but generally speaking IMO there is no excuse in 2017 for not using SSL/TLS 

Yeah, I really think you are probably right, SSL is fairly standard and ignoring 1 or 2 hickups they were usually pretty good about patching problems before they become such.

But still I think there is great value to never even touching sensitive data, if you can avoid it (unless you are extremely confident in your crypto)

[Yamoto42]

20 hours ago, leodaniel said:

Then I agree.. it's fine for learning  just don't use it with real sensitive data  

Yeah...rule 1 of cryptography:  Don't do it yourself.

[Blade of Grass]

On 2017-10-17 at 11:31 AM, ChalkChalkson said:

And btw, don't forget, that an MITM attack can fake the certification agencies public key if a certain set of conditions apply. 

What conditions would those be? 

[leodaniel]

6 hours ago, Blade of Grass said:

What conditions would those be? 

The current system (Certificate Authority) relies on the weakest CA. Basically you have to blindly trust the Certificates Authorities in the first place. So if a CA gets hacked it would be possible to issue some bogus certificates, worse, the private key of the CA could be stolen and used to create certificates.

There where some cases of bogus certificates in the past, if I remember correctly there was a bigger one with blackberry involved in some point... maybe just google if you want to know more about that.

There are currently s lot of CAs (1000+) so the safety of TLS really comes down to the weakest member in this chain!

[Blade of Grass]

9 hours ago, leodaniel said:

The current system (Certificate Authority) relies on the weakest CA. Basically you have to blindly trust the Certificates Authorities in the first place. So if a CA gets hacked it would be possible to issue some bogus certificates, worse, the private key of the CA could be stolen and used to create certificates.

There where some cases of bogus certificates in the past, if I remember correctly there was a bigger one with blackberry involved in some point... maybe just google if you want to know more about that.

There are currently s lot of CAs (1000+) so the safety of TLS really comes down to the weakest member in this chain!

Trust is an inherent issue in our CA system, but from @ChalkChalkson post it seemed as if he was talking about some other issue.

 

I haven't heard of the issue with Blackberry, but in the past manufacturers have added their own certificates in the trust (i.e. Lenovo), I guess they did something similar?