NSA PROOF encryption
Hello experts!
Todays Question comes with a heavy weight on security. Given the new revalations that NSA spies on ALL internet traffic, heightened security is a priority.
What methods to encrypt internet messages and files between websites and clients will result in NSA proof security
Thanks for playing
Todays Question comes with a heavy weight on security. Given the new revalations that NSA spies on ALL internet traffic, heightened security is a priority.
What methods to encrypt internet messages and files between websites and clients will result in NSA proof security
Thanks for playing
Sorry but I honestly believe the answer is none.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ive heard rumors that nsa can crack Aes 256 within a week or less
ASKER
@dave, the token and private key techniques are insufficient as well. I use x509, but its a simple encryption method with just one private key. With a city of high tech machines like NSA's new centers x509 stands no chance.
The only thing it will stop is on the fly decryption and to limit access to connect with the website. But ild messages will eventially be cracked withing a few days.
Im looking for new ideas.
Perhaps a new algorithm technique
TrueCrypt methods are as close as i found so far to encrypt data, however, after transferring data, their files get undecryptable.
I'm looking for a solution to develop inhouse which works so all your suggestions are appreciated
The only thing it will stop is on the fly decryption and to limit access to connect with the website. But ild messages will eventially be cracked withing a few days.
Im looking for new ideas.
Perhaps a new algorithm technique
TrueCrypt methods are as close as i found so far to encrypt data, however, after transferring data, their files get undecryptable.
I'm looking for a solution to develop inhouse which works so all your suggestions are appreciated
There is no reason to believe we can't trust either AES (which wasn't designed by the NSA) or RSA keys above around 3K.
As far as anyone can tell, the NSA have been taking steps to work around those two facts. That could of course be a smokescreen, but if they had super-secret methods to break RSA or AES, they would not waste time and effort on doing so.
Conversely, Snowden (and Schneier, who has seen the documents Snowden has shared) both say you can trust crypto, but not the software it is embedded in - Schneier in particular has called out his doubts over the EC encryption method, the now known to be badly broken by design and the PRNG based on it that the NSA/NIST were promoting - however, he just renewed his PGP key, and went with a 4K RSA+256 bit AES key (which presumably he trusts).
I am not going to go around second-guessing Schneier, who was one of the finalists in the AES competition and provided one of the other algos used in Truecrypt.
X509 (well, TLS and S/MIME, the schemes based on using X509) is still secure; as both are hybrid schemes (using strong symmetric crypto for the message, and only encrypting the symmetric key using asymmetric methods) the one asymmetric key, being used only for a tiny amount of data, is going to be very hard indeed to crack.
It is important to avoid trying to invent your own crypto schemes - that never ends well - however, you can often add additional encryption, often quite weak, to make a hybrid scheme that is no worse than using the trusted crypto (MS took that approach with DESX - instead of re-inventing the wheel, they added a simple XOR step before and after single DES - the result is almost as strong as 3DES, but less than half the processing load). Truecrypt offers a similar mechanism, allowing you to mix and match its three candidate methods for additional security.
The issue isn't the crypto, its getting it into the hands of who needs it. Anyone can issue X509 keys at 4K keystrength, but only a CA is automagically trusted by the major browsers to do so.
As far as anyone can tell, the NSA have been taking steps to work around those two facts. That could of course be a smokescreen, but if they had super-secret methods to break RSA or AES, they would not waste time and effort on doing so.
Conversely, Snowden (and Schneier, who has seen the documents Snowden has shared) both say you can trust crypto, but not the software it is embedded in - Schneier in particular has called out his doubts over the EC encryption method, the now known to be badly broken by design and the PRNG based on it that the NSA/NIST were promoting - however, he just renewed his PGP key, and went with a 4K RSA+256 bit AES key (which presumably he trusts).
I am not going to go around second-guessing Schneier, who was one of the finalists in the AES competition and provided one of the other algos used in Truecrypt.
X509 (well, TLS and S/MIME, the schemes based on using X509) is still secure; as both are hybrid schemes (using strong symmetric crypto for the message, and only encrypting the symmetric key using asymmetric methods) the one asymmetric key, being used only for a tiny amount of data, is going to be very hard indeed to crack.
It is important to avoid trying to invent your own crypto schemes - that never ends well - however, you can often add additional encryption, often quite weak, to make a hybrid scheme that is no worse than using the trusted crypto (MS took that approach with DESX - instead of re-inventing the wheel, they added a simple XOR step before and after single DES - the result is almost as strong as 3DES, but less than half the processing load). Truecrypt offers a similar mechanism, allowing you to mix and match its three candidate methods for additional security.
The issue isn't the crypto, its getting it into the hands of who needs it. Anyone can issue X509 keys at 4K keystrength, but only a CA is automagically trusted by the major browsers to do so.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks guys.
Here is the model I am looking for for transmission
I'm looking for new encryption methods to jumble the data
and perhaps also new ways of transporting the data instead of SSL, http, https
Here is the model I am looking for for transmission
I'm looking for new encryption methods to jumble the data
and perhaps also new ways of transporting the data instead of SSL, http, https
What you really want to do to be secure is use non-writeable media, like a CD/DVD. Create a live-cd that boots up the OS from the DVD drive, and then download you're files from the internet or you email. You've downloaded them to memory then, and once the pc is off for a few minutes, it's unrecoverable. Just keep them in the internet until you need to access them again.
You could have 30 passwords in you're diagram above, but you really only need one good one and a well chosen algorithm. Also the private key is not what you exchange, you never give that one out, you can exchange you're public key openly.
The way PGP/GPG works is by asymmetry, one key to encode and one key to decode, you can use either technically. But what you want is someone to use the public key you freely share to encrypt something that only your private key can decode.
I use your public key to encrypt a message, you use the private key to decrypt it. You send me a message by encrypting it in my public key, I decrypt it using my private key.
I can also (technically) encrypt a message using my private key, and then my public key can be used to decrypt it, but since my public key is well known, and I don't want the message decrypted by anyone else who might see it, I use your pub-key instead.
As to transport, you have to understand there aren't a lot of alternatives that have been scrutinized like SSL has. There are plenty of technologies built on SSL/TLS, like httpS, SSH, SFTP, FTPS, SCP and much more. You may want to think of a container like 7zip as an additional barrier, but that's where I'd stop. 7zip or Rar containers are very slow when using brute force, maybe 100-200 tries per second, which is sloooooow compared to almost anything else.
>What methods to encrypt internet messages and files between websites and clients will result in NSA proof security
The same ones we use today. We just need to change the locks. The NSA is exploiting the plain-text side more than they are interested or trying to break the encrypted side. They are working smarter, not harder.
-rich
You could have 30 passwords in you're diagram above, but you really only need one good one and a well chosen algorithm. Also the private key is not what you exchange, you never give that one out, you can exchange you're public key openly.
The way PGP/GPG works is by asymmetry, one key to encode and one key to decode, you can use either technically. But what you want is someone to use the public key you freely share to encrypt something that only your private key can decode.
I use your public key to encrypt a message, you use the private key to decrypt it. You send me a message by encrypting it in my public key, I decrypt it using my private key.
I can also (technically) encrypt a message using my private key, and then my public key can be used to decrypt it, but since my public key is well known, and I don't want the message decrypted by anyone else who might see it, I use your pub-key instead.
As to transport, you have to understand there aren't a lot of alternatives that have been scrutinized like SSL has. There are plenty of technologies built on SSL/TLS, like httpS, SSH, SFTP, FTPS, SCP and much more. You may want to think of a container like 7zip as an additional barrier, but that's where I'd stop. 7zip or Rar containers are very slow when using brute force, maybe 100-200 tries per second, which is sloooooow compared to almost anything else.
>What methods to encrypt internet messages and files between websites and clients will result in NSA proof security
The same ones we use today. We just need to change the locks. The NSA is exploiting the plain-text side more than they are interested or trying to break the encrypted side. They are working smarter, not harder.
-rich
You aren't going to want to invent new crypto, trust me. That is an extremely difficult task, and you would want to do it three times over. just.. no.
you could of course use tunnelling to achieve the same effect, with different sorts of crypto for each tunnel, and multiple levels of tunnel. The best protocol for that isn't SSL, but SSH - as that has tunnelling support "built in" and there are existing implementations and libraries you could use to bootstrap your way up to your desired goal.
Consider the following scenario.
1) your app (or applet) connects using SSH to the "outside" server. This is a VM running in your DMZ, with one port listening to the internet (on the SSH port) and one dedicated vlan on a second interface. Only one login is valid for this, and it requires an RSA key (embedded in the client) not a password.
2) this app logs in (with 3DES), and immediately opens a tunnel to the only listening server on the second interface, which is (again) ssh. this accepts a username and password from the client so as to identify the person logging in to the second server.
3) the app logs into this second server (with Blowfish), and opens a SECOND tunnel to a loopback interface on port 443
4) the app launches an embedded browser which uses the second tunnel to open a web page over HTTPS (DHE+RSA+AES) in the conventional manner.
There. three layers of different encryption, one hard coded local RSA key, one username/password login, and one serverside certificate.
Would take some coding, but you could *simulate* the setup easily enough for testing.
First, configure a virtual machine with linux and openssh. restrict login to RSA and 3DES.
Second, set up another vm, running openssh (Blowfish only) and apache; have apache listen on loopback only and port 443 only. join this to the first vm with a dedicated vlan.
Log into the first VM with puTTY. use the ability of puTTY to open a tunnel from local port 222 to port 22 on the second VM
Log into the second VM by connecting a second copy of puTTY to port localhost:222 - open a tunnel from port 8443 to localhost:443 (note, this putty is working *entirely* inside the 3DES encrypted tunnel from the first putty)
Log onto https://localhost:8443/ with your choice of web browser. Note that this connection is an encrypted (https) one, but over the Blowfish tunnel of puTTY #2, which is itself connected over the 3DES tunnel of puTTY #1
so - doable, if you really want to, using only conventional encryption methods and protocols.
you could of course use tunnelling to achieve the same effect, with different sorts of crypto for each tunnel, and multiple levels of tunnel. The best protocol for that isn't SSL, but SSH - as that has tunnelling support "built in" and there are existing implementations and libraries you could use to bootstrap your way up to your desired goal.
Consider the following scenario.
1) your app (or applet) connects using SSH to the "outside" server. This is a VM running in your DMZ, with one port listening to the internet (on the SSH port) and one dedicated vlan on a second interface. Only one login is valid for this, and it requires an RSA key (embedded in the client) not a password.
2) this app logs in (with 3DES), and immediately opens a tunnel to the only listening server on the second interface, which is (again) ssh. this accepts a username and password from the client so as to identify the person logging in to the second server.
3) the app logs into this second server (with Blowfish), and opens a SECOND tunnel to a loopback interface on port 443
4) the app launches an embedded browser which uses the second tunnel to open a web page over HTTPS (DHE+RSA+AES) in the conventional manner.
There. three layers of different encryption, one hard coded local RSA key, one username/password login, and one serverside certificate.
Would take some coding, but you could *simulate* the setup easily enough for testing.
First, configure a virtual machine with linux and openssh. restrict login to RSA and 3DES.
Second, set up another vm, running openssh (Blowfish only) and apache; have apache listen on loopback only and port 443 only. join this to the first vm with a dedicated vlan.
Log into the first VM with puTTY. use the ability of puTTY to open a tunnel from local port 222 to port 22 on the second VM
Log into the second VM by connecting a second copy of puTTY to port localhost:222 - open a tunnel from port 8443 to localhost:443 (note, this putty is working *entirely* inside the 3DES encrypted tunnel from the first putty)
Log onto https://localhost:8443/ with your choice of web browser. Note that this connection is an encrypted (https) one, but over the Blowfish tunnel of puTTY #2, which is itself connected over the 3DES tunnel of puTTY #1
so - doable, if you really want to, using only conventional encryption methods and protocols.
ASKER
thanks rich. The reason i sak is to roll out software to our customers who will not need to worry about security when communicating with us. the focus is to make all data transactions between us and them, especially encrypted
thats why the boot from DVD is not an option for us.
If their computer is compramised, thats their problem. Nothing wrong from our end
thats why the boot from DVD is not an option for us.
If their computer is compramised, thats their problem. Nothing wrong from our end
If it has to be easy to use, then you should use what's already in place. That's not where the NSA attack vector, it's the opposite when they need to surveil a large part of the internet. When they have to target, then it's possible, for them to look at attacking httpS, but there are easier methods.
If your customer is compromised, so is your transaction (after the fact). If there is some trail, and remember just because a communication can't be read doesn't mean it can't be tracked. You can ascertain a lot about encrypted transactions and payloads just by watching them.
So perhaps to get all experts on the same page, can you re-state your question with the goal you have. https://www.schneier.com/blog/archives/2013/09/new_nsa_leak_sh.html
It's going to be hard to build up trust again, but when we do, it's going to be using the same technology as before, just updated versions of it. You, me or any expert here won't devise anything better than what's out there now, but it's good to have input into it.
-rich
If your customer is compromised, so is your transaction (after the fact). If there is some trail, and remember just because a communication can't be read doesn't mean it can't be tracked. You can ascertain a lot about encrypted transactions and payloads just by watching them.
So perhaps to get all experts on the same page, can you re-state your question with the goal you have. https://www.schneier.com/blog/archives/2013/09/new_nsa_leak_sh.html
It's going to be hard to build up trust again, but when we do, it's going to be using the same technology as before, just updated versions of it. You, me or any expert here won't devise anything better than what's out there now, but it's good to have input into it.
-rich
If I had something that needed that level of security, rather than sending it over the Internet I would deliver it on an encrypted USB thumbdrive via SneakerNet, plugging it only into computers that are not even connected to a network. Then if the NSA wants your data, they'll have to go to the FISA court for a secret warrant and spirit you away to a black site prison in another country for enhanced interrogation.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Of course the most elaborate setup is always vulnerable to an inside job. The best encryption available is "one time pad" but then you have to securely distribute the pad.
one time pad, while provably secure, is near unworkable in practice. you can just about get away with it if you predistribute a few dvd-r of key material in advance, but then you need to worry about protecting the key material....
ASKER
It's not as simple as that, you have to know what they are talking about, which algo to "ditch", which the WSJ link doesn't say...
http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/
It's the "random" number generator implemented by intel in it's hardware and many others in their software.
My focus is on answering your question rather than all the dumb things the NSA has done. I think there are a few acceptable answers already
There will be no new technique for quite some time, it will only be new algo's or updated keys, or better yet updated PRNG's from someone other than the NSA.
I'm switching the AMD until I hear otherwise :)
-rich
http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/
It's the "random" number generator implemented by intel in it's hardware and many others in their software.
My focus is on answering your question rather than all the dumb things the NSA has done. I think there are a few acceptable answers already
jmcmillan227I don't think that is correct, but it can seem that way at this time.
Sorry but I honestly believe the answer is none.
There will be no new technique for quite some time, it will only be new algo's or updated keys, or better yet updated PRNG's from someone other than the NSA.
I'm switching the AMD until I hear otherwise :)
-rich
@Darr247:
Note that was the exact method that led to David Miranda being held without charge and interrogated for 9 hours while they copied said usb drives....
Note that was the exact method that led to David Miranda being held without charge and interrogated for 9 hours while they copied said usb drives....
That WSJ link's pretty worthless for people who stopped subscribing when Murdoch turned it into an arm of faux newz.
If the guy publishing stories containing information directly from Snowden was my significant other, I would *expect* my electronics and data storage devices to come under scrutiny, and certainly wouldn't have the password for the files written by itself on a piece of paper carried with me.
For passwords, I prefer using something like the MD5 hash of the SHA1 hash and/or RIPEMD160 hash (et cetera) of a word or phrase I memorize.
e.g. to come up with password 7b2531c32074f98609cb3b1272
(i.e. it's the MD5 hash in the 3rd step.)
Even if they go to the trouble of working MD5 (or was it MD4, which has the same length hash?) backwards, which takes longer and longer the more characters there were in the hashed value... what's the next step - work RIPEMD160 backwards, or work SHA1 backwards? (alternately, SHA256 and PANAMA steps, which both have the same length hashes, could be inserted also).
For passwords, I prefer using something like the MD5 hash of the SHA1 hash and/or RIPEMD160 hash (et cetera) of a word or phrase I memorize.
e.g. to come up with password 7b2531c32074f98609cb3b1272
(i.e. it's the MD5 hash in the 3rd step.)Even if they go to the trouble of working MD5 (or was it MD4, which has the same length hash?) backwards, which takes longer and longer the more characters there were in the hashed value... what's the next step - work RIPEMD160 backwards, or work SHA1 backwards? (alternately, SHA256 and PANAMA steps, which both have the same length hashes, could be inserted also).
@Darr247: lots of to-and-fro on that one; no doubt we will learn more after the formal court case starts in October, but probably never know the full story.
Fact still remains though - the UK used extra-legal powers designed to identify potential terrorists, on someone in transit though their airspace (officially he never "landed" as he was still on the other side of the customs barrier) to interrogate them for 9 hours and seize all their possessions explicitly because they expected to find him hand-carrying usb media between the journalists.
Using only physical interchange media is therefore little better than straight data transfer, if they are determined to get access - you clearly need to get the encryption right, and if you do, the medium doesn't matter.
Fact still remains though - the UK used extra-legal powers designed to identify potential terrorists, on someone in transit though their airspace (officially he never "landed" as he was still on the other side of the customs barrier) to interrogate them for 9 hours and seize all their possessions explicitly because they expected to find him hand-carrying usb media between the journalists.
Using only physical interchange media is therefore little better than straight data transfer, if they are determined to get access - you clearly need to get the encryption right, and if you do, the medium doesn't matter.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks guys, id like to close this question, but keep the idea open
According to Snowden Tor’s core security is still intact
http://www.pcworld.com/article/2052149/tor-stands-strong-against-the-nsa-but-your-browser-can-bring-you-down.html
http://www.pcworld.com/article/2052149/tor-stands-strong-against-the-nsa-but-your-browser-can-bring-you-down.html
Unless he doesn't know everything of course. It certainly looks like the takedown of the silk road was due to the owner being an idiot when it came to opsec, but that is the second "onion" site the FBI have hit in the last year, and they did't even have to go to Ireland for this one...
ASKER
yea, so much bad news as of late,
though mcafee says he will make you nsa proof for $100
http://abcnews.go.com/Technology/john-mcafees-product-aims-make-internet-users-virtually/story?id=20424182
though mcafee says he will make you nsa proof for $100
http://abcnews.go.com/Technology/john-mcafees-product-aims-make-internet-users-virtually/story?id=20424182
It has to be end to end, and even then encryption has to be decrypted to read, so it's never going to be 100%. Both ends have to be unwilling to cooperate, which at this stage the Service Providers aren't all that unwilling, even after all of this. McAfee is a crazy nut-bag, god love him, I hope he or someone can make something positive soon.
Per my article on the subject. you can betray or be betrayed by encryption products in many different ways: https://www.experts-exchange.com/Security/Encryption/A_12134-Choosing-the-right-encryption-for-your-needs.html
The weakest link is the way into encryption.
-rich
Per my article on the subject. you can betray or be betrayed by encryption products in many different ways: https://www.experts-exchange.com/Security/Encryption/A_12134-Choosing-the-right-encryption-for-your-needs.html
The weakest link is the way into encryption.
-rich
Sadly, while a jug makes it easy to see if there is a leak due to poor construction, crypto is a lot less likely to warn you until its too late :(