Schneier on Security

ab praeceptis • August 22, 2016 1:47 PM

Marcos Malo

I expect but rather insignificant progress.

Above I talked about proper reasoning. Let me give you an example: Humans tend to think in patterns (as opposed to arbitrary series of symbols, number, etc.).

If we ask a human to a) come up with and b) remember any password – which in the end is a string of symbols – he/she will process that in a way that is radically different from a computer. He/she will come up with something that makes sense to him/her, which is another way of saying “pattern based”, while to a computer as password is just a string; to a computer ‘mom_and_dad’ is no different than ‘1$1-&#7-p3p’. Funny sidenote: Humans actually tend to assume the latter to be somehow more secure (because it a) uses symbols not perceived as ‘common’ and b) is a comparatively rare combination (seen from a human))

On the other hand, one of the major potentials to make more powerful cracking stuff is based on an attempt to “recognize” and use patterns, i.e. combinatons of elements of any available set of symbols that are more likely to be “human”. dictionary based attacks are a crude example.
However, that’s important to note, the motivation behind that is merely to enhance statistical hit probability; those “human” symbol combinations promise a higher hit rate.

In the end it’s always those two factors. The purely mathematical factors, i.e. for instance the combinations possible based on a symbol set size (e.g. 23 characters), and probability enhancements.

Way more important, however, – and you address that somewhat – is the human factors.

Let me offer you a striking example:

As most humans dislike (or are hardly capable) to remember more than very few passwords, they create a situation in which cracking any service they use, gives you their access (credentials) to many if not all the service they use.

This is often not seen, but it is a very major factor for crackers, because it translates to “Chose the service that is the most simple to hack and gain access credentials for services you might be unable to hack at all”.

And there is another factor: To a machine it makes virtually no difference whether it stores 2 or 2 billion strings. For a human, however, that is an unsurmountable difference.

So, even if we succeeded to enhance password variety by 100%, the net effect would be virtually insignificant.
Moreover inertia plays a shockingly major role with humans. They dislike to come up with, let alone remember multiple long strings and, to make it worse (in their eyes) to frequently change them.

There is no way around it: Password based security, particularly through wires, comes down to symbol set cardinality (alphabet size) and password length. Even “random” passwords vs. “human” passwords (-> dict. attack) isn’t a major factor but rather a modest enhancement.

Which means: long passwords out of large symbol sets -> which directly translates to “forget it. Won’t work with humans” (except, of course certain rather exotic settings where that can be rudely enforced (opening security gaps)).

It comes down to a classical man vs machine problem. The solution is to use a machine for assistance on the humans side (as I roughly drew earlier).

In other words: a) have high quality passwords and b) keep the human out of the loop for the most part.

ab praeceptis • August 22, 2016 2:48 PM

Gerard van Vooren

It wasn’t about the mental model. It’s about a standard of many, many hundred pages. That leads to a situation where a language might theoretically allow for safe highly reliable programs but being practically no less a bug generator than, say C++.

“Modula and Capitals” – that is an editor problem, not a language Problem. Though, to be fair, the very raison d’etre of the capitals almost doesn’t exist anymore nowadays with syntax highlighters. But begin/end rather than curly braces really is but between a minor annoyance and an editor problem.

As for the operators (I did crypto in Modula-3) the issue isn’t so much one of ^over ‘XOR’ but it gets quickly annoying and disturbing the flow to write ‘XOR(a, b)’ rather than ‘a ^ b’ or at least ‘a XOR b’. And it gets much worse with nested bin. operations.

What was really the showstopper is that the (currently only “major”) implementation of Modula-3 has no true cardinals! Incredible. Just try crypto with cardinals that magically turn into (signed) integers whenever the MSB is 1…

More generally speaking I see a problem in that Wirth in a way went the opposite direction of (most mostly us-american) language designers; where the latter usually cared little about scientific principles and soundness but rather went “hands on” for pragmatic use (which does have its own advantages) Wirth seems to have been largely ignorant of pragmatic issues. He did, however very much care about simplicity, purity and elegance which happen to be existential for a good and safe language.
Sad sidenote: Modula-3 was one of the very few languages (I think even the only one for a long time) which had a formally specified and verified standard lib. Unfortunately Larch (the system used) has been all but forgotten and shelved it seems.

But anyway, if tomorrow I had millions thrown at me and at the same time a revolver at and a calendar near to my head to create a reliable and sound language for safe programming I’d base it on Modula-3 and I would change precious little and very carefully and respectfully. Meyers DbC would be the single major add on that would strike my mind right away. And maybe, but that would require more time, a good interface to formal spec. and verification. And, of course, but that’s nothing in terms of workload, I’d introduce Adas ‘–‘ comments (and multiline and doc variantions thereof).

