From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4
Date: Sun, 2 Mar 2014 16:17:02 +0100 [thread overview]
Message-ID: <20140302151702.GA12912@tansi.org> (raw)
In-Reply-To: <20140302073523.GA2122@fancy-poultry.org>
On Sun, Mar 02, 2014 at 08:35:23 CET, Heinz Diehl wrote:
> On 02.03.2014, Arno Wagner wrote:
>
> > > It's not always the facts which leads to action, but the peoples
> > > assumptions and beliefs. After all, there's a general disbelief in all
> > > things the NSA put their fingers on. That said, it is not hard for me
> > > to understand what people moves to use whirlpool over SHAx..
>
> > The advice is not to change crypto parameters unless you
> > really know what you are doing. Most people do not and make
> > matters worse.
>
> It's perfectly clear to me (and I'm neither using whirlpool nor a
> libgcrypt < 1.6.1). What I wanted to point out is that it seems to me
> that people have lost their confidence in anything the NSA touched.
> Thus, they seem to choose what they believe is most suitable, and not
> what is based on facts.
Indeed. Thereby they will often make themselves less secure and
play into the NSA's hands. A good eaxmple is SELinux. While
in theory it may be backdoored, doing so for an access control-layer
is blatantly obvious, unlikely to have happened and easy to fix.
If people now avoid SELinux because the NSA had a major part
in its cration, they are making hemselves very much less secure
and easier to attack, also for the NSA.
Examples of NSA sabotage show that they want to be subtle and
hard to detect reliably:
- Dual_EC_DRBG: They likely sabotaged the constants. This is
not detectable even for the very best experts. What experts
can do is suspect that the design allows undetectable attackable
constants. (By now somebody has proven this by providing
compromised constants and then attacking them.) Experts have
been suspicuous of this thing for a long time because of its
design. And then there is the little gem, that in the
implementation by RSA Labs it was the default, despite
having the worst characteristics of the alternatives.
That is highly telling and it is clear that at least
some people at RSA Labs were in bed with the NSA.
- Intel RDRand: While it is unclear whether it has been
backdoored, the design intentionally makes it impossible
to detect in software if it has. There is no sane reason
to do so, just an irrational end emotional appeal along the
lines that "somebody could use this to attack RDRand if
its internal state was exposed via JTAG". That is of course
complete BS, than anybody having JTAG access has physical
access to the CPU busses at that time and can do anything
they like. Contrast that to the VIA C3 hardware random
number generator where you can read raw bits and see,
for example, influence of thermal shift.
Just like for Dual_EC_DRBG it is unclrear whether RDRand
has actually be compromised, but it clearly is prepared
to be compromised easily and in a hard to detect fasion.
I.e. it is insecure by design.
It may never be compromised, it may be compromised for
specific batches of chips only, or it may be routinely
compromised from some point in time onwards. We cannot
easily find out and that is the problem.
There is one non-technical clear indicator of sabotage
though: There was a strong push by Intel egnineers to make
the Linux kernel use RDRand exclusively for randomness
generation and to drop all other ways of entropy gathering.
There is no good technical reason for doing so (there
are a lot of good reasons for _not_ doing so) and the
Linux kernel folks recognized that and refused. But the
pressure applied is in itself already quite telling.
- IPv6: The NSA sabotaged it not by introducing any direct flaw,
but by making it convoluted and complex, thereby making it
very vulnerable to implementation errors due to extreme
violation of the KISS principle and unneeded complexity.
They likely go over the popular implementation from time
to time to have a nice liost of zero-day exploits ready
whenever they need them.
In all cases, sabotage cannot be reliably demonstrated, but
it is pretty clear it happend or there was preparation for it.
Of course, it is possible that Dual_EC_DRBG and RDRand is
secure and they were just testing the waters whether the
community would accept a design with serious vulnerabilities
against the designer. It is even poossible that the
anti-KISS attack against IPv6 is in fact incompetence. But
how likely is that? Right, not at all. Hanlon's razor is
a good first evaluation for the actions of individuals,
but an organization like the NSA is very well capable
of hiding behind it.
Now take other things:
- AES: There is really no reason to believe the NSA did
compromise it. It would have been hard, the risks of
being found out would have been quite real, and
the damage to US and world economy could have been
catastrophic.
- SELinux: Far too high a risk of them being found out.
So there is a pattern. And the Snowden documents confirm it.
Now an example where I am highly suspicuous of sabotage:
- systemd: It follows the example of IPv6 by violating KISS.
It creates a high level of unneeded complexity, by doing
a lot of things that should have been done seperately, just
like for IPv6, thereby making it a lot more prone to
vulerabilities to exploit by the NSA (and others). It sits
at a central control position and is implemented in C, giving
it at least some level of obfusction, especially compared to
the set of smaller shell-scripts used before. Just like for
RDRand there is high pressure being applied to variopus people
to make it the one thing to use and to drop all alternatives,
an in fact to make it hard to use any alternative.
There are more similarities with other NSA sabotage efforts
and, at least to me, there is a high likelihood it is sabotage
with the intent to make Linux easy to attack.
The problem here is, AFAIK, there is no known NSA involvement
with systemd at all, just the same as with RDRand. It is however
quite probable the NSA has gotten more careful and views hiding
its involvement as critical part of sabotage efforts by now.
So shying away from everything you know the NSA touched does
not make you more secure and it may make you miss out on some
security that is actually good. The way to do this instead is
to look for the tell-tale signs of sabotage: With IPv6,
Dual_EC_DRBG, RDRand, systemd, they are strong. For anybody
security-concious, the advice would be to stay away. With
SELinux, AES, the SHA family, etc. there are no telltales
I am aware of, so continue using them.
This is of course not a sure-fire thing. You may mis-detect
things as possibly sabotaged that are merely incompetently
designed, for example RDRand or systemd. But if you want
to be secure, you should stay away from incompetent design
anyways, so it _is_ good advice.
Personal side-note: Thomas Bächler may respond to this
because I say bad things about systemd. After a series of
cheap emotional manipulation attempts from him via email
that reek of having spawned from the NSA and GCHQ "How
to manipulate people on the Internet" documents that became
public just a few days later, I am not talking to him
anymore and hence no responses from me to him will be
forthcomming. Just in case anybody wonders.
> > The only thing we can try to do heres is to
> > explain, as, e.g., FAQ Item 5.20 "LUKS is broken! It uses SHA-1!"
> > tries to do.
>
> I guess this is not sufficient, unless this is supplemented with a
> clear statement on why they should trust something produced by the
> NSA. That the recent attacks on SHA-1 are not relevant for
> LUKS/dmcrypt is not the point, people understand that.
Sorry, but from my observations people do not understand that
at all. And it is not only the recent attacks, SHA-1 would
have to have a very gross fundamental vulnerability to be a
security issue in LUKS. It is unlike to have that, the NSA
does not want a smoking gun found that points to it.
There is also a second problem here: I am a competent user of
cryptology, I am not a cryptologist. There are not too many of
those around. Even for the absence of a gross vulnerability in
SHA-1 I have to rely on what the academic crypto community says.
From the voiced early suspicions against Dual_EC_DRBG, I conclude
they have not all been compromised.
And there is a third problem: If I say "trust me, even if the
NSA has made SHA-1 less secure, LUKS is still good.", the problem
is the "trust me". The NSA has managed to corrode the very fabric
of society in a way no concentrated terrorist campaign could
ever have hoped to by eroding fundamental trust. The best I can
do is to give all the facts as I have them and tell people to form
their own opinion.
Incidentally, that is what I did before the NSA's treason
against humanity became known. There should always be independent
verification, even if only by a few users.
> SHA-x is produced by the NSA, that's the problem.
> It's a matter of belief, not
> facts. The whole Snowden case and all the articles, reports and other
> media accompanying it shaped an overall statement: "You can't trust
> the NSA". I guess the problem lies right here. And that is why people
> choose e.g. whirlpool over the defaults.
And that is the wrong approach. Even if you cannot trust the
NSA, compromising crypto-hashes by design in a non-obvious (!)
way is very hard, as is, for example, compromising block-ciphers.
For LUKS, the usage makes it a lot harder still.
> There are many well-known theories and models which try to explain
> and/or predict such behaviour, see e.g.
>
> http://people.umass.edu/aizen/tpb.diag.html
Yes. I understand that. The only thing I can do is to
say "you are doing it wrong" and to try to explain why.
And for those that have already shot themselves in the
foot to help them recovering from it.
I do know that there is no way to prevent some class of
people from panic-reactions, and I also do know that
triggering these panic reactions is something done by
highly competent attackers as amatter od routine. Hell,
it es even used widerly in politics and advertizing and
almost never fails to deliver.
Arno
> (I for myself am quite comfortable with the defaults, because the only
> purpose of encryption for me is to protect my data on my laptop in
> case it gets stolen, and the defaults run fast on that machine. I do
> not worry if the NSA has put a backdoor in SHA-1, because it would
> hardly ever happen that the thief who stole my machine has that
> insider knowledge to use it. So I consider my data to be safe in case
> my machine gets stolen, and that's all I want.)
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. - Plato
next prev parent reply other threads:[~2014-03-02 15:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 14:39 [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4 Milan Broz
2014-02-27 17:30 ` Thomas Bächler
2014-02-28 7:51 ` Milan Broz
2014-02-28 11:29 ` Milan Broz
2014-02-28 11:38 ` Arno Wagner
2014-02-28 21:26 ` Sven Eschenberg
2014-02-28 21:46 ` Arno Wagner
2014-02-28 22:06 ` Sven Eschenberg
2014-02-28 23:27 ` Arno Wagner
2014-03-01 7:39 ` Sven Eschenberg
2014-03-01 8:35 ` Milan Broz
2014-03-01 11:32 ` Sven Eschenberg
2014-03-01 16:50 ` Heinz Diehl
2014-03-01 19:44 ` Arno Wagner
2014-03-02 7:35 ` Heinz Diehl
2014-03-02 15:17 ` Arno Wagner [this message]
2014-03-01 13:50 ` Arno Wagner
2014-02-27 21:44 ` Heinz Diehl
2014-02-27 22:36 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140302151702.GA12912@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.