Schneier on Security

ab praeceptis • May 31, 2017 8:48 PM

Thoth, Clive Robinson, call girl (et al)

I see two main aspects re. nist and djb.

• there are different groups such as academia, mist/nsa/…, large corps and gov’ments, and us, the security people (keep in mind that our perspective can be quite different from the one of cryptologists).

djb and his colleagues, being in academia, are in one way or another (as professioals) living and working with a construct called academia which is certainly not “free” and which is in a major part financed by state and large corp money.
Moreover the major driving – and paying – forces in the field are again states/agencies and large corp.

Which leads to a simple and tough situation: At least you don’t attack them (in a professional capacity) and if you want your work to continue (being financed) and accepted you will be pretty much bound to look halfway neutral.

Furthermore we all know that something withouth nist/fips/eal/etc stamp won’t be accepted by state agencies and large corps.

We security people are mainly interested in the net result (“security”) plus being mistrusting is part of our healthy professional attitude. A cryptologist, however, usually is mainly a mathematician and academician. Both his definition and measure for security often is quite different from ours (e.g. attacks being of no less complexity than brute force).

It is hence much less strange for a cryptologist to use nist as an example for a “neutral” and widely accepted third party (also with access to considerable computing resources) than it seem for us.

In other words: When we judge (as I among others did) we naturally do that from our perspective and the result is pretty much bound to be a clear “nist? No!”.

If we, however, want to judge someone like djb then we must apply the norms and usances of his field!

Another aspect – that is more important for us anyway – when asking “can we still trust djb (or Bruce Schneier, or …)?” is that we do not even need to trust them a lot. a) we ourselves can examine the result of their work, the algorithms and b) quite commonly their own colleagues rigorously examine each others work.

So, as far as I’m concerned: No, no golden sticker for Chacha, 25519, etc. I do trust those algorithms with good reasons (and btw. I also trust djb and based on solid grounds).

I suggest to not boil down and reduce that paper to “nist” but to study it. Many years of experience tell me that a djb/Lange paper shouldn’t be ignored.

I found call girls thoughts and remarks interesting. I myself also don’t expect quantum computers (not 4 qubits experiments but actually useable systems) anytime soon. In fact, I would not even bet more than a pizza on quantum computing anyway for diverse reasons, some of which call girl also mentioned.

However: As security people we must assume the worst.about half a century of “don’t worry, that won’t be a problem” premises have brought us into the ugly situation we’re in now. So, again: Let us assume the worst case scenario, maybe quantum computers, maybe aliens landing, may who knows what.

Which leads me back to djb’s paper. Forget that (from our perspective) unhealthy “nist” remark and let’s look at the beef.

PK still pretty much means algorithms based either on the factorization or its cousin the log. reduction (for ECC). Now, make a little – and frightening – jump in your minds: If djb and colleagues have found some non-pq Shor competitor then we must assume that nsa/ghcq and accomplices have that, too.

djb just went the big step to the conclusion, namely: So, we have to assume that rsa 4K isn’t good enough anymore. But how far do we want to go? Is 8k good enough? 128k?
That seems pretty much akin to how much time will ever bigger rsa buy us?

From what I see djb asks the right question in driving it to the point of assuming that sooner or later we will be at the point that we currently label as “pq” (post-quantum). We must understand that quantum-computing in a way is just the only known realistic looking incarnation of a problem that, as djb demonstrates, may well find other incarnations, some of which, btw. will evolve out of nsa’s ever rising computing power obsession.

I also found call girls thoughts interesting as they tough a major real boundary for nsa: energy and the related factors (e.g. cooling). We should understand that that means no less than that some major leap in quite different fields (such as cooling live silicon, for instance) might create the situation, the threat that we currently paint and imagine as “quantum computing”.

In other words: It is not quantum computing that is threatening us at the horizon. QC, again, is but one incarnation of the real problem, the monster behind it: Massivley increased computing power, no matter how (and in the wrong hands -> nsa and accomplices).

pq-secure crypto must be an urgent target and I agree with djb that it’s not anymore good enough to step from 512 to 1k to 2k to 4k rsa. We must prepare for the monster because it will come. If that happens in the QC incarnation or in another one is not the relevant factor. But QC is what we always had in mind as image of the monster and it serves the purpose well.

And please, let us also learn to be humble as scientists and engineers! Not only because djb’s paper is humbling but also because arrogance and ignorance have led us to where we are. Let us be humble and let us be mistrusting. Both, in my minds eye, are sine qua nons for good security people.

ab praeceptis • June 1, 2017 6:06 PM

Clive Robinson

I get your point but I’ve lost my believe in mitigation (although one might argue that looking at the current state usually all we do comes down to mitigation). Moreover mitigation by definition is not the best solution; after all mitigation implies that something went wrong in the first place.

But what really triggered this response was the link to the imperial violet article.

What he describes there is sad on multiple levels (one of which is his own view). Pretty much everything there is rotten and mistaken and actually describing the sad state of things and why we came there in the first place.

Example: “protocols should be extensible” – uhum. Because the holy sea of google or some mistaken professors said so? Looking at that statement from a practical perspective we quickly see what’s the real driving force behind it: Something like “We quite never get it right so let’s design crap at least in a way that allows for new crap versions”.

And besides it’s logically questionable. What is a new version? Actually – and more healthily – we can decribe a new version as a new “product” that happens to reuse some work and some interfaces from another “product” (that happens to be called ‘the old version'”
But there’s more …

What is that thing called protocol? And how is it different from the interface? To make it short, everything gets mixed up – which again explains why we have the whole problem in the first place.
When he brought up tls as an example I wondered whether I should sarcastically smirk or whether I should be saddened and cry.

Let’s look somewhat deeper: There is a plethora (OK, a small one, but still) of “AES extension” algorithms. A considerable part of the aead candidates, for instance, either extend aes or (more or less slightly) change an aes phase or at least reuse major parts of aes. Some even spell out their reasoning clearly: it’s proven to work, very extensively examined, and brings along a solid security reduction and so, hardly surpringly, quite some of the candidates quote aes’ security reduction …

How does that work? And how does it work that we have aes 128 and 256 and, if needed, can create a 512 bit “extension”, too? Obviously the answer is that the cryptologists (had to and) did work professionally and methodically – very much unlike the tls weirdos and their (not so) funny friends at google and elsewhere.

To make the whole game funnier quite some tls users didn’t care a rats a** about the “protocol” anyway and, as he correctly describes, for instance just took version or protocol not supported as an error rather than to fall back/chose an available one.

That is the situation and I very strongly doubt that the google, mozilla, apache, and other people who drove us deep into that crap zoo will be able (or even honestly willing) to drive us back out. Frankly, I don’t see much more than wild arm waving, some good will theater, and a major dose of ignorance and incompetence, of course.

In case you want an example for “wild arm waving, some good will theater, and a major dose of ignorance and incompetence”:

They now formally verify the protocol safety. Wow. Even with a reasonable tool (proverif). There’s just a tiny but very ugly problem: Unless one very well understands the problem field a proverif “All is OK!” is all but worthless. Why? Example: proverif (and other spi-calculus/horn clause based tools) doesn’t verify much of what one states; it merely cares about the protocol and runs a yolev-dao attacker against it (by default a mildly friendly one btw).
Now, well noted, proverif is a fine tool and I’m pleased to see tls 1.3 being tested with it. But there is this ugly problem …

When you introduce a hash function (“fun hash/1.”) proverif does not know nor care what that function does! To offer a brutal example, if hash/1 happened to be a function that simply adds 3 to its parameter proverif would be quite happy. Similarly it simply assumes that any function with one private (“secret”) parameter returns a private/secret result.

As I said, it’s a protocol verifier. A very useful one, a proven to be solid one, and one that offers the comfort to run worst case attackers against your protocol (if you explicitely ask it to); it’s just that that kind of tool doesn’t care about your functions and assumes them to be good and proper.

That means that I could prove a protocol using md5 hashes and a PK algorithm that simply mod 32 multiplies two 32 bit integers to be secure (if only the protocol itself is secure)!

In other words: by itself those tools prove basically nothing of worth. Only as a part of a good tool chain they are worthwhile and valuable. In particular the building blocks (like key and hash functions) must be properly specified, implemented and verified (both algorithm and implementation) to offer a solid tls.

We always scold openssl (and rightfully so) but the infestation goes way deeper.