ab praeceptis • August 23, 2016 9:17 AM

@Thoth

I was talking about the 66 series.

Sidenote (without having any depth re. smartcards): Surprisingly much crypto uses surprisingly few operation types over and over again. If you know the math good enough and if you know enough about the chip (e.g. instruction set incl. hw ops) I’d see some light at the end of the tunnel. It might be doable and useful to use those hw capabilities, no matter whether they’re called “des accel” or “aes accel” or “rsa accel”, as hardly any (to my knowledge) do, say, rsa, magically in an rsa op; they “merely” offer hw accel for some ops that are typically heavily used and hence worthy of accel.

@Figureitout

Sidenote/hint (ad “muon detector”): driving a simple cheap zener diode within a certain range will do the trick, too.

@Clive Robinson

Yes and no. MULs and DIVs (which MOD usually is in disguise) are among the most expensive ops on pretty any architecture. Going ASM rather than, say C, doesn’t cut out much there. Plus: Unless one knows a given system very well (and ASM development, of course), chances are that a decent compilers backend developer(s) is/are someone who know that Arch. very well. In other words: For the vast majority of java, C, etc. developers, chances are that them doing crypto in ASM will actually create slower code.
On the other hand you are right insofar, as only tight control over code, allocation, etc. provide the necessary means to get a grip on timing issues and other sidechannel beasts. Which quite certainly i at least one of the reasons for djb to create hs own intermediate language/representation.

If the chip designers did their job well, using the hw accels will even get you some sidechannel protection, too.

Gist: ‘Don’t think twice but twice to the cube before going to “making it faster/better/more secure” yourself’ is a piece very solid advice to all but very very few.

“Unfortunatly we are moving out of the land of 8 and even 32bit processors in all but the likes of smart cards and low power embedded systems when it comes to data communication.”

The world looks quite different in an industry shop floor than in a university office.

ab praeceptis • August 23, 2016 5:09 PM

Nick P

I’m not surprised by that answer. But the real world is quite different from a sofa with 1.000 papers around it. You can and do provide lists upon lists of projects and at times that’s useful. However: How much code have you produced in, say, Mercury (which you mention)? Have you searched for and finally hacked yourself syntax highlighting for your favourite editor? Have you used and tested the seemingly nitty gritty details which, however, can make ones day miserable? Have you created bindings for C libraries with it? Have you also analyzed what Mercurys weaknesses are?

HOL, for example. is a PITA for developers to work with – and that’s why very, very few do. Don’t get me wrong, HOL is a fine tool for some things, but there is a reason why programmers rarely touch it. btw, most not only don’t ever touch compcert (a fine verified compiler) but actually even hardly heard of it.

Another example: The creator of TLA went the distance to create TLA+, a “much friendlier” incarnation; and while he mentions some major corps. as reference, it’s rarely used out there in the wild. If you are Amazon you can afford to get a lecture and support (and the prof will gladly hurry to your HQ); unfortunately, very few of us are Amazon.

Part of that problem is that software developers are educated (and practically forced to) think in terms of language and compiler. It goes even further: There is a language standard and there is what ones compiler accepts. Guess which one is binding for most programmers.

As for across the ocean and europe, my point isn’t that across the ocean they are stupid and have no culture (no matter whether true or false; it’s imply not my point). My point is the significance of proper reasoning and a solid foundation (where europe happens to be in a much better position. If it were the lila-lulu polynesian islands I’d say the same). Actually, I’m expecting quite a lot from Russia in the next decade; reason: excellent education, rigorous adademia, solid cultural and intellectual foundation. I’d even go so far as seeing Russia as the “new europe” because we (west)europeans have lost very much and have reached a very sad academic state, except maybe france and, to a limited degree the uk.
The Russians seem to have well kept (over a long winter) what across the ocean hardly exists and what we (west)europeans stupidly and arrogantly let go.

You fail to see factors not to your taste (or experience or self-view or …). To give some examples:

The decisive factor sadly often is not the quality of a concept (or language) but the “market”. If large corps. push sht then sht is the wid spread normal. Had Ichbiah created Ada as an academic experiment or for a portuguese government agency, it would be dead by now and but a few experts would have heard of it. But he created it for the dod and so it had weight and clout.

Or look at Pascal. Hardly anyone would know about it, let alone use it, if Kahn/borland didn’t market and push it (and at an affordable price at that, which probably was the decisive factor for its success).

Another issue you underestimate or judge wrong (imo) is when you name all the projects done across the ocean. So, does the fact, that a given country has a massive community in pharmaceutical research indicate that its population is healthy?

Many of the projects you seem to see as a wunderful example of ingenuity (which is a valid way to see them but not the only valid one) can as well be looked at as late insight after fu**ing up big time.

But in that fat argument block of yours is a hidden very major factor, namely when you mention ISAs. Why? Well, there has been am (understandable) tendency for languages to go along with cpus. As someone so aptly and funnily put it: “At those times we considered a language something to come with a new architecture or processor”. In fact, C, or more precisely, its ancestors came into existence for that very reason! While a new hw architecture (or a significantly evolved or changed one) was worked on, a new language for that arch. was also worked on.

So, in a way you answer the question why there were/are so many projects across the ocean. In the end: Because IT was widely their technology (and to a large degree still is).

But that was not my point. My point was how to create safe and reliable software from the beginning (rather than starting many projects to cure problems that should have been avoided in the first place).

Extracting it brutally down we arrive at: There is but us and mathematics and proper reasoning (at the other end, let’s not forget about that, there are exploding rockets and humans killed by radioactive poisoning … or maybe soon a hijacked and melted down nuclear reactor).

That also explains why I’m somewhat hard on you and the 1.000 papers.

So, to get back: we have us, humans, and we have mathematics and proper reasoning. That is what it boils down to – and that is what we must build on. To do that, we need tolls – and, very important, a healthy perspective and understanding of our field of profession.

And, if I may remind ourselves, albeit somewhat bluntly: That’s what makes us engineers rather than hobbyist. It’s about time to understand – and to understand as non-negotiable and as binding, as the law of our profession – that software must be built no less carefull and no less professional than bridges or airplanes.

As long as this is not the accepted and implemented professional standard we may enjoy fumbling but we’ll have to worry about this weeks 10 mio stolen passwords or, sooner or later, about a hijacked nuclear reactor.

ab praeceptis • August 23, 2016 7:21 PM

@ Clive Robinson

You are right. But hl languages that do support inline asm aren’t that rare anymore; moreover one can always link in asm routines.

The point I was focussing, however, was a different one, but maybe I misunderstood Thoth. I was under the impression that the assumption ASM is faster than, say, C is not necessarily correct per se. I did quite some ASM stuff myself but then, when I did that, it did make sense to even quickly glance over any C compiler output (todays compilers are dimensionally better).

Just recently I had to “print” (no really, but it’s good enough as explanation) some numbers in a very time sensitive aio network context and sprintf just didn’t cut it; it was way too slow. So I did my own and evidently divide-by-10 was an ugly spot. After handcrafting some SHL, ADD, then SHL ASM I got curious (way too late) and looked what the C compiler made out of a stupid / 10. Surprise (on my side): It knew and used the same algorithm.

That’s why I warned that most programmers will usually be better served just sticking to their language. But again, for things like flags, your are of course right.

@ Ni (we are saving bits, right?)

“You also re-iterated a prejudicial statement about Europe’s superiority in this field.”

If I may offer a piece of advice: Don’t allow emotions to take over in an intellectual discourse. I did not say that. I talked about the foundation, not about the tools or the quantity thereof.

” All I need is those papers,” … [a while later] … ” TLA+” … ” model-checker to help people with less time or talent. … follow the guidance on its website. Or … book. ”

The 1.000 papers effect again. Reality: TLA+, at least for a while, simply didn’t work on linux, another version did, but didn’t on Windows. Was, it seemed, to do with some java idiosynkrasy.

Which leads to another point: A verifier, model checker, or similar in java. In java! Of course, in academia they love antlr and it’s certainly no coincidence that since antlr got popular, a whole slew of tools (usually created in academia) are built in java. I’ve learned from bloody experience to stay away from them, although, from time to time, I curious (and stupid) enough to try again (as I did with TLA+).
In fact, it was only later that I tried to reason about that and to find out why a whole class of tools has a strong tendency to not deserve my trust or to be in my toolbox.

Sir, it seems to me that you never used TLA+. But you know papers and books about it. You might want to seriously consider to have no less respect for actual engineers than you expect from them.
Again, you are evidently a man who knows a gazillion things from a gazillion papers (I say that respectfully and honest); and that is valuable and useful and I respect you for that and I read with attention what you write here. But knowing a thousand cities from books and pictures is very different from living there. Each one of us has his place and use. The 1.000 papers people are a valuable resource but so are the engineers, even though some 1.000 papers people consider them, I quote, “people with less time or talent”, not “skilled”, or “immaterial to this conversation”.

For your information: I’m actually working with formal specifications every day, I do formally verify anything sensitive or not trivial. My “1.000 papers foundation” is 100 papers and 900++ hrs of actually doing what we talk about here. I dare to conject that this foundation is no less reliable and solid than 1.000 papers.

Being at that: It is exactly those immaterial people with mediocre talent whom we must wake up, teach, and provide with tools they can use. Because it is those people who write the vast majority of software – the very software that spills our credentials and has plenty of backdoors.

“Your claim was a European advantage. ” – Again: No.

That was what you in a hurry and with a quick glance took it to be – and erred. I claimed a european advantage in the foundation, i.e. in the cultural and intellectual basis. If it pleases you (which seems probable) I’m ready to say that across the ocean many, many more software (incl. tools) have been created.
Not only would I be ready to assume but I actually did assume that elsewhere (namely Russia) is a society that will very soon overtake us europeans.

My interest isn’t in glorifying one country and blaming another and, if that soothes your feelings about the felt “attack” I’m certainly not proud to be west-european (ask them. I’m telling them often enough how stupidized we have become, how we did allow our very foundation to rot).

My interest is in finding reasons and the hope that finding them will lead to solutions. That is what I’m interested in.

Let me offer a concrete example. Something that looks very innocent and unimportant, yet is extremely powerful: ranges. The point I’m interested in is: How must one think to come to that approach – as opposed to the typical and very widespread signed and unsigned integers (and floats, and …)?

The signed, unsigned, 8, 16, 32, 64 bit integer approach is one that sees a machine and asks “How to make use of that?”. Wirth’s (et al.) range approach comes from a quite different direction, namely from mathematics. It’s an approach that says “well that machine can do operations very quickly and we have to keep some of its properties in minds (such as word sizes) but – a very important but: foremost we must properly define the domains and codomains of the functions.”

The C approach is to say, that the machine offers a word size, while Wirth’s approach is to ask, how to properly use the provided technology and he keeps the rules of mathematics in mind. Whatever we put in those registers are but values along an alorithm and for an algorithm, which can be considered a function we need to properly specify domain and codomain. For him, so to say, an integer is a box of a given capacity and he acknowledges that but moreover he keeps in mind that we use those boxes for a purpose and that not the tool but the concept and the laws of reasoning are of primary importance.

Seen from this perpective we can easily understand Ada to be an evolution of that paradigm, one that is even more rigorous.

But we can also understand other things, for instance that it’s insane and irresponsible to use tools (incl. languages) that do not support and make easy to discern between algorithmic and implementation errors.

There are other examples that look innocent, yet have much depth, for instance Pascals High and Low. While a loop in C is often parameterized in a descriptive way (what the lowest index, typ. 0, what’s the highest index, typ. sizeof – 1) behind Pascals loop lays the mathematical constructive approach (apologies. english is not my 1st language).
All that is needed for trouble in the C approach is to add some elements to the array (changing its size). Using the other approach won’t spill beans. Low is still Low and High is still High (~ Ada ‘First and ‘Last).

One can hardly overestimate that point. Wirth (et al.) come from a mathematical view and are almost necessarily more robust – and btw. much easier to correlate with formal specs. Not by coincidence.

But there is even more to it. Because one approach makes it easy to make implementation errors while the other makes it easy to avoid them. That is also important because unfortunate many developers don’t care too much (as you correctly hinted). I call that the human factor – and we’d better keep that in mind until we find a planet with natural programers, because if we want more reliable code we will need to produce it with the programmers we have.

ab praeceptis • August 23, 2016 7:41 PM

@ Wael

I had no intention whatsoever to diss or insult a poster. As some might have noticed with a certain poster, I politely reply and when I reach the point where I think *stupid a**hole”, I simply turn around and ignore that poster.

In fact, I respect Nick P, and I have clearly stated that now. We do need the people who know a 1.000 papers. But we must not forget that in the end we also need code, preferably properly working one.

I’m, however, not willing to “politely” ignore issues. I’m willing to address them as politely as I can but I will address them.

How the hell should I address a bluntly obvious problem without someone feeling dissed? It is, in my minds eye (and I’m ready to learn something I clumsily overlooked) a simple fact that pretty everything across the ocean is quite different. Similarly, its bloody obvious that we in europe reach new records of stupidity every decade it seems. We observe, to be concrete, that nowadays fresh students are considerably less educated than high schoolers were some decades ago. And, Pardon me (and I *really, really try to avoid politics here), need i spell out the factor that changed europe since about the fifties and that replaced baguettes with burgers and relatively sophisticated TV with primtive soaps?
Yet, well noted, my interest is not to point at the bloodily obvious culprit – my interest is to avoid us dying in millions next to melting reactors. Or, less dramatically, “how do we enhance software quality?”

I heard that phrase probably more often than my own name -> “Nowadays IT is the nerve system of modern society, of goverments, of industry, and economy”

To me, our way of dealing with that looks like saying “rattle snakes can kill you” and reaching with your bare hand for one. It’s sheer insanity!

The epicenter of IT is across the ocean. May they be blessed and earn gazillions with it. But that also means that we must somehow address that problem and as politely as we possibly can ask them “You fu**ed up and big time. No week without mio. of credentials stolen, probably billions of $ robbed, and sooner or later a max. desaster like a nuclear reactor melting. OBVIOUSLY you must think again and think hard about your approach rather than happily spitting out new band aids every month”

ab praeceptis • August 24, 2016 4:25 PM

Gerard van Vooren

I think, DbC is often misunderstood, probably mainly because most of us think too much in terms of code and processor.

Risking to bore, Dijkstra again (I’d nail that to the head of CS graduates) “software is the implementation of algorithms”.

DbC isn’t a pimped parameter assert(). DbC is (already from a rather pragmatic developer view) about the domain and codomain of algorithms. It’s about “given, you feed me with data matching the domain, I will produce data with the codomain and according to spec” (plus invariants, which are another story).

The domain may or may not contain, say the NULL (pointer) element. I sometimes use a nice example in number theory: Most people would tend to agree that even numbers can’t be prime as they are, by definition, dividable by 2. A trap to easily walk into. The correct definition, however, is that a prime number is any number that is not dividable by anythin but itself and 1 – which 2 satisfies – and hence the above statement is false.

True, this is a simple and evident example (which, however, traps surprisingly many grown up software developers).

Now, assume you function is checking for primeness. You bet that many developers would tend to create a condition ladder with “((n % 2) != 0) ranking high (less experienced developers might even very early on try to get it cheap by “if(n < 3) return false;).
Similarly, many would define the parameter ‘n’ as “int n” – and fail to properly deal with negative numbers.
DbC isn’t about “make sure the array index is within bounds”. It is about making sure and expressing that the implementation matches the algorithm.

Is the index array i for a outside Low(a) .. High(a) is a job for the compiler.

Actually and reasonably some (very few) of the better formal algo tools for software development have DbC, too. And that’s a place where I welcome it because it will help the developer to realize that the correct type for n is “unsigned int”.

I’m experienced but I’m a human and both formal tools and DbC have saved me sometimes from doing stupid things.

I conject that any safety conscious language must have DbC and definitely should have a good interface for formal spec. Such a language would know and accept that it’s job is to implement algorithms and that it should assume that they have been properly developed, specified, tested, and verified. Seen from that perspective it would look insane to ignore domain and codomain.

“linking”

I’d like to offer a different point of view (and I have generics on my side *g)

Files are too big a unit. I’d like to have micro libraries with many small thingies, very basic algorithms, mini generics so to say, that I build and collect over time.

But, on the other hand, yes, files are the wrong approach. They are again an implementation of the “hands on” approach. We have way to many houses in the software world that have been built without architects and guided by “So, well, let’s see what we find in the local constructers market”.

ab praeceptis • August 24, 2016 6:17 PM

Funny(?) Addendum:

I think we are focussed too much on cpu performance. That doesn’t make sense for 1 and a half reasons (and possibly others but this is what I’m looking at, now):

A very major part of our software, starting from the OS, is big, ugly, fat bloat. An average linux desktop PC devours between 300 and 1000 MB before you even start any, say, word processor. Much of that is bloat.(I assume windows is similar but I lack data).
Plus the (well, my) “law of pixels”: Programmers who do graphics (on average) create considerably worse and more bloated code than console people. Touch “design” or “video” or the like and it gets a dimension worse. And the worst of all is web people. The performance per MB memory is miserable but the trouble per LOC rate is at the conceivable peak.

And: Performance isn’t just hardware. Slim, well designed sw on mediocre hw will easily outperform the usual bloatware on fast hw. In case you are interested, have a look at Oberon (which isn’t simply a language but rather a “language coming with its own OS” (or vice versa)). Probably Nick P can tell you quite more examples.

BTW: Recently I has to (oh well, I stubbornly insisted I had to) create a small special editor using Object Pascal. Primitive thingy but with some special features needed.

Result: About 5.5 MB executable! Damn. How had I so lousily failed? But: that thingy, without any hand tuning, was fast, way faster than even the minimalist editors (e.g. xfwrite, based on a quite modest lib). And it also loaded instantaneously (faster than others).

And then it hit me: statically linked with everything incl. the kitchen sink. The C++ coded alternatives (also GUI) looked tiny in terms of exec. size. But dynamically linked. Their net size? Multiple of my Lazarus thingy.

Small things one easily forgets about.

ab praeceptis • August 25, 2016 10:51 AM

Thoth

Pardon me, while you are right I take this to be yet another case of “Let’s ignore the gun pointing at us as well as the knife at our throat and let’s focus on the buttons on our shirt which are of regrettable quality!”.

Why? DES was good enough to protect state secrets for many years. And it’s not as if any Joe or Harry could crack it within the blink of an eye.

NO I do not recommend DES and I am very seriously concerned about security.

But: From what I know, most banks still use a 4 digit PIN to “protect” accounts. Moreover I could tell you banks (yes, in the year 2016) that happen to use the same method to “protect” their online banking websites. A 4 digit PIN!

Now, put 2 to the 56 security nex to a 4 digit pin and everyone should clearly see why I think our problem is not to enhance our indecent but not outright ridiculous door locks. It seems to me that DES is a far superior shield than a 4 digit pin to protect us from heaven falling on our head.

That said, we should properly analyze the situation, that is, we should see the the evil banks use a combined protection mechanism, namely [insert mediocre crypto algo] plus legal means. Whereever they are forced to rely on proper technology they do get the best and most epensive (e.g. HSM).

Plus, there is a social factor: The legal part of their construct, coming down to “any problem is the customers problem”, also creates a social problem (which maybe shouldn’t be discussed here as it directly leads to politics).

Funnily,the financial institutes in a way use the same approach we do, albeit they actually use it smarter. Like us they use the doorlock approach where their interests are touched and legal instruments alone can’t protect them. And we apply blissful ignorance (everything except ever better doorlocks) they have hordes or lawyers (plus excellent political contacts).

Cipher designers needs to design ciphers that can scale from a tiny 8-bit CPU to a 64-bit CPU

They did and they do.

standards bodies have to pick a capable and secure selection of ciphers for a cipher suite that supports a wide variety of application from securing 8-bit CPUs to 64-bit CPUs and even beyond 64-bit CPUs

Absolutely. Unfortunately, there is little reason to support the assumption that will happen. You yourself named one reason indirectly: The clout of 5 banks and 10 corporations is way bigger than that of 5 or 50 million ordinary people.

Plus: Those millions are humming away happily using opensssl (a.k.a. how not to implement cypto properly or as serious trouble generator) and paying plenty bugs to have some corp’s machines auto-certify that they are John Doe – unless, of course, they liked themselves to be known as “trustworthy banking inc” for the same “low” price.

With PKI being to do more with a money making machine (and the occasional man in the middle of some gov.) than with security and with banks today using 4 digits pins my worries about “DES is dangerously insecure!!!” are very limited and modest.

ab praeceptis • August 25, 2016 12:31 PM

Dirk Praet

I join.

ab praeceptis • August 25, 2016 2:42 PM

Wael

My stupidity is limited. Of course I know what you said.

The algorithm, however, is but a means, a mechanism. The final goal can very well be subsumed under “obscurity”. More bluntly, crypto serves to create obscurity in a controlled, well understood, and realiable manner.

2 to the x security directly translates to “more time needed to defuse the obscurity”. When we say, aes-256 is more secure than aes-128, we mean that (statistically) way more time/resources are needed to defuse obscurity and to get at the cleartext.

Funnily this is exactly the analogon to the friendly police officer explaining that doorlock Y (us$ 100) will buy more time (~ security) than doorlock X (us$ 20).

The private key is protected beause it’s the means to immediately defuse the obscurity rather than in years and with systems worth millions. A prng creates obscurity so as to seed an algorithm to provide better obscurity.

Concrete: We introduced salt so as to enhance obscurity when e.g. having our OS store password hashes. Kindly follow me for a moment. hashes would be worthless if they weren’t properly repeatable, i.e. if input X would not always and guaranteed create output Y. Signatures, for instance, are based on that very fact. So, what is a salt? It’s increasing obscurity so as to make an attack on a given hash algo harder.

private key plus public key in PKE create obscurity (sym. key) which then creates obscurity again (ciphertext).

I don’t think we serve ourselves and others well when we simply belittle obscurity as the idiots understanding of security.

The decisive difference between ourselves and the romans tatooing messages (maybe shifted) on a messengers head and relying on his hair growing back is that we have a way better understanding of obscurity and way better methods and algorithms to create and work with it.

ab praeceptis • August 25, 2016 4:17 PM

Wael

You’re redefining terminology… What is it you are trying to get at, what’s your point? That all crypto algorithms depend on some secret shared (or PKI) entity?

Yes, partly your “redefining” accusation is correct. But I don’t do it for the fun of it. Allow me an analogy to show my point:

Some experts argue that our rifles need a better MOA (“more repeatable precision”) to win in the war in which we are plenty attacked. They say that for some cases we need rifles that can hit within a 3 inches circle over a distance of 750 m. They are right – somewhat. And not – somewhat.

I argue that we shall not lose sight of the reason of the war, of what we want to achieve and what the enemy wants to achieve. And I argue that while we should work on even better guns, we should also realize that most of our people have no gun at all but stones and possibly knives. I argue that we should care about every one having a half-way decent handgun.

And I don’t want something like bishops to declare from church thrones what the terminology (and in fact the universe) is. I want a profound understanding of terminology, too. I don’t want dogmas (“obscurity is not security”), I want profoundly and properly understood facts and a solid basis.

We may turn any way we want but we can’t but see where our paradigm led us to. It lead us to a situation where we do not urgently need even better crypto. What we need is reasonable – and reliable – implementation of “security” and safety for everyone.

I’m not worried about crypto. We do have excellent and sufficient crypto thanks to some excellent cryptologists incl. our host here. We can – as far as crypto is concerned – protect our secrets, we have the necessary crypto with the exception of post-quantum scenarios.

And we have plenty experience that again and again demonstrates that (real world) attacks very, very rarely give us reason to doubt our crypto. What it does show, however, is that the implementation frighteningly often is attackable and attacked.

“terminology, part 2”

When people preach dogmas and create lousy software (incl. crypto implementations) while bluntly ignoring scientific facts that are oberservable then we did something wrong. 2 factors (of posibly more) that I can identify are a) an unhealthy distance between science (crypto) and everyday developers and b) terminology that seems to serve the experts well but that frightens Joe and Harry and makes him think that security is something to be consumed (because it’s too complicated anyway).

How can I educate Joe and Harry, how can I make them learn more and apply better standards when I’m not ready to talk their language? How can I succeed, when, in sad fact, I myself have not understood what it is all about (obscurity).

Joe and Harry may have the good intention but reality shows that their servers still happily accept SSL2 and lousy or even dangerous algos. Obviously we have created a scenario in which Joe and Harry are not capable, no matter their good will, to create a reasonable config.

“obscurity is not security” is also an elitarism and it’s a major obstacle for Joe and Harry to understand security. In the end they think security is “weird damn complicated math stuff” one better stays away from. So they buy certificates and run the (idiotically dangerous) standard config.

I will not elaborate much on that because it would bore most and because I’m not allowed to. But I’m involved with security every day and I was profoundly shocked when I had to realize that we do have excellent crypto – but not much more other than major conceptional flaws (plus, of course, massive implementation problems). OpenSSH to name a concrete example is a living proof of lack of proper thinking. It was basically treated as just another internet service although even a quick look would clearly show the very major differences and that SSL is a completely mindless approach for that purpose (while, in theorym, it is well suited for web servers and the like).

Apologies, it seems I’m annoying many here. I’ll try my best to become a nice friendly little link and sec. gossip drone.

ab praeceptis • August 25, 2016 4:47 PM

Wael

Can you offer me any solid statistics that show aes-128 or even old blowfish (“not cutting edge crypto”) being the reason for even 3% of security incidents?

As I mentioned my stupidity is quite limited. But I can offer “ugly knees” as a reason to dislike me. Thank you.

ab praeceptis • August 25, 2016 7:08 PM

Nick P

Front-up: I do not know much about about the system across the ocean, amendments and such.

First, thank you. I highly value people who are capable and willing to change perspective from time to time.

And perspectives might explain some differences. I assume you are right in thinking that billions are made with diverse “security solutions”, but to me (from my perspective) that means nothing and proves nothing (relevant). One might also mention the CAs, a pure snakeoil business; I assume they make billions, too.

Bruce Schneier – and I liked that a lot – was among the first to differentiate and to talk about “security theater” (vs. security). It’s a powerful and true image.

Blowfish was recently hit in practice by the SWEET32 attack. Bad implementation …

Thanks for that confirmation. In other words: Blowfish is still fine but implementations are often problematic.

As for your “long term” argument I agree to the degree possible (I’m not panicked by post-quantum but I take it seriously and see it as the single most potent long-term risk).

The read thread this goes through all the problems, vulnerabilities, crack, hacks, etc. is 2 things, one of which can to a large degree be reduced to the other: lousy software and very basic and foundational problems. In other words: We did think hard and well about whatever we thought (e.g. crypto algorithms) but we thought was too little about the foundation of everything.
In a way (hence military my analogy above) we behaved like officers who pondered many detail questions and did that quite well, but we forgot to ask the underlying basic questions like, why we are in war and what’s the purpose.

I agree with your “Forget about teaching them” – theoretically. Practically though we’re way too deep in trouble to afford that. We can’t just let all the attacks happen for a decade or two until we have developed the necessary basis (like languages that make it hard to create bugs and easy to use techniques to avoid them).

I agree with you, that’s why I brought up (way ago) my library analogy. It’s about complexity shielding and abstraction. That’s the only way I see, that is logically sound and not contradicting the way human are. And it’s an excellent knowledge multiplier.
Some very few high end professionals can put their knowledge into their layer and all the layers above can build on that without knowing much about details, risks and dangers.

Unfortunately that’s also the hard part. To do that it’s, for instance, not sufficient to know math well enough to formulate and verify one algorithm. One must also find a way to make it easy and comfortable for others to make use of that.

Concrete case: I know of no professional, supported and alive language that makes it easy to verify that any code matches the formal specification (and adds nothing). What I know of is e.g. ACSL, i.e. a more or less attached layer on top of the code that, frankly, is more of a good will gesture. Funnily, one that seems to work quite well, albeit based more on psychological reasons. To make it short, it seems that developers making the effort to use ACSL seem to be concerned enough to produce better code.

Or seen fron another angle: In the beginning as youngsters we took the compiler as enemy; it was moldesting us and putting barriers in our way to success. It needed some riping time to understand that a strict and rigorous compiler actually is our friend hinting us at problems that could be ironed out cheaply now rather than dimensionally more expensively later.
I’d like and suggest to add more to that, namely formal spec info to enable the compiler to check even more rigorously.

BTW, I have escaped some crypto problems by diligently (and stubbornly) cleaning and tightening data types. Stuff like “uint16_t” rather than just “int”. Well, crypto guys are typically mathematicians and not programmers, that’s OK. But I’ve learned that I must not simply consume their work but understand that for them code is often an ugly necessity. No problem, once understood I can, with a friendly and grateful smile, work over their code and bring my part to the table.

Which brings me to a final point: I can do that because I don’t hate math (I’m a pervert, I know g). Not that I’m particularly good at it but I understand enough to have some common basic ground with the math crypto people. And I think thatÄs of high importance. I’m very worried about the many, many programmers our universities produce that dislike or even fear math and who, for whatever reason (comfort?) assume that the crypto people are both, experts in math and in programming.
So it comes up again: We *must teach many people more, at least more solid basics.

ab praeceptis • August 25, 2016 7:54 PM

r

Misunderstanding. While code verification is an important part it was not the issue I addressed. That was a) algo verification and, more importantly, b) verification that the code actually matches the algorithm.

Some think that certain languages like setl or lisp provide that. I’m not content, however. Let me show you a simple example:

Suppose you have an algorithm that takes as input or produces as output (for whatever reason. Don’t care, this is an example) any positive integer that is matching two criteria: It’s max. 100 and its divisable by 4. In (some of the better) tools it’s feasible and even simple to specify that.

But what about the code? Most would probably say “well, use an assert()”. Nope. That’s a (rather poor) solution to a different problem, namely to “how can I check that a parameter or the return value matches certain criteria?”. My question, however, is how one can assure that the code is indeed a proper implementation of the given algorithm.

Add to that that an assert is the wrong tool anyway for the “max. 100” limit. In code that should be expressible; which e.g. in Ada or Pascal it is but in many languages it is not.

Again, I think that the basic problem is that most languages are trying to answer the question “How can one create code for a cpu?”. The correct question to answer (or to ask at all in the first place) were “How to express an algorithm in a manner that is digestibble both for a human and (after compiling) for a machine?” … and in extension “and how to do that in a way that makes sure that the language code does indeed fully and precisely express and match the algorithm?”

Why? 1 answer: One of the famous clay problems -> NP – P or, in other words (and slightly different) the Turing problem, i.e. that any non trivial programm can not be checked for correctness (actually Turings statement is somewhat different but this is the practically relevant version of it).

Which boils down to: It seems we simply can’t check a programm for correctness.

What we can do, however, is to check algorithms and, I conject, to check whether a given implementation (code) does match the algorithm. (Reason: That’s an entirely different problem class, namely transformation correctness)