Live data from Hacker News

The Cryptographic Doom Principle

thoughtcrime.org

121–130 of 140 posts

Re: The Cryptographic Doom Principle

#121
post #94

If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.

How far should we take that maxim? It implies that no one should ever attempt this, but that leads to nothing new (unless you are first recognised as a crypto guru -- but how could you become one?).

I think it's worth drawing a distinction between the algos/maths and attempts at implementations. Otherwise we wouldn't have things like OCaml-TLS and others.

http://openmirage.org/blog/introducing-ocaml-tls

Re: The Cryptographic Doom Principle

#122
post #116
post #94

If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.

Schneier's Law comes to mind "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." https://www.schneier.com/blog/archives/2011/04/schneiers_law...

Oh, that's what that is!

I had found a similar thing making my own puzzles, "It's easy to make a puzzle you can't solve, but it's hard to make a puzzle that's fun."

Well, that' not entirely the same thing, but they overlap I guess.

Re: The Cryptographic Doom Principle

#123
post #35

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless. --EDIT-- I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow…

> culture of elitism

Reality is elitist. You either know how to do things or you don't, and if you don't, you fail. Sometimes you fail anyway. That's elitism.

Re: The Cryptographic Doom Principle

#124
post #93
post #17

Earlier quoted context omitted.

I think cascading ciphers might be a good idea, but if you're following Kerckhoff's rule, if your system achieves significant use and there is a cryptographic weakness, you should assume an adversary will exploit it even if it's different from the weaknesses of other systems. I guess there's an economic argument to be made that millions or billions of pairs of communicating parties could develop their own individual…

I'm well aware that it doesn't stop a devoted attacker. But it needs a devoted attacker. That is the import point which you also recognized (beside many others). Even a devoted attacker has it harder because cracking a code with known algorithm and unknown key is easier than cracking a code with unknown algorithm and unknown key. Even more if the unknown algorithm is not available. I think your argument that the effo…

