Cryptography 'Becoming Less Important,' Adi Shamir Says 250
Trailrunner7 writes "In the current climate of continuous attacks and intrusions by APT crews, government-sponsored groups and others organizations, cryptography is becoming less and less important, one of the fathers of public-key cryptography said Tuesday. Adi Shamir, who helped design the original RSA algorithm, said that security experts should be preparing for a 'post-cryptography' world. 'I definitely believe that cryptography is becoming less important. In effect, even the most secure computer systems in the most isolated locations have been penetrated over the last couple of years by a series of APTs and other advanced attacks,' Shamir said during the Cryptographers' Panel session at the RSA Conference today. 'We should rethink how we protect ourselves. Traditionally we have thought about two lines of defense. The first was to prevent the insertion of the APT with antivirus and other defenses. The second was to detect the activity of the APT once it's there. But recent history has shown us that the APT can survive both of these defenses and operate for several years.""
no (Score:5, Insightful)
APT (Score:5, Insightful)
Would have been nice to define APT...
Re:no (Score:5, Insightful)
Re:no (Score:5, Insightful)
Re:no (Score:5, Insightful)
Slashdotters (including myself) dont hate code signing, they just hate code signing where the owner of the computer does not control what gets signed and what can run.
Re:APT (Score:5, Insightful)
It's doubly annoying because(in PR-flack ass-covering speak) an "Advanced Persistent Threat" is "Any bad guy smarter than our dumbest sysadmin's stupidest mistake".
It might have been a clear category at one point(and there still are attackers who are pretty clearly both advanced and persistent); but the constant "Well, we could say 'gosh, we fucked up, how stupid of us.' or we could say 'It was and Advanced Persistent Threat, total national security shit, probably chinamen or something!'" pressure hasn't helped...
Re:no (Score:5, Insightful)
Re:no (Score:5, Insightful)
Re:The way I do security (Score:5, Insightful)
Re:APT (Score:5, Insightful)
Actually, I know plenty of intelligent people who make mistakes. Almost as many as retards who take pleasure in calling others out.
Translation: (Score:4, Insightful)
Encryption doesn't do shit if they're grabbing it before encryption or after decryption. It's not a magic security bullet. It has its uses, but now it's become easier for Eve to hack Alice and read the plaintext than to intercept and brute-force the ciphertext. And when Alice is talking to not just Bob, but Carol and Dave, well, that makes Alice a high-value target worth spending time on.
Re:no (Score:2, Insightful)
The problem is most owners have no clue how to do code signing, and would rather their equipment/software vendor take care of it.
My car door/ignition lock came from the factory; I have no idea how to fix it if something goes wrong, but that's fine by me, since for more than 10 years it has just worked.
The best encryption is transparent to the user; most people won't notice if a link uses HTTP or HTTPS, a bright red bar might get their attention, but that's about it.
Re:no (Score:3, Insightful)
Its fine for someone else to take care of it. The problem is when you complicate it for those who don't want someone else taking care of it. The reasons it is being done differ from those stated. They are doing it with malicious intent.
Re:The way I do security (Score:4, Insightful)
I think what most of the people responding to this post aren't realizing (or acknowledging) is that your security needs to be appropriate for the data it's protecting.
If we're talking about a corporations backbone, then yeah saying "it's not connected to the internet" isn't acceptable.
If instead we're talking about some John Doe's personal data, then you aren't going to be attacked in the same way. Keeping it on a drive that has no internet access is probably good enough.
Re:no (Score:5, Insightful)
user education should be printed in all caps, bold, underlined, comic sans, etc...
At some point, unless we develop new algorithms that utterly break how current encryption algorithms behave (which I know I know, is a possibility... and of course the NSA has it already)... your weakest point is not going to be the computer. It's going to be the lackey at the front-desk happily letting a "tech" in (physically or electronically)
certificates (Score:4, Insightful)
From TFA
One way to help shore up defenses would be to improve--or replace--the existing certificate authority infrastructure, the panelists said
Indeed. IMO SSL public keys could be stored in DNSsec protected DNS records. That way one would only have to trust the manager of the root zone and the TLD, which would be a good improvement compared to the CA debacle.
Re:no (Score:4, Insightful)
What you're referring to is more often called information security. Cryptography usually just refers to the methods, algorithms, and protocols of transferring data.
But there's little point in arguing the semantics of words. I think we can all agree the human factor plays a large part in almost all intrusions these days.
Re:no (Score:4, Insightful)
I don't give a damn about how secure it is, I could even use crc-32 if the snapshot takes too long. The idea is only to be alerted about unexpected file changes, especially system executable like; top, login, w, etc. but you should look wider.
1) Take periodic checksums
2) Have differences reported
3) If they don't match documented updates you have an intruder.
That's why it is recommended to run the checksum program from a secluded host because the rootkit hopefully won't have had a chance to get at the checksum program on the secluded host. View that host as the ultimate secured host in a good rsync backup strategy, the CA in a good PKI strategy, etc...
It used to be common practice in the old days to take periodic checksums to detect intrusion into systems. Now, with all the fancy IDS solutions around, it seems to be less used but I do not see anything that really replaces it yet.
Re:no (Score:3, Insightful)
Exactly. When the code signing process can not be initiated by the end user should they chose to sign an unsigned executable. It's just asking the vendors of your hardware and OS to establish a monopoly on your user experience by locking out competition.
This current system of all-or-nothing needs to go unless they offer an easy but out of the way means of signing an executable. All the current system does is make dumb users choose the nothing route and forgo all of the transparent benefits of the all route.
Hell stick the signer in a control panel app or similar easy to access location. Restrict it to administrative/root level for usage. That's enough to deter anyone from using it unless it's needed. The process should not be so obscure that you must resort to potentially malicious 3rd party sources just to get started. Especially with all the self-proclaimed experts out there that regularly dish out advice like "disable UAC" instead of pointing out the simple process to give an individual program automatically elevated privileges.
Re:no (Score:0, Insightful)
Yes. In the same way that a gun is a tool for killing, so code signing is a tool for evil.
You are a simple-minded fool.
Killing is not always bad. And guns are efficient tools when killing needs
to be done.
Or maybe you'd rather try to "negotiate" when scum who have invaded your home
are interested in raping your wife and daughter while they make you watch ?
Do you actually believe the police are going to save you in the above scenario ?
That is the sort of fantasy naive children entertain. Adults know better.
Re:no (Score:5, Insightful)
I have a handful of fairly secure passwords. They're reasonably long, are incredibly easy for me to memorize, and don't rely on any details of my life (pets, wife, kids, birthday, etc.). But I have to deal with websites that demand a series of ridiculous standards: some require (thank you, AmEx) a number in the username, some require passwords to have number, capital letter, and symbol. I spent a lot of damned time figuring out a password that people can't guess, and I can't use it because I can't remember the rules for any random website - so I have to get a password reset email sent to me in plaintext. And on top of that, I can't use a password I've used before - so every time I log into a website I rarely use, I have to reset the password to something I will forget in a few days. I'd use something like Keepass but I need to be able to log in from non-home computers.
I do not agree! (Score:5, Insightful)
I was just having a discussion about this at work today. Encryption should be ubiquitous now. There is no excuse. It's not "free" in terms of the resources it takes up, but it's pretty close. Everything should be encrypted in transit. Everything should be encrypted at rest. "Well you mean the table with the PII and not...." NO! I mean EVERYTHING. The servers drive should be encrypted. The entire database should be encrypted. Every network connection should be encrypted.
This doesn't mean encryption is a panacea solution to APTs or to any other security threat, but its an absolutely critical layer which is still not widely implemented enough. To prevent tampering, to prevent certain types of attacks, to prevent breaches through physical theft, etc. Saying encryption isn't as important anymore is like saying that keyboards aren't that important anymore. Sure, management shouldn't spend a lot of time worrying about them, and should be focusing on other problems instead....but that doesn't mean everything will be cool if everyone's keyboard is stolen overnight.
It needs to be there, and by there I mean everywhere. And its not. Every day developers are looking at security guys like, "huh??" because they are looking for encryption to be incorporated into the product. Or, they want to "just get the system built out" without encryption, but they'll totally enable it once everything is working perfectly and all the testing is done (FYI developers, security guys aren't falling for that, we realize that you really mean, 'we'll think about enabling it until we realize how many things it will break, and then we'll ship the product without it, ignoring the enormous liability it creates'). You would think things would be different now that its 2013...they are different, but not that much different. Security still isn't regarded as a core piece, or even an important feature, of most products.
Re:no (Score:4, Insightful)
Actually, a safe is a good analogy. Nobody actually "cracks" a safe any more, in the same way criminals don't gain access to your computer by cracking your crypto. Safes are blown open, battered open, cut open, or subjected to some fancy chemical attack. But modern high-quality combination locks are impervious to the guy with nimble fingers and a stethoscope (which is a Hollywood thing anyway).
Installing a rootkit from an email is roughly analogous to having your safe opened because you put the combination in the top right drawer of the adjacent desk.
Re:no (Score:1, Insightful)
"After they take it from you"
What sort of fatalist defeatist bullshit is this?
Re:I do not agree! (Score:4, Insightful)
I am a proponent for more widescale use of encryption, but I am against braindead application of it as you seem to advocate for. As has been called out time and time again, the application of the encryption is critically important to it fulfilling its role. It's easy to get it so wrong in practice that all you provide your users is a false sense of security that encourages them to put more highly sensitive material than they otherwise would have at risk. Then there are other considerations. Once you bring encryption into the fold on every single aspect of your product, how easy is it to test and debug? Is your time to market now twice as long because you have to develop special QA tools rath than use something off the shelf? Is the data actually sensitive? What are these "tampering" and "certain types of attacks" that this encryption is going to protect against? Do you and your team actually understand what they are? If you don't, how do you know the encryption scheme you're using protects against them? What about export restrictions? Where does your product need to be distributed? Does your encryption help at all if your servers are rooted, since they can presumably decrypt all the data anyway? Is the encryption giving you a false sense of security around your customers data? If everything your product does is encrypted, are your customers going to be happy about their ability to implement compatible products? How can customers trust and validate your product if they can't see how it works?
"Encrypt everything" isn't a very well thought-out plan.
Re:no (Score:5, Insightful)
would you remove all the locks on the doors and windows of your house merely because they couldn't stop aliens from abducting you?
also, window locks are uselss because burglers can simply smash the window
any level of personal security (even the fake security cameras, lasers, etc) is better than none at all
but on the other hand, imposing your ideas of "security" on others is not a good idea (such as the TSA)
people should be free to decide what level of security they think is appropriate for themselves, as long as it doesn't adversely affect others (don't install a nuclear reactor powered ion cannon in your back yard because your neighbors likely won't be very happy having risks from your ideas of security imposed on them)
Re:no (Score:1, Insightful)
Re:I do not agree! (Score:4, Insightful)
The servers drive should be encrypted. The entire database should be encrypted.
Its not so simple. A server requires the drive to be mounted (and therefore decryptable) in order to function. So from the time the server is powered up until the time it is powered down, the file system is vulnerable - for a server that is powered on all the time, this means the window of opportunity for an attacker is huge. It stops a burglar from getting at the data after they unplug the machine and walk off with it, but if your server is in a secure datacentre then this isn't such a big worry - the concern is the server being compromised *while its running* (and as mentioned, servers tend to be running all the time). This could happen either by a remote attack, or by someone physically accessing the machine. So really, for an always-on server there often isn't a lot of point in encrypting it. Add to this that, unless you want to store the encryption key on the server itself (which rather defeats the point), you need to manually load it every time the server boots, which isn't great for failure resilliance.
And especially for I/O heavy servers (frequently the case with big DB servers), encryption is *not* free - it can have a significant performance hit.
There are places where filesystem encyption on servers makes sense - this is where the encrypted filesystems are only mounted for brief periods of time. For example, a server that is performing remote backups of another server can retrieve the key from the machine its backing up, mount the FS, do the backup, unmount the FS and wipe the local copy of the key. The window of opportunity for an attacker is relatively short there (the duration of the backup); although obviously if an attacker can load persistent malware on the machine they can have it capture the key when the backup next starts.
It's a matter of motivation (Score:3, Insightful)
Re:no (Score:4, Insightful)
When i threw him out the shop he was saying "it says its limewire now you make it work!"
These are the people I don't understand. Not because they don't listen to you, that's normal. But what I don't understand is why they would trust you to fix their computer when they don't trust you to tell them what to do with it.