Schneier on Security

ab praeceptis • December 16, 2016 2:38 PM

Ron

Frankly, there is no need for secure communication using smartphones. Simple as that.
That whole mobile universe is crapped from top to bottom. Starting at the EM end, over the custom hardware based on arm, up to the OS.
To add anything secure to that is akin to installing a high quality door lock onto a cardboard house with plenty man sized holes in it.

As for PGP, it’s “flaw” is that it’s all but unusable for the normal clicky clicky user. The effort to repair that flaw, however, is modest. More importantly, the complaints about PGP should be directed at the email client producers and at the standards committees who did what they alway do; they wasted immense amounts of time, resources, and money to come up with a bad non-solution compromise.

And that’s not the only mess they have created in what is one of modern mankind most important communication means. Just have a look at the SSL zoo across diverse ports and protocols in email.

One reason for that mess not being cleaned up is certainly the mobile idiocy. It’s “cooler” to create the zillionth app thingy instead of creating a reasonably useable and secure mail server and a couple of up-to-date good clients.

Maxie Marlinspike may be a smart man but obviously not smart enough to understand that no lock whatsoever, no matter how good, will make a cardboard house with man size holes secure.

ab praeceptis • December 16, 2016 5:43 PM

Ron

Nope, you are mistaken. 3G/4G and Signal are completely different things and on different layers. Signal is on top of 3G/4G, hence my card board house and high quality door lock image.

No matter how forward secret and whatnot Signal encrypts you are not secure if all that is running on utterly insecure devices with lots of insecure building blocks.

One can continue to use cool smartphones, which, for instance, share ones current location and enjoy lots of nonsense crap. No problem, after all most of what normal everyday citizens comunicate is not confidential or sensitive. One can not, however, somehow magically make those devices secure.

Moreover, the security hype seems to deactivate peoples brains. They seem to be in a “security!” frenzy. Security, however, starts with a proper understanding and assessment. Would I like, for example, my tax data or nudes of my wife to be looked at by god knows whom? Certainly not. But: Will the nsa be interested in my tax data? Hardly. Security starts with understanding and properly assessing “what is the need to protect?”, “Against whom and what to protect?”, “To protect at what cost?”.

The last one being a barrier the vast majority of smartphone users won’t cross. Clicking once on “download” and then “install” is what they are accepting as cost. To think about the above questions or, let alone, to move to their desktop PC (as a slightly more secure option) is a cost they are not willing to bear. Similar story for passwords; most users are simply not willing (or capable) to have multiple passwords for multiple sites.

Some of that can – and should – be compensated by better software, for instance, by realiable and easy to use PGP mail clients. Some of it, however, can not be compensated as we know even from strict military settings where people use the same usb stick both for their porn PC and their official work system.

ab praeceptis • December 17, 2016 3:12 PM

Nick P

Yes, PGP isn’t exactly friendly ease. I’m also not getting younger (and anyway disliking to keep details of peripheral stuff in my head). Maybe my solution that has been serving me well since some years now can be of use for you, too -> 2 shell scripts (pgpenc and pgpdec). Both of them are friendly and need only 1 or 2 parameters and when called naked they print some help-

Thanks for the cheat sheet. Not so much for the sheet itself; there is a man after all, but for the following idea: I will create a third script “pgphelp” that will serve as a life cheat sheet for less common cases.

Btw., am I the only one who uses only mksh and who avoids zsh, bash and accomplices if ay possible?

ab praeceptis • December 17, 2016 4:09 PM

Ron

It seems to me that Clive Robinsons image of the houses floating, on sand, or on solid ground etc, should have been clarifying enough.

Signal is an application that a) runs on an utterly insecure device and b) transmitts over a rather questionable medium (with b) being less of a concern).

You seem to think (and stated multiple times now) that Signal somehow magically makes communications more secure no matter all the problems beneath.

That is a wrong conclusion

The first question is against whom and what you want to protect. Against a curious neighbour with a small hobby radio station? If yes then what you do is a mixture of total overkill and futility.
Or do you want to want to defend against, say the fbi? If yes then you act like someone who uses a very secure 50 digits/chars password but who noted it on a post it on his monitor.

You must see the full picture, both re. the information you want to transmit and the hw/sw stack.
For the latter Signal is running on a device that you (and end user) can not possibly consider as secure and is using libraries, system calls, a kernel, many firmware blobs etc. whose security is very doubtfull and next to certain unknown to and uncontrollable by you. We need not even discuss that; there is proof for the underlaying hw/sw not being secure and outsde of your control anyway.
Re. the information, that is most probably not existing only during the transmission, i.e. it exists before and after (at a site you probably don’t control). Maybe it exists on your drive, maybe in your head, maybe on paper, no matter. Moreover transmitting information usually also means creating multiple copies of it and to multiple places, etc.
Moreover even the assumption that the information transmitted by Signal exists only within Signals memory area is highly doubtful. What, for instance, makes you sure that the get-users-password routine which uses the system beneath doesn’t keep a copy? Not even for evil purposes, maybe just because some prgrammer worked sloppily…

Short: You view is way too focussed on only a part of the whole picture and based on hardly tenable premises.

Btw: Could you even make sense of it if I gave you the extracted machine code of some of the (unknown to you) chips in your mobile device using Signal? If not, we can stop that discussion right here.

But hey, have fun using it and feeling secure. And in case you ever need an Eiffel tower or a brooklyn bridge, contact me; nobody has better prices than me!

Sancho_P

“2/3 of our security is still based on obscurity.
I don’t know if there is a solution to this.”

Yes. Make 3/3 of security obscurity and, even more importantly, let us finally understand that what we do is about obscurity.

It’s damn about time to understand our job. We are professional obscurers.

It seems to me (maybe I’m too generous and optimistic) that about 134% of the people in IT Sec have fallen victim to a lack of differentiation, to a mangling disease, namely to abhoring obscurity.

We must leran tu understand and to discern the following:
a) IT Sec is largely about obscurity
b) the mechanisms to create oprimized obscurity, however, should not be obscure.

Look at rsa: We basically multiply two very large primes (plus some mumble jumble) so as to create obscurity. Let’s be honest and realistic. That’s exactly what we do and what we work on. We work on professionally created optimized obscurity.
What’s rsa all about? It’s about presenting an opponent with such a horrendous amount of obcurity that he can’t possibly see the information behind it (say a session pw for sym enc.).

They way however, to create that obscurity must not be obscure but it must be a solid and verifiable mechanism.

Another example is (P)RNGs. There we want some criteria to be met; like equal distribution, etc. In other words: We desire optimized obscurity. A lousy distribution, for example, is akin to the 007 being behind a curtain with the tip of his shoes still visible.

In fact, we even have a measure for the quality of the obscurity we produce: If an opponent’s chance to see through our obscurity that is so ridiculously low that it’s considered null then we are satisfied and consider our work “damn obscure enough ™”.

Example: As per today we think that no opponent is capable to find the factors of a 2048 bit (about 650 – 700 decimal digits) number having only 2 (prime) factors within reasonable time.

Even better example: We sometimes call (crypto) has function “spreaders” because one the properties of an x-bit hash function is to take an input of arbitrary length, in the case of password typically about 20 – 30 bits, and to produce a representation of x bits (typ. 128 – 512 bits).
That, ladies and gentlemen, is professional and optimized obscurification. In fact, a proper crypto has function even guarantees that one will not possibly be able to see the underlaying information.

The way to do that, the mechanism must, however, not be obscure.

It’s about time that we a professional obscurers learn and keep in mind that difference.

ab praeceptis • December 17, 2016 5:44 PM

r

Usually, you don’t get answers from me anymore.

Here I make an exception, however, to avoid others being misled by your error/intellectual negligence.

I said “machine code”. That’s a simple blob of bytes – not “asm”.

Btw. you err even once more in that post. My question was not if “one” can … but if he can …

ab praeceptis • December 17, 2016 6:40 PM

Ron

I did not say “don’t use Signal!”. What I said was that you should be aware that it’s security theater to a large degree (and not by its won fault, but that doesn’t change the result).

Please, do not take that personal, it isn’t, but in a way you demonstrate a major problem in our field, namely complexity. You, for instance, say things like “SSL/TLS … because certificates make it more difficult to intercept transmitted communications”.

That’s plain wrong. Certificates – in theory and lucky cases – provide one service, namely they give you the opportunity to verify an identity (usually that of the server at the other end or that of a communication partner).

As I said, this isn’t against you; actually it’s more against ourselves: We must create a) problem awareness and b) simple and simple to use solutions. It’s not your fault to have misunderstood quite a lot. It’s our failure.

As for “eminent experts”, Bruce Schneier is our host, he has given us some pretty impressive and useful algorithms/programs/libraries, and I’m a polite man (well, I try hard), so I won’t comment much on that argument of yours. Suffice it to say that “this is secure” is not the only and possibly not even the decisive criterion to use some technology.

Be that as it may, my point was not to advise against using Signal. It was against using Signal cluelessly and against believing that Signal somehow magically turns a cardboard box into a fortress. It does not.