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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
