Does anyone actually use public key encryption for legitimate purposes?
rjo__
Posts: 2,114
Or would it be okay to just destroy it now?
By anyone, I mean military/government/financial institutions.
By anyone, I mean military/government/financial institutions.
Comments
(this post looks suspiciously like trolling, by the way....)
I certainly don't want to talk to my bank without HTTPS which uses public key crypto.
Or what about all the other places you buy and sell stuff. And all the other things you do over the net.
In fact I think all websites should be using HTTPS. Like this one for example.
Also I think it's shameful that governments around the world are trying backdoor all this. Thus making the world a lot less safe for all of us.
And what about all that administration of remote machines that is done over SSH. Which uses public key? Do I really want sloppy security on my servers and remote embedded devices?
Example. I have a Raspberry Pi, with attached Propeller, at home accessible from the internet net here. I want that to be secure.
And what about the growing world of IoT gadgets?
Governments have have many and devious ways to stop or enforce all kind of things.
I'm worried that just now they are focusing on busting our security.
Perhaps they cannot destroy HTTPS for example. But there are many other ways to get at what they want. See the current Apple vs USA argument for example.
These are worrying times. We have the "bad" guys one end and the governments working against us on the other.
"How exactly do we destroy it?" +1
What do you really mean @rjo__?
Un-creating or revoking ideas has seldom proven successful. The burning of the Alexandria library is one example of success, possible because of technology limitations. Despite that, some ideas did endure as people aware of them shared them anyway. A lot was lost too. Net loss for humans, if you ask me.
Given our fluid information tech today, I am completely serious when I ask how we actually do destroy an idea.
That said, we can marginalize one, or compete with better ideas.
We can also learn to live with ideas too.
My gut says we will have to learn to live with it, and that will take a few generations.
Expectations will, and are clashing with realities. New ideas are needed, and they will come, but until they do, we will struggle with all of that, often seeking easy outs for what will turn out to be yet another example of the work inherent in the human condition.
We want easy, and we want to know. We get hard, and mere understanding, no real knowing.
That is very hard for people to live with, generally speaking. It takes a long time. As our understanding peels back a new set of potentials, that cycle repeats. We think we know stuff. And when we are reminded we don't, we as humans generally, just don't respond well.
Humans really are a PITA.
Reading between the lines is perfectly acceptable.
It can wait;)
Thanks
What actually are you trying to say?
Do you really mean to say that here should be no way for me to send a message to you that no one else can listen in on, or vice versa?
Edit: Excessive bluntness removed.
I retracted my blunt statement above, because well, it was too blunt.
I guess it's just that I don't get the idea. The web needs, security, we need security, all of us. We certainly don't want it to be weakened or back doored by spies like the NSA and friends.
The issue of previously published information being reclassified seems totally orthogonal to the original question here.
Insertion of a backdoor for government use would be extremely unwise because it would create an attack vector for hackers sponsored by foreign governments to attack the financial system. This would result in things like electronic funds transfer and bill payment being unreliable. Foreign governments hacking corporate entities goes on daily, and most corporations have security teams dedicated to intrusion detection and prevention.
tl;dr This isn't your grandfather's COBOL overnight batch program financial services sector anymore.
don't underestimate COBOL. Still strong in the financial market. But not so grandfather-like as you think. CGI in COBOL works as well as interfacing QT or even Web services via JSON/REST whatever. To get @Heater happy someone even was able to combine Node and COBOL...
I am personally out of the COBOL world since 1994 but had recently some job working with a couple of old work friends moving some code from a IBM 370 to some Linux based system. Went over pretty well, hundreds of programs without much change to the source.
Sometimes I have to agree with @heater and sometimes I don't. HTTPS as standard, even for this forum is more then needed. Why encrypt a public accessible website? Who can gain what by decrypting the content of that stream thru the net if he can access the information by himself anyways?
confused again,
Mike
On the other hand a forum has users. User have user names and passwords. Registering often requires giving your email address and so on.
Those passwords and other potentially sensitive information travels over the net in plain text. Your secret password is not secret at all. Why bother having one then?
One could say "OK, let's use HTTPS to secure registration and login etc, thus making passwords secure, but do everything else in plain text". Well, fine, that is better than nothing. But it turns out that allowing logged in users to access anything without securing the communication with HTTPS leaves them open to all kind of vulnerabilities.
Bottom like is that HTTPS should be used for everything in order to make it water tight.
A quick google search for "Use HTTPS by Default" or some such will turn up a ton of articles on why this is so.
http://www.businessinsider.com/john-mcafee-nsa-back-door-gives-every-us-secret-to-enemies-2016-2?IR=T
http://thehackernews.com/2016/02/china-hacker-malware.html
I am not against encryption. I think it is a vital necessity. My question had to do with public key encryption, which as a first pass at encryption isn't really that bad. I think it would be prudent to add some other layers on top of it... that's all.
As a sole defense, I think it is not adequate. I am actually surprised that major organizations would trust it.
That's why I asked. In retrospect, I guess it sounds like a stupid question or implies something that I didn't mean to imply.
Good responses.
Thanks,
Rich
I'm no security expert but I've been curious about all this for a year or so now. Some random thoughts...
Public key encryption is hardly a "first pass" at encryption. Cyphers, encryption algorithms and the systems to use them have been under development for perhaps thousands of years. Certainly since the second world war (see Enigma and Lorentz machines) and the advent of electronic computers these things have been the subject of a lot of research world wide. What we have today in our browsers and VPNs etc is about the best the human race has come up with so far.
What layers would you like to add? Things like HTTPS already have a ton of layers. Consider...
1) I want to send a message to you that no one else can read. So I encrypt my message with some key and send it. But how do I give you the key? I need to be able to send that in a way that no one can read it as well.
2) Easy. You send me a public key. I encrypt my key with your public key. Then send it. Only you can decrypt my key because you have your private key. Now I can send you encrypted messages and you can read them with my key.
3) We can do this both ways round if we both publish public keys.
4) But how do I know I'm talking to you and not some fake rjo__? Not so easy. Now we get into signing messages with third party keys, certificates ... That has to be a third party we trust of course...As done in HTTPS.
5) But how do you know it's me you are talking to? Typically HTTPS does not help with that, I probably have not paid for the certificates from those trusted third parties to authenticate myself. But if you make me log in with a user name and password then at least you can assume that when I log in I am the same person again.
6) But I don't want to give a user name and password on every reload of your web page. Again HTTPS does not help with that. Enter cookies and JSON Web tokens to maintain a "session".
I guess 5) and 6) are those layers you would like to add. A sure enough web sites using HTTPS have to take care of those layers themselves. User names, passwords, cookies, tokens, sessions.... Serious people like banks will want other means of authenticating you. Like those secret numbers they send you in the post. Traders have your credit card or paypal numbers.
Major organizations put their trust in this stuff because:
a) It's about the best we have, as noted above.
b) Creating your own cyphers and crypo systems is hard. It's unlikely you are going to do a better job. Decades I ago I did some work implementing encryption in military communications systems. It was a lot of work for many people to design, implement and verify over a few years. And those systems were simple and primitive compared to what we have now. All in all it's better to use the well studied and proven systems that many people have been analyzing for years.
Which part is "not adequate" by the way?
As I understand it, many protocols use public key encryption to exchange the keys and then switch to asymmetric encryption for the main data exchange. The idea being that asymmetric encryption is a lot harder to brute-force.
The problem is performance. Shared key algorithms are much faster. So, we use public key at start up to exchange the keys that will subsequently be used for the data transfer.
My other impression is that when securing a session between browser and server the HTTPS is the easy part. Just a few lines of code or a server configuration tweak.
But then there is a ton of other details to take care of to try and make sure things don't get compromised. Most of which seems to involve trying to stop the browser form being able to do insecure things, which for some weird reason seems to be the default specified in the standards. Or making sure that if insecure things do happen you have a defence against it.
See for example the security check list:
https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
After tying to implement a lot of that in a simple demo web app I started to get very nervous and paranoid. How do I know I have not missed anything? How do I know I did not make a mistake? How do I test this? Proving that it is actually secure is pretty much impossible.
See server code here: https://bitbucket.org/zicog/propanel/src/48bcc1adbb4fb9d1ca600cc9895c3c1c67c40c48/server/index.jsx?at=master&fileviewer=file-view-default
And the running thing here: https://xn--2-umb.net
"Which part is "not adequate" by the way?"
Depends upon what is being defended, by whom and against whom.
Against individual hackers... fine. Against major players with serious intentions. I worry.
short answer
The keys:) The primary assumption... just to be a little "cryptic" about it:)
I'll try to say more in a different way ... later.
You guys have the most phenomenal depth.... just incredible.
Thanks again.
Rich
I look forward to hearing more.
As far as I can tell "the keys" are rarely the issue. Sure if you have twinky little short keys they can be brute force attacked. But today we can use such huge keys that it would take a few times longer than the life of the universe to brute force them even if you used all the energy available on the planet to run the computers to do it.
Also it can be the crypto algorithm you are using. Perhaps it has some known weakness that can be exploited. But today we can use algorithms that have been subject to crypto analysis by experts, mathematicians, hackers for years with no known weakness.
Then there are just bugs that creep in. See recent Heart Bleed problems and the like.
What I do read about a lot is that secure communications gets busted by exploiting a flaw in the implementations. Simple mistakes in configuration or use. The first famous examples of this was the busting of the German Enigma and Lorentz machines in WWII. Greatly aided by a single German wireless operator lazily transmitting the same message twice with different keys (or something like that). It's been going on ever since.
Then there is social engineering your way around passwords and such.
Bottom line is that security is not a technology, an algorithm, a hardware, it's a process of eternal vigilance. Having to be aware of who is getting into your system. What are the latest attacks? What are the latest fixes to old bugs? Etc, etc.
Of particular interest "...quantum resistant algorithms..."
Edited to add: Remembered this link "...why did the NSA just freak out and throw its Suite B program down the toilet?" http://blog.cryptographyengineering.com/2015/10/a-riddle-wrapped-in-curve.html
The downside of the one-time pad is distribution of the keying material, but quantum cryptography uses superposition of photons to do it in an unbreakable manner.