Just to put the issue in an extreme perspective, suppose that the best mathematically possible attacks against AES-256 in some setting only reduce the attacker's work by the same factor as the best mathematically possible attacks against AES-128. (There's no proof of this now, but it's conceivable that it's true.) In that case, the decision to use AES-256 in a particular application instead of AES-128 improves security against cryptanalysis of AES by a factor of 2¹²⁸ steps for the attacker. (Maybe cryptanalysis of AES isn't actually the weak point anyway, but let's set that aside because that's what inventing new ciphers tries to address.)

If this hypothesis is true, the work that Daemen and Rijmen did to invent AES-256 and the work that a particular implementer did to implement it will produce an almost inconceivably vast security benefit against this particular threat.

The reason this is important is the kind of disproportionality between the effort of Daemen and Rijmen and the AES reviewers and implementers, and the magnitude of the resulting security benefit. They might have spent a total of 500 person-years on making AES-256 work well, and received a security improvement of 340 trillion trillion trillion trillion-fold relative to whatever the security of AES-128 is. Whereas a homegrown cipher that isn't very mathematically sound might be developed with 1 person-year of effort and end up make an attacker do, let's say, 100 trillion operations. In my hypothesis, Daemen and Rijmen and other folks then got somewhere between a trillion trillion trillion and a trillion trillion trillion trillion trillion trillion trillion times better security return on their effort.

Now you might reasonably point out that if you use a standard, known cipher, the attacker's costs for a direct brute force attack are purely computational and don't involve research and development, or attempting to suborn or hack your correspondents or colleagues to discover the principles of operation or your system. Whereas if you do have a homegrown mechanism in play, an attacker incurs these other kinds of novel and sort of one-off costs, notably including making other human beings think about stuff more.

The point that I've taken from a lot of the security experts who've talked about this, though, is that the scaling benefits are the important factor here, again especially if you want to make a system that many people could use for a long time. When the limiting factor is computer time, which is really only likely to be true for systems created, refined, and reviewed by experts, you can sometimes get the really absurd security ratios that are hard to even think about, and require your adversary to spend more money than exists in the world, build more computers than can be made from all the silicon on Earth, consume more energy than the Sun outputs, etc., etc. When the limiting factor is human reasoning, you might say "but that would require human cryptographers to think about my system for 1 year!". But if that's so, that may actually happen, and in any case you can't easily get the order of magnitude of the costs and resources required up to "inhuman" levels.

The point I'd take from your idea is that it could be valuable to try to make adversaries incur diverse costs in attacking your system, especially if you don't know what capabilities and resources your adversaries do and don't have. This is kind of akin to what's happened with key derivation, where people have proposed KDFs that are very CPU-intensive and also KDFs that are very memory-intensive, and if there are other sorts of resources that you could make an attacker burn, there are probably people trying to invent KDFs that burn those, too. It's not clear to me that there's a genuinely scalable way to require human analytical effort as one of those resources, but if there is, that could be a useful property for communications systems to have for defense in depth. But making up a new cipher by hand for every system is probably not going to provide that property very reliably, or be a very effective use of resources, again when other uses of resources can improve security to a staggering extent.

Re: The Cryptographic Doom Principle

#125
post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

What constitutes a "top expert"? I'd want the people writing cryptography software to have made mistakes and learned from them. That's how the software gets better, no? Of course, there's a theoretical minimum to be familiar with.

Re: The Cryptographic Doom Principle

#126
post #73

Earlier quoted context omitted.

> You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site. You'd probably be right on any other site; but I'm guessing there are a few people who do this for a living somewhere on HN.

> there are a few people who do this for a living somewhere on HN. And Daeken would still be right. You skipped over daeken's point , which would stand on HN or crypto.stackexchange.com where there are undoubtedly people more qualified to talk about crypto than HN. Crypto is impossible to know if you got it right. Read that again. It's impossible to know that you got it right. If you get it really wrong it'll be obvi…

> Even RSA which has stood the test of time since 1977, is only considered 'safe' in so far as there's no algorithm better than brute force for factoring products of large primes

https://en.wikipedia.org/wiki/General_number_field_sieve but most of your point still stands. RSA is edging slowly closer to the abyss.

Re: The Cryptographic Doom Principle

#127
post #69
post #54

Earlier quoted context omitted.

Technically correct is usually the least useful kind of correct. The root of this thread is extremely sound advice. Don't touch your own crypto unless you're an expert. If you're at the point where your security requirements are so sensitive that you can't possibly risk a break in an underlying well-known cipher, you should hire a real cryptographer and not dick around with inventing your own laughably-broken ciphers…

So I think it comes down to whether the root > I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. is a sound advice. I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert. Furthermore, I described a relatively simple protocol that monotonically increases the secu…

I described a relatively simple protocol that monotonically increases the security of a communication

Careful. Encryption is decryption, remember. Do any of the rounds of CC undo any of the rounds of KC? Can you verify that bits that were correlated in PT and uncorrelated in KC are still uncorrelated in KC + CC? Does CC change the entropy content of the resulting message? (If it decreases it you have a problem, and most popular ciphers end up with damn near 8 bits per byte in the ciphertext.)

Re: The Cryptographic Doom Principle

#128
post #5

Earlier quoted context omitted.

That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.

I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my…

I need to see a citation for this

You're looking at it the wrong way. You need to demonstrate for yourself that nothing in your cipher undoes the last round of the underlying cipher.

Re: The Cryptographic Doom Principle

#129
post #80

Earlier quoted context omitted.

And it has the added benefit from the NSA's point of view that your connection/data is precisely fingerprinted as 'homebrew-crypto-1629: refer to analysis cell 2865JQ'. Then the computer is sub basement 19 goes 'ding!' and sends an automated SWAT team to your house.

To fingerprint the connection/data by the used cipher they would need to break KC. If they are able to break KC they can fingerprint you also when you only use KC.

You have said multiple times that the outer wrapper was CC, and the offline, inner wrapper was KC. All they need to do is infer it is CC output, either through online attacks, anomalies in its statistical distribution, block size, etc. Also, certain modes like ECB have watermarking attacks, which inherently reveal that ECB was used.

RC4 is a common stream encryption which can definitely be detected. In contrast AES seems much harder.

It is called a Distinguishing attack. See: https://eprint.iacr.org/2013/176.pdf http://www.security.iitk.ac.in/hack.in/2009/repository/bimal... http://elligator.cr.yp.to/elligator-20130828.pdf http://cr.yp.to/streamciphers/mag/053.pdf http://christina-boura.info/sites/default/files/KeyDifferenc...

Re: The Cryptographic Doom Principle

#130
post #92
post #70

Earlier quoted context omitted.

Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.

That seems ridiculous for 2 reasons. First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. Second, if you're assuming the NSA seriously has the capabilit…

First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it.

You can tell mode somewhat reliably (I've hit 75% confidence or so) by the entropy content of the ciphertext, and I've never done a Markov chain longer than a native word so I'd assume that gets better the longer your chain is. I would also assume people much smarter than me have compiled heuristics that are more useful than just determining the mode.

Post reply on HN