Schneier on Security

ab praeceptis • November 6, 2016 6:45 AM

Funny misunderstandings around.

PBKDF2 is certainly better than pretty any password, unless one chose one with many characters (in the programmers sense, i.e. incl. digits, punctuation, etc.).

Simple reason: Not only are common hashes way longer than common passwords but they are also way more random.

The other part in those ratchets (usually KDfs) the number of rounds, as some describe it, serves a completely different puropse, namely that of driving up the cost to use rainbow tables, or to otherwise crack password hashes.
It works (in good cases like Argon2) by very considerably driving up the memory and computing cost. The “rounds” are not just rounds but rounds designed specifically to be expensive, not to be parallelizable, not to be easy for GPUs and ASICs, etc.

The problem with cloud based password managers is somewhere else, like in lousy javascript running in gigantic bug heaps called browsers and, worst of all, it’s in trusting a third party with all ones keys – usually a not at all trustworthy one, at that.

My suggestion for fans of clous based password managers is hence to go the full way and to use voice recognition and/or fingerprint readers at their local end, too.

Or, to make it much simpler, to use 1 single password for everything and to simpley write that one on a sticker attached to ones monitor. The security level is about the same cloud based password management, haha.

Maybe nas and fbi should open a free cloud based password service and put a nice fbi “secure” logo on their website. I’m sure they’d need serious rack space in no time.

ab praeceptis • November 6, 2016 4:30 PM

Clive Robinson

It should be obvious by now. (Most) tor fans are not interested in facts; it’s an emotional and social issue for them. Rather than being glad to get pointed at facts by helpful knowledgable people like you, they perceive your remarks as an attack.

tor traffic many times intercepted? Many tor nodes, particularly exit nodes, under dubious control? People using tor being arrested? Doesn’t matter to those who want to religiously believe in tor.

But it goes much deeper. Some of the good and nice tor people (like some of the good and nice mozilla people and others) are more or less visibly related to people like soros, and even to organizations quite close to nsa, cia, ghcq, etc.

There will never be such a thing as secure and confidential communication for the people. The internet is said to serve that purpose (at least inter alia) but is, in fact, quite probably the contrary.

Let’s be reasonable and cold thinking for a moment. No state likes real freedom for their people. Each and every state has it written down in law, albeit worded looking positively. Things like “the untouchability of the private sphere” sound nice but simply mean that outside your house you are fair game. And even inside your house you are fair game if any state agent pleases to assume that you are possibly not a perfectly law-abiding citizen.

Moreover the internet was a darpa project. darpa is a mil. agency and since millenia the control of information and communication has been impregnated onto the genes of mil. people. It seems ridiculously blue-eyed to assume that those mil. people ave let go some of their holiest principles for the sake of freedom and blabla.

Whenever mil. (and in extension, spooks) is involved there is a simple “law” applied, and that is the law “we can communicate securely and confidentially and all other can not. Moreover we can control the flow of communication, the confidentiality, etc.”.

To look at that from a democracy perspective is just nonsensical. If one really, seriously wanted to limit the mil. and security agencies, one might as well resolve them. They need that to operate; it’s not a political issue for them but a simple precondition to perform their work.

Many are shocked at how they lie and that they do not seem to understand liberal values and the need of citizens to communicate freely, etc., plus it’s even written in the laws. What did they expect? Did they expect that politicians write into the laws “Dear people, mil. is about killing others and preferrably not getting killed oneself” or “dear people, our enemies don’t have the politeness to always attack in formally correct ways and from far away, hence we must include all possibilities”? Hardly (at least not in language normal persons could understand).

Possibly the worst flaw of (not only) the tor crowd is to consider them friends rather than foes. That’s the classical – and often deadly – error. Same with cloud based password services.

Security begins with having a reasonable idea about the threats to expects, about the foes (and their desires and means) etc.
Can the (in particular, the deep) state de facto take over tor? Certainly. They’ve shown so much. Can tor show convincingly that they can’t be taken over, poisoned, abused? No.
Ergo: tor is not an ally. tor is not friends.

And that’s what crypto is all about. It’s about being certain about some properties (like confidentiality, integrity, …) under hostile conditions.

tor is but security theater. Simple reason: It doesn’t meet spec #1.

Will religous tor zealots eventually get that message? I don’t hold my breath.

ab praeceptis • November 6, 2016 7:06 PM

My Info

Just a short remark: many people seem to blissfully ignore that but a) proving anything with Gödel incompleteness theorems is not the best way to go about it and b) GITs also apply to themselves!

Plus: Looking at different areas of math/logic one is easily seduced to feel having discovered something great which also seems provable but actually isn’t.

If you ask my advice: Continue playing with it but don’t bet anything on it. Playing is good, playing is a wonderful motivator and in one or another virtually alway bears fruits. But think more than twice before building or betting anything on it.

One of the problems you are dealing with is the age old question whether mathematics is an invention of the human mind or whether it’s something inert in the universe which we discover. Which, btw. is also a sibling to Gödels ITs.

Next: Keep in mind what P/NP really is! It’s a rough – and temporary – sieve. One can, of course, establish propositions based on that but in terms of proof it isn’t worth to much.
Also keep in mind that the settings are very floating and diverse. What might be P for nsa might well be NP even for most states.

To make it even uglier: What reference do you have? What’s NP – and: are you sure?
What I mean is this: The assumption that “is known to be NP” is treacherous. What guarantees that agency X in country A having achieved to bring, say factorization into P will also publish that?

That’s btw also why I’m so worried about pq. My worry is less that google or someone might soon have Shore and Grover working on a quantum computer. Hardware progress has a tendency to be talkative (i.a. because usually corps. are involved and selling usually needs talking). My worry is that another Perelman might come up with a devastating algorithm that, however, is not published.

And btw. keep in mind what oracles really are. They are by definition magic boxes. I see more problems than advantages in using them in proofs.They are useful devices, no question, for certain model operations but as lemmas they are pretty much worthless.

ab praeceptis • November 6, 2016 8:05 PM

Thoth

IMO that largely depends on whether we are talking about one shot ops, i.e. once creating a secure has that is then used over and over again or whether we are talking about something that happens each time, say, a login proc. In the former case it seems acceptable, in the latter it seems a no-go.

And again, I think that you should reconsider your approach. Let me explain again in the context of KDF (which your are using):

Using an excellent KDF with a reasonable cost in both performance and memory, I end up with a ratio of about 1:10 to 1:20 between a fast multicore machine and a slow pentium or modern dual core arm machine. Note, however, that unlike smartcards for all machines 16 or 32 MB memory use is small to neglegible.

I guess that even a fast infineon would be more in the range of 1:200 – 1:500. That’s deadly. In a real world application you must see both, your quite poorly equipped user and you quite amply equipped opponent. That difference or, more precisely, to have a small difference, is absolutely key to your KDFs. Get that one wrong and you have a weak mechanism.
Also note that KDFs must be well understood. A “cost” parameter tells you little. What you want is a thorough understanding of the cost domains, of memory, algorithmic complexity, cpu cost. Example: You do not want algorithmic complexity! That’s OK if the execution context virtually always are intel or arm and Joe and Jane users but otherwise not. Complexity is the weak point because it invites HW powered opponents.

I think you should look and assess again. A smartcard is (within the bounds of easy availablitiy) a very attractive and secure “I have” that moreover can be well linked with with a “I know” (and can, to a degree, also have a “I know” on board).
That is it’s strength. Not computation, no matter what they tell you about their hw engines (don’t forget that those hw accels are being there to make crypto bearable in terms of time, not to make it fast!).
And smartcards have an inherent weakness, namely their weak processing power.

Therefore I suggest again looking into staging, i.e. transferring a very small routine from the smartcard to the host which then runs on the host and checks that some larger routines haven’t been tampered with which then do some more complicated checks as well as the crypto.
As an exception one might have 1 long running (even minutes) single-shot routine that is only rarely running to, for instance, KDF create a good key or hash or alike.
Be ware though that one must “cut into pieces” the KDF very carefully. Why cut? Because users will need some “I’m alive. I’m just working hard” signal. So, rather than having your KDF do 10.000 rounds in one go you want it to do 100 rounds of each 100 rounds each time with a life signal for the user in between. That slicing, however, can be intricate (e.g. you must keep lots of delicate state intact) and some KDFs lend themselves better to that than others.
I have coded that myself and I has to carefully study some of the better KDFs for that (and stayed away from bcrypt and scrypt and simple (say sha256 based) ratchets.

It’s ugly, I know, but if we want users to actually use our devices we must keep their needs and way of ticking in mind.
One example that comes to mind is the fact that users have different needs and priorities. So, your mechanism must be constructed in a way to allow users to make decisions for themselves e.g. re speed vs security level.

And again, I think that “I use a smartcard” by itself is not the best approach. I’d strongly suggest to use a mixed approach where each elements can fully play its strengths while avoiding its weaknesses.

ab praeceptis • November 6, 2016 10:05 PM

My Info

I see. It’s a religious or quite personal thing.

“GIT fringe view” – BS. I didn’t doubt the GITs. Reading less zealously you might have found that I merely suggested that they are (often) not a good approach to proving something. Like potatoes. They exist; definitely. But they are often not a good approach to prove something.

Moreover you seem to have missed a point or two in the linked paper. I quote: “Gödel’s assertion … We have certainly shown that it cannot be a provable theorem” and, more importantly “Since Gödel’s theorem applies to all formal logical systems …”.

The author certainly doesn’t serve as a basis for your attempt.

You might also want to think about the temporal/causal properties of both GIT and the machine you rely on so strongly.

It seems to me that you mix and shake Gödel numbers, his incompleteness theorems, Oracles, Turing machines plus an assortment of crypto devices and feel to be on the track to something big. Well, good luck, honestly, but I don’t hold my breath.

“I really do not like the sound of that type of “warning.” At all.” – don’t worry, I will not again benevolently fall for your game (nor will I make it my religious goal to care about what sounds you like).

ab praeceptis • November 8, 2016 6:56 AM

Info Update:

OpenSSL has announced their new bug collection. One of the features is that a high severity bug from the recent bug collections has been killed.

It just keeps giving …

ab praeceptis • November 8, 2016 8:20 AM

Thoth

For the sake of fairness: The OpenSSL developers are confronted with a code base that is about as lousy as it is massive, which then is implementing a plethora of algorithms for a plethora of architectures.

Which translates to a) no chance, and b) no chance again.

To roughly quote Hoare, reliability is to be payed with simplicity – which comes down to saying that no ssl/tls implementation can be of good quality, unless they throw out tons of “historically grown” crap for a start.

Another very important point is that to the best of my knowledge none of the halfway known ssl/tls implementations (ignoring the F* based one which iirc is hardly alpha and whose usability for code in other languages remains to be seen) does even so much as annotating their C or C++ or java source texts for static verif (leaving aside the fact that even trying to implement tls in c/c++/java and accomplices should be punishable by law).

But, OK, granted, OpenSSL is quite certainly winning the big “crap” medal.

ab praeceptis • November 8, 2016 5:15 PM

Wael, Thoth

Fips. Let me be frank: About the only property Fips seems to actually ascertain is certainly not about software safety. A Fips certficate seems to be about as valuable as a blind comatose dog is as a guardian. It seems to wear a golden collar with rubies though.

And btw. there are other creepy options with a Fips sticker around than just OpenSSL.

The question in which language I’d implement it is not fair (towards OpenSSL). When OpenSSL was started there were a whole lot of things we didn’t know and understand. Then it reasonably looked like a good choice to do it in C.
On the other hand even then alternatives like Modula were around. I mention this less as an attack than as a witness. It points to people not really understanding their problem domain because, if they did they would at least have used some available tools like e.g. Larch and they would have approached the whole thing quite differently. So if one asks me, one should ask me what language and other (spec, model. verif) tools I would have used then. My honest answer: I would have done it like them because then I was a cool youngster with bold self-confidence, a half empty brain, and a lack of proper reasoning. But I know that smart, experienced and very capable men with a far more professional attitude than I had then were around. So, it could have been done much much more professional than it was done.

And languages … oh well, we had no lack of them plus we had very fine research centers with very fine people in PL. One would have had languages available that were running on pretty much anything plus, so it seems, it’s much easier to port a well designed language than it is to hunt the bug in a big pile of crap down …

But it’s not even about the language choice really. From my point of view the language choice was just another symptom of the real problem. And that was too much politics in it, probably too much sales interests, and most importantly too little quality thinking. I think that OpenSSL is rotten due to very poor conception and design, showing a severe lack of understanding the problem domain.

I’m btw. not so much concerned about too many ciphers. Sure, obviously and known to be creepy and broken ones should be thrown out, but all in all the problem isn’t about ciphers multitude, and if it is then more due to the mechanism that come with that choice (complex options processing etc.)

Interesting problem domain btw. A well meant and well conceptioned system with, alas a lot of problems due to implementation – vs – a lousily conceptioned and carelessly designed system with, of course a never ending stream of problems. The former can be repaired, the latter can’t. “Simple” reason: The problem source is out of reach for the repair tools; one can’t but fix symptoms over and over again. About the only way to make that worse were to thrown in a golden “secure and well done” seal (Fips) because what that really does is cementing the problem source and strongly supporting it.

But hey, in case no one noted it: My point wasn’t so much about C anyway. My burning concern was “How much more pain do we need to learn that we need to use some formal methods for our safety and security crown jewels?”. An attempt in C but using ACSL/Frama might not be the optimal but much much more solid than the 16th attempt in naked C. It might acually being a basis for some reasonable safety propositions.

ab praeceptis • November 8, 2016 6:59 PM

Wael

do formal methods catch conceptual flaws, things that caused Heartbleed, for example?

For a starter: One may debate in which corner to put heartbleed and one might well argue that even proper implementation could have avoided it.

Here you go: Rather than

…
free(p);

one might – given an understanding of the problem domain – have written

…
memset(p, 0, pSize); /* pSize is the chunk size */
free(p);

An artifact well known back then and often used. Had it been used, the heart wouldn’t have bleeded (but happily thrown out zeroes).

But, more generally, YES one could, at least to a quite large degree. Not with verifiers, of course, but with formal spec and modelling. And, yes, that kind of tools were available back then. Z, for instance, or vdm, to name two examples.

Et voilà, back we are at what I said. Lack of understanding of the problem domain; if those guys had had that understanding, it would have bitten them right in their noses that a project that is about safety and security crown jewels and hence includes lots of crypto, loudly shouts “spec and model me properly and formally!”

Note: I used “blockquote” formatting for code above. In case is a futile attempt, I apologize. I’m rather stupid in html stuff.

ab praeceptis • November 8, 2016 8:40 PM

@Thoth

Yes and no. Yes, there is quite some formal tools that can help to an amazing degree. Some problems, however, like heartbleed and other buffer or mem. problem classes pretty much fall into the separation logic field (where tool support still is very thin).

A not completely correct but good enough primer to understand:

One problem class is to do with code paths and code flow, plus a whole lot of related stuff.
Another problem class is roughly what one tries to tackle with strong static typing. Things like not reading/writing beyond mem/array boundaries.
Those two are often put into one solution approach roughly summarized under “static” whatever (static verif, static typing (and checking), etc.). It’s roughly what one means when talking about “formal tools”.

But there is rather different problem class, namely memory, which, to make it harder, is not only closely linked to code paths but also to time. That’s where separation logic enters the game. One can roughly understand that as Hoare triples but memory related.
Where is normal H3s you make logic statements as we know them (like “when entering param ‘day’ must be no less than 1 and no more than 31” or “the return value is guaranteed to be a valid date”) separation logic follows the memory and works with predicates like (very simple example) “Upon entry the memory area of var X is of know size and location and accessability (e.g. threads!) and does contain a value within a specified range”.
It is this that allows to posit properties like “for all bytes of array ‘heartbleed’ it must be true that their index is either lower than ‘pSize’ or else their value must be ‘\0′” – which is the only way to properly and verifiably state that there are no arbitrary values within that array (which led to heartbleed).

The other main approach to that problem class, which is often preferred for its friendlier surface (“ease of use”) is the path Ada took, namely to anally control and limit (to sane levels) memory, in particular access.
In some way Rust is going somewhat in that direction, too, albeit from a more “C-ish” perspective. Where Ada says (except for exeptions which need to be expressely declared and are avoided as much as any possible) “Nope. You can get a pointer to some variable mem that you own (“access”) but you may neither change that “pointer” nor do arithmetic with it. Period.” Rust come from a C view and says “Well, the world needs pointers, but we must control them, tag them, group them into different kinds of pointers, etc.”

In other words: You can chose between a very strict and limiting language or else you can enjoy funny pointer games but you’ll have a lot of not exactly easy formal work to do.

Personal side remark: Both approaches have their advantage. Ada (to name the classical ‘strict language’ example) offers a lot of convenience at not a high price (it just feels tough for C-ish developers because the paradigms are so different on multiple levels) but one must also see that quite many projects just can’t be implemented reasonably without some pointers – and that’s where Ada leaves you completely alone. You can do it but you’ll be alone and outside the supported zone.
Rusts approach is (IMO) by far inferior but, and that’s an important but, it doesn’t leave you completely alone when you sometimes just need them dirty pointers.

Looking at how Ada evolved there is a clear trend visible (it seems to me anyway), both in Ada 2012 and in Spark 2014 that IMO points to them sooner or later (and maybe already) looking for ways to include at least some basic separation logic into at least Spark.

For other languages like Parasail, Modula-3 or Sather who look(ed) promising but are either rather exotic or next to dead that SL approach would be desirable and feasible, too, but rather unrealistic when considering how poor tool support is even for way more common languages.

@Wael

First, thanks for the html formatting hint.
And, yes you are right, one should neuter memory right after use but I wanted to stay close to the point.

“Critical Systems” – You are right. Of course that effort isn’t made and that price isn’t payed when building some everyday thingy. But: I think we should have learned by now that the crown jewels of safety and security, the very f*cking base that is used in so many software products is critical.

@MyInfo

“pentagrams, hex, …” – Bullshit!

ab praeceptis • November 9, 2016 12:34 AM

Clive Robinson

Thanks for walking right into my (absolutely benign and friendly, purely discursive) trap; I used a date/time related example well knowing about the box I would open *g

And you are absolutely right.

But it’s not just for the fun of it that I opened that box. It also serves as a striking example why we need to shift “start of design” from “well, hack away” towards “play with your model”.

What you say are basically algorithmic and/or conceptional problems. Doing it sloppy and just assuming that dates are in our current calender system is a good example. Static code verif. will fail to catch the problems arising from that; it will be limited to catch errors in implementation on top of the chosen concept. How should it catch the fact that someone might enter a julian date? Or how should it catch a feb 28 vs 29 error unless our conception includes that issue?

Short: we should change towards a model where we finally remember Dikstra: Software is the implementation of algorithms.

Nobody (I would hope) would try to redesign a houses static while building it. Obviously a “building checker” can only check against what the blueprints tell.

Accordingly we must re-locate our perception and habits to do the playing and testing on algorithms/models and not on code. Unfortunately, as I showed above, that is a complicated a hardly promising endeavour when the tools are cumbersome and didely ignoring developers (they are usually made by and for mathematicians) and when steady progress on the code verif. side makes it luring to do the modelling as an afterthought and necessity or, in many cases, just let go completely and content oneself with “the compiler gave me no error”.

ab praeceptis • November 9, 2016 5:26 AM

Just discovered at hackernews. An open source “Hospital System”. In java. What could go wrong?

On the home page I quickly see a smartphone, a tablet and a notebook; looks all very apple-ish (don’t count on my word. It’s my first impression, it might be wrong).

Evidently that’s their image, both of themselves and for users (hospitals). Looks like a typical driven by design (as in “colours” and “forms”, not as in “engineering”). What could go wrong? After all, as everybody know, the most important criterium for a hospital application is doubtlessly that it’s nicely designed and that it runs on smartphones, right?

Next, a look at the code. I have a hunch …

Being confronted with a java typical maze I walk around and have a look at the drugs stuff (“It’s all a matter of dose. Too much can kill, too little can be irrelevant or even harm”).

And what do my eyes see? Some kind a prescription/application class (feed drug order).

Wow. Have look:

private int numberOfDays;
    private String productUuid;
    private Double quantity;
    private Double dosage;
    private String unit;
    private String orderUuid;

They should be lauded! At least they didn’t make it public and accessible through a web xml blabla publisher thingy (don’t take my word for it …)

Quantity as a double. Brillant. I see it before my eyes how their brains ticks, when suddenly it strikes them “There might be half pills or 2,7 ounces of something!” – hence double. double is also good and useful in case you ever wanted to describe 3.7 zillion tons of some medicine. Don’t you laugh! let me ask: what’s in their way to avoid that?

Well, let’s look:

public BahmniFeedDrugOrder(String productUuid, Double dosage, int numberOfDays, Double quantity, String unit, String orderUuid) {
        this.numberOfDays = numberOfDays;
        this.productUuid = productUuid;
        this.quantity = quantity;
        this.dosage = dosage;
        this.unit = unit;
        this.orderUuid = orderUuid;
    }

Very well done. In case you wish to prescribe 3.7 gazillion tons of some medicine, that is.

But let’s not hasten and judge too quickly. Maybe that constructor wasn’t really meant to set all the parameters and they just put it there because they like to type.
Certainly, there is a setter which then with eagle-eyes controlls whether the input makes any sense.

public void setQuantity(Double quantity) {
        this.quantity = quantity;
    }

Uhm, hmmm.

Do you feel better already?

So sorry, Ma’am, but who would have thought that our 30 cents an hour nurse would mix up micrograms and pounds? Sorry again. Have a nice day.

ab praeceptis • November 9, 2016 8:22 AM

Thoth

Rule #1: Assume that the user will enter the most nonsensical input imaginable.
Rule #2: Assume that your imagination is limited and that some user will find ways to enter crap far beyond your wildest imagination.
Rule #3: setters are part of the interface. Any input that is not properly checked is to be considered a kilogram of explosives with a free crocodile with aggression disorders thrown in for free.

But hey, it’s just a hospital system. Though, certainly it’s not too welcome to hear “Pardon me, Sir, yes your wife is dead and your brother crippled but, you see, that’s not our fault. It’s our IDEs automagic that did it” (and the fact that our developers chose to remove their brains to make room for java stickers and usb sticks).

(I’m not angry at you. You just told a reasonable assumption. I’m angry at those brainless “developers” who, of course, expect but admiration; after all it’s open source!)

Sometimes I’m wondering whether it’s soldiers with evil intentions who killed more people or whether it’s brainless meatpiles who meant, oh so well.

ab praeceptis • November 10, 2016 5:21 AM

John J Foelster

Pardon me, but from what I see and know about this blog, this blog is not the right place.

For two reasons:

• This blog is about security. Our interest in voting fraud is of a rather technical nature. (And I guess most of us have lots of reasons to be suspicious of pretty much all voting machines). But your post offers very little for us to look at.
• Please join the line. There is many, many who feel or think that the elections haven’t been perfectly proceeded, possibly with evil intention.

But this is neither a Trump nor a clinton forum.

Third, many of us are not the believer kind of personality but the researcher kind. And mistrusting (security and mistrust are cousins).

Having your text on an absolutely non-technical site and on what seems to be a pals site, doesn’t exactly soften my mistrust.
Neither does the fact that your “vast” private website with “lots and lots of information” gets mentioned in your pals intro but I don’t see a link.

Mentioning “lots of info” but not providing it is all but making sure to create mistrust.

Maybe I’m a tough a**hole. Possible. But from what I see, there is no case because there is no material, no evidence, at least none for us.

I therefore suggest that you lay down and get some sleep, possibly while sobbing about this bad world, or that you give us something tangible and IT security related to look at.