2

I've noticed there's an absurd amount of time, effort and arguments about whether or not we should use certain crypto ciphers or encryption methods.

In this link some people go into how certain ciphers at minimum are required per level of security clearance in the DOD. They go into detail about how each cipher is built to a certain degree of strength for the importance of the information.

The thing is, eventually their recommendations for even touching things like SHA-128 certificates for "low priority items" is going to make them have to go back one day and change out everything once that is declared unsafe. (which the security community knows most people won't)

There is plenty of debate about safety. The thing is though, we have the capacity to come together and agree that certain reasonable methods are stronger than others like when a certain method was openly selected for veracrypt as the safest.

My question

Why are encryption methods when being taught to new admins and engineers in the industry with the approach of:

"From what we have heard about, this list seems okay to use for now. These ones are broken and over there are fine for now but will need to be upgraded in around 4 years from now. There are recommendations that will put you to new levels of security standards but, we'll let the security gurus worry about that for now."

instead of:

"We know you're busy, so this is the strongest practical option we have today. It runs everywhere math works and it's the most solid solution we have come up with. So, use it. Don't consider anything else until the industry has decided there is something better. If you find something using something weaker, improve it. If you can't, move it. Otherwise don't come to us when you're dealing with the consequences of not just locking onto the best option that the security community openly handed you when you decided it was fine to just use something else."

Improve this question
7
  • The simple answer is, it isn't that simple. (The answers to the Quora question, BTW, are, as usual, terrible.) Different algorithms have different qualities suited to different uses and scenarios. They also have different trade-offs, which makes the question of "strongest" both subjective, situational, and in almost all cases difficult to measure with any degree of certainty.
    – Xander
    Sep 1, 2016 at 18:27
  • What would the benefit of using sha128 vs sha256 be?
    – codykochmann
    Sep 1, 2016 at 18:29
  • 2
    I believe you mean SHA-1. The benefits are that it's faster and requires fewer resources to compute, and the output is smaller (though that's only a weak benefit, since the output of SHA-256 can safely be truncated to the same length (160-bits) as SHA-1. In most cases, you wouldn't pick SHA-1 as your hash function of choice today, but at one point it was the most modern option, and the standard, and still has a lot of momentum on its side. Switching an entire ecosystem is hard.
    – Xander
    Sep 1, 2016 at 18:33
  • An opinion isn't hard though. In an age where we're rather good at clustering to the point where we just throw more cores at problems and bandwidth is at the degree that both Netflix and YouTube can exist on the same Internet without bankrupting the companies, why does the security community still feel as though they have to step to the side for performance?
    – codykochmann
    Sep 1, 2016 at 18:37
  • 2
    Only to solve some specific sets of problems. Those are not options for low-power embedded devices, or phones, or commodity routers, or fifteen year old clients, or millions of existing clients outside the systems control, or backwards compatibility, or, or be honest, most of the other considerations that need to be made when implementing a cryptosystem.
    – Xander
    Sep 1, 2016 at 18:44

3 Answers 3

Reset to default
3

The simple answer is, it isn't that simple.

There a number of reasons for this.

First, let's address the notion of:

"What is not broken, instead of what is possible?"

Outside of information theoretically secure algorithms, all algorithms fall under the category of "isn't broken yet" for some notion of semantic security. This includes entire classes of systems that we don't have (in use today) good quantum resistant replacements for, like asymmetric algorithms for digital signatures and key exchange in TLS. Not that quantum resistant algorithms for problems like key exchange and signatures don't exist...We just haven't figure out how if we can use them practically yet, and in cases even done enough research to be sure they're actually reasonably secure. So "what is possible" is more academic than practical, even in the world of hyper-scale systems.

On that note, performance. Even in the world of hyper-scale systems, performance is critical, even to the largest players. Google, for one, is constantly looking for ways to shave milliseconds and increase the number of concurrent sessions they can serve, and they (and everyone else) has to be concerned not only with their own servers but with the hardware the client has on the other end, which may be a modern laptop, or a 15-year old low-end desktop, or a smart-phone, or an eight-year old feature phone with a basic web browser, or for non-web systems, a low-power embedded device, or a smartcard with almost no computing resources at all.

On that note, compatibility. Even in the most up-to-date modern x64 processors and software can easily handle any algorithm thrown at them, as Matija noted in another answer you can implement algorithms in a cryptosystem that can't be understood by consumers of those systems.

Additional considerations pointed out by SEJPM in a comment is certification, and politics. Some systems implementers don't even have a choice in algorithms. A FIPS-certified system, for instance, can only implement FIPS alogithms. And not just any implementation of those algorithms will do..The implementation itself needs to be FIPS-certified. Many US government systems have this requirement. Russian systems, on the other hand, may be required to implement their own standard algorithm, GOST. So even in senarios where better algorithms exists (and for FIPS, this is a reality, not a theoretical) they aren't an option for regulatory reasons.

To deal with all of these issues, we have a variety of options, and all of those options come with various benefits and drawbacks, and for a specific use we have to consider carefully the trade-offs which make choosing the "most secure" option subjective, and often impossible to measure without resorting to individual opinion on the impact of those trade-offs. And, as we've seen, due to performance and compatibility requirements, security itself is a valid trade-off to make in order to produce an entire system that works nominally optimally well.

Improve this answer
6
  • This was an excellent answer. I do have one question for it though. What about the companies who don't care nearly as much? Google might care a lot about performance but they also have an insanely large budget for growing securely. This minimal security model works perfectly in balance with Googles but what about the companies who if we're lucky will only bring in a security specialist once?
    – codykochmann
    Sep 1, 2016 at 19:57
  • 1
    @codykochmann Generally, probably this: Cryptographic Right Answers. I don't always agree with Thomas, but for most common scenarios his suggestions resolve down to "Use Nacl" and this is probably the best and most secure way to implement crypto for most folks, for most uses, most of the time.
    – Xander
    Sep 1, 2016 at 20:02
  • why isn't this a universal expectation for new services?
    – codykochmann
    Sep 1, 2016 at 20:06
  • @codykochmann Well, because most folks, for most uses, most of the time is ultimately only a small subset of all folks, for all uses, all of the time. And even at that, we generally don't get a lot of insight into what companies are doing to even know.
    – Xander
    Sep 1, 2016 at 20:09
  • 1
    Don't forget that speed and security aren't the only concerns. Politics, certifications and compliance also play a major role. For example you'll find many "non-standard" algorithms in countries which don't trust the standard ones (look at SEED and Camellia) here. This is mainly for political reasons ("don't trust dem 'muricans!"). Alternatively some governments have classified algorithms which are only implemented in tamper-resistant HW. These are required from you if you want to sell certain equipment to some governments (ref: Libelle and Suite A).
    – SEJPM
    Sep 1, 2016 at 21:32
1

In short, compatibility. Sure, you can select only the most secure ciphers in only the newest TLS and be secure for a longer period od time. However, half of the people on the Internet wouldn't be able to reach you at all then.

It may be fine for you (for example, on servers I use exclusively for myself, I do exactly that). For other uses, losing even a few percents of the customers (like those still using unsupported Windows XP for example) is unacceptable, and supporting a weaker ciphers for some more time is solution to use, even if it more work.

Improve this answer
7
  • Backwards compatibility was never a part of evolution's design. When you move forward, there is always something left behind. Companies that live off of the past inherently are going to be less secure. That doesn't mean practices moving forward should do the same if it comes at the cost of the increasingly more and more personal data that companies collect falling into the wrong hands.
    – codykochmann
    Sep 1, 2016 at 19:32
  • @xander well, we can never prove that something is really secure, we can only (sometimes) find out that some things were not as secure as we previously thought... But that was not a question here, I think... As for asymetric crypto resilient to quantum computers, there are ways, see en.wikipedia.org/wiki/Post-quantum_cryptography
    – Matija Nalis
    Sep 1, 2016 at 19:32
  • even if it is breakable, even just theoretically, if it's the best that we can offer cryptographically then it should still be the thing we decide to recommend
    – codykochmann
    Sep 1, 2016 at 19:37
  • @codykochman was it not? If you had mutation that for example double your strenth (positive trait), but could not procreate with others of your race (which is compatibility issue), your evolutionary path most often ends right there. Same as with crypto - super secure online bank to which almost no customer can connect (as their own computers don't have advanced enough software) will probably have much less chances to survive than the one that allows RC4 and SHA1. But as I said, everybody is free to run their business as they think best.
    – Matija Nalis
    Sep 1, 2016 at 19:41
  • @MatijaNalis Moved my comment into an answer, since I had more to say on the subject. :-)
    – Xander
    Sep 1, 2016 at 19:45
1

I get the impression that you haven't internalized these principles:

  1. Security is about risk vs. cost tradeoffs—and these tradeoffs vary between users and applications.
  2. A security system is no stronger than its weakest link—and outdated crypto often is not the weakest link.

To use an example others mentioned, if an online retailer tightens down your public HTTPS server's accepted cipher suites, they'll forego revenue from customers who use outdated software. There's a judgement call to be made here.

Another consideration: upgrading old software to use new cryptography is costly and error prone, and competes for resources with other enhancements. And #2 tells us that some of these competing enhancements may well be fixes to security bugs that are higher risk than the outdated but unbroken crypto.

But note that it is standard practice to recommend that new projects always use the best recommended crypto available at the time they start. For example, cryptographers today generally tell people to use SHA-2 in all new projects, not SHA-1.

Improve this answer
1
  • Don't take the brevity of my question too seriously, I more ask in the perspective of trying to back up for a second and ask why we even have these debates about whether or not we should use old ciphers in the first place since it exposes new developers to conversations where they'll for example hear that "sha1 is fine, people are just being careful". I heard that myself a week ago and knew that there's gonna be at least one who sees that as a quick option and decides that is what they'll take since someone they listen to mentioned that it was fine, thus adding more fuel to the fire.
    – codykochmann
    Sep 1, 2016 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .