> From: discuss-bounces+blu=nedharvey....@blu.org [mailto:discuss- > bounces+blu=nedharvey....@blu.org] On Behalf Of Tom Metro > > Uses closed-source, proprietary software. Nullifies the first point.
Disagree. Both windows and mac are closed-source OSes, which provide standard crypto libraries to the application layer. The fact that your OS is closed source immediately nullifies your above nullification argument, because it's literally impossible for you to run a completely open source stack, unless you switch to a different OS. More: While we all agree that more eyes and more scrutiny (open source) are good for security of a crypto library, the honest truth is, it's more *trained* and dedicated eyes that matters. And you can only count the ones who want to help. The flip side is that the bad guys also get the open source, and sometimes they keep their discoveries secret. The honest truth is, flaws exist in both open and closed source. Some of each are great. Some of each are crap. Some were accidental, and some were planted by the NSA coercing Linus (or whoever). As a software developer, who develops closed source software that does (amongst other things) encryption and transport of user files, I can say this: I scrutinize all the open and closed source libraries and applications that I use. I care greatly about using them correctly, and ensuring strong crypto to the best of my abilities. It is *appalling* how often I look at open source, as well as closed source stuff, and determine that it's bad crypto. This should be a separate thread, but I'll name a few examples, both open and closed source: To encrypt files or communications, using standard RSA, ECDH, SSL, AES libraries, it literally makes no difference if you're using open source or closed source libraries. Because they're functionally equivalent. We use .NET and Mono (amongst others) so half of that is open and half of it is closed. But the code they run is literally identical on the open & closed stacks, and the communicated and stored results are binary equivalent to each other regardless of the open or closed stack. The only thing that matters is correctly using strong crypto random, and correct usage of the standard libraries, whether they be open or closed. In closed source, it might be tempting to just instantiate .NET SslStream, because it handles everything with the SSL connection, all into a single method call. (Well, two or three, but really simple.) And the appalling insecurity there comes if you don't bother scrutinizing its selection of algorithms and key strengths. In every version of .NET, all the strong libraries are available - SHA256, RSA 2048/3072, ECDH 256, 384, AES 256. And I've benchmarked them all and there's literally no reason not to use them. Yet, when you instantiate an SslStream, the strength of your crypto depends on your platform. XP defaults to md5 and RC2 or something like that. Vista, I think, defaults to RSA 1024, which you could crack with a laptop by brute force. And win7, win8, default to SHA1 and AES 256 or 128. In open source, Truecrypt is one of the appalling ones. As far as I can tell, everything in their code is strong, except one: Your password. The way it *should* be is that your password is salted and stretched with a workfactor that effectively rate-limits brute force attacks to guess your password. Something on par with 1 password per second would be reasonable, so you could use a 4-words (44 bit entropy) human memorizable password such as correct-horse-staple-battery, and withstand a brute force attack. KeePass does the best I've seen in open source - They give you a "1 sec" button to click, to set the number of iterations in your workfactor. Of course by default, they have 16K iterations, and most people won't think to click the "1sec" button or understand what it does or why it's important... But I like to cite it because it's the only product I've seen that gives you that option explicitly and makes a conscious decision to be good. On my laptop, 1sec yields aroun d 10 million iterations. But Truecrypt is hard-coded to something around 16K, which is nothing. So any fool can brute force your Truecrypt volume, unless you are using (as Truecrypt officially recommends) a minimum of 20-char randomly generated password that you memorize. Note: What most people consider to be strong passwords are not at all strong, because they're subject to sorting of the brute force guesses according to frequency of occurrence of letters in the English language and so forth. Your password must be randomly generated by a computer or dice or something, and then your minimum length must be around 20 to keep Truecrypt secure. I see code examples out there on the internet, where people say things like ... Talking about bouncycastle ... "Use new SecureRandom()" as the supposedly secure random number generator... But this returns a mere 8 bytes, seeded by the system time. So if somebody were to capture your encrypted data, it would be trivial (well, at least straightforward) to brute force the range of time when the encryption occurred, in order to find the random seed that was used for encryption. You may have a timestamp that's accurate to a second or a couple of seconds. You may guess that the system clock is a few seconds out of skew with your own, and at 10m ticks per second, you'll have a grand total of 100m seeds you need to guess by brute force, in order to break the crypto. And as I mentioned above, my laptop can do approx 10m iterations of one rijndael library per second. So the crypto can be broken in a few minutes. And even if you didn't know the time, you've only got 8 random byt es, so your attack will be scoped to a maximum 2^64, which is doable again, with a laptop. Albeit perhaps several weeks with a laptop. See this site? http://protectedtext.com Sounds like protected sex. Now you'll never forget the name. Open source, client side encryption. An IT colleague (but not crypto expert) told me he was going to start using them to store some of his secrets, so I went ahead and read their source code for him. They use strong crypto libraries client-side: AES 256, SHA 512. But they use your password *directly* as the key to AES-256, and no workfactor. Which means, as described above, you have strong security *only* if you use a password complexity that's generally beyond human memorizable. Crypto random numbers: It's actually very easy to generate strong crypto random, given the existence of strong crypto hash algorithms as the basis for prng libraries. You take some prng library, and you continually feed it all the hardware entropy you can find. But is that what the linux kernel does? No way! (Disclaimer: I haven't looked into this myself, but I read a whitepaper on it by a security consultation firm a couple years ago, and settled on a simple workaround that makes it so I don't need to dig any further into it.) The linux kernel uses one of the most confusing, convoluted, undocumented huge bloated RNG codes ever written. And supposedly influenced by the NSA. I read all of this *before* anything related to Snowden, which makes it more plausible in my mind, a little lower probability of it being simple NSA FUD. Fortunately, if you're like me, a software developer who cares about security and wants to distrust the OS RNG crypto service, I don't need to know or care if the OS crypto library is good at all. It goes like this: Consider the case of a stream cipher, or one-time pad. You have supposedly random data, that you XOR with your plaintext, and your ciphertext is absolutely perfectly obfuscated, unless an attacker is somehow able to discover your random stream. The result of this is: Even if you have 100% predictable data, such as a simple repeating pattern, when you XOR it with random data, then the output is indistinguishable from random. So if you distrust your OS crypto random service, all you have to do is collect more than one source of crypto random, and XOR them together. Even if the OS crypto service was completely swiss cheese, you will have strong crypto random, as long as *any* of your sources were strong. The only caveat is that you must take care not to collide two crypto random sources that are related to each other... For example, if there is Foolib, and Barlib, that both poll the same hardware and apply the same transform, then they'll output the same output, and when you XOR them, you'll get a stream of 0's. It's easy to avoid this type of problem. Take one stream from the OS. Take another stream from something like bouncycastle SecureRandom. Take another stream from a prng that you seeded with a hard-coded value that you randomly generated once and kept at least somewhat hidden. Take another stream using a different algorithm (sha1 vs sha256 or whatever). Do a little bit of your own hardware sampling, and feed it into your own prng. As long as *any* of these sources was strong random, then your end result is strong random. For most purposes, I am comfortable using the closed source OS crypto stream, XOR'd with any other standard open source crypto stream (such as bouncy castle), XOR'd with a prng that I seeded myself and made at least minimal efforts to obscure the seed. I distrust the OS crypto rng in every platform that I develop on. Particularly Windows, Linux, Mac. I think this point has been driven long enough. Moving on: > A cloud storage service should have these characteristics: > > 1. use strong client-side encryption. > > 2. use fully open source client code. If developed by a commercial > entity, then there should be an independently developed open source > client available. If you distribute the client open source, then there's nothing preventing someone from developing an open source server to go along with it, thus undermining your business model. There are plenty of solutions for which the open source business model doesn't hold. _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
