12 ms·

Why I don't touch crypto

77 points by fs111 13y ago

area51org 13y ago
This point bears repeating every so often: cryptography is difficult, and those of us who haven't spent years in its mathematical bowels are not qualified to create usable algorithms. Meaning: the encryption code you wrote yourself is probably hackable. Easily hackable. I first encountered this in a classic essay by PGP's Phil Zimmerman: http://www.philzimmermann.com/EN/essays/SnakeOil.html http://www.philzimmermann.com/EN/essays/SnakeOil.html edit: fix incorrect link
- stcredzero 13y ago
  It's not just algorithms. Implementing the algorithms securely is also hard. Even using libraries implementing algorithms is hard. Actually, most problems are at the security protocol level. Implementing those is the hardest.
  - area51org 13y ago
    Excellent point; I wish I'd thought to mention that. I spent a few years as a CISO, and honestly, I know that I really want anything to do with the security industry again, outside of making sure that systems and apps are as secure as I can make them. Why? Because security is a lot harder than most people recognize. Blowfish is an excellent symmetric encryption algorithm, but, as you say, it would be easy enough to implement it badly and end up with insecure, trusted code.
    - tptacek 13y ago
      Blowfish is not an excellent symmetric encryption algorithm. For instance, it has a 64 bit block size, which makes it riskier to use in CTR mode and makes some ciphertext malleability problems easier to exploit.
      - area51org 13y ago
        Shows you what I know. :-) I assumed because Schneier created it ...
- danielweber 13y ago
  Crypto is in two states: broken, and not yet broken. I'm reminded of Yeats: The best lack all conviction, while the worst Are full of passionate intensity. Anyone confident in their crypto is dangerous.
- 23david 13y ago
  Great link! The takeaway for me is that in an ideal world we would be able to use only strong peer-reviewed crypto written by programmers experienced in codebreaking and cryptanalysis. Phil Zimmerman admits in that article that this is his ideal standard and yet his own PGP software doesn't meet his ideal. So we're in a situation where we have to make imperfect choices. Is there any reliable guide that discusses the current best practices in securing things like ssh, VPN, etc? I get the feeling that the preference of many of the infosec professionals on HN is that a properly configured SSH tunnel is the only secure way to communicate between machines on the Internet. ( IPSec VPN connections I guess are weaker?) So just use stunnel or autotunnel? Tunneling traffic imo seems like an inelegant hack, but are there any crypto libraries that are reliable? Crypto is hard, but to be fair it's also not easy to figure out what crypto to use if you want to rely on external libraries or systems like SSH.
schrodingersCat 13y ago
"Crypto can't be a «bit broken». It can't be «mostly working». Either it's 100% correct, or you shouldn't have bothered doing it at all. The weakest link breaks the whole chain." I completely agree. Ever seen a password hash mega-post on paste-bin? Bought to you by bad crypto. Saying "I don't know" is one of the hardest things to do, and also one of the most powerful. I applaud you for knowing your limits in this regard. I like to say crypto is like surgery, best left for the experts. You never want to "I kinda messed up that triple bypass," because there are major consequences for it. The same is true for virtually all aspects of cryptography. Thank you for this post! Edit: Here a link to a blog post that was discussed recently on HN that is pertinent: http://www.daemonology.net/blog/2013-06-17-crypto-science-not-engineering.html http://www.daemonology.net/blog/2013-06-17-crypto-science-no...
- bhitov 13y ago
  I disagree. You could, for example, unintentionally lose entropy without entirely breaking your crypto.
kGrange 13y ago
There ought to be a good set of FOSS unit tests for those who dare implement their own crypto. For instance, you let it hook in to your PRNG, and it'll tell you if the output is random-looking enough. It wouldn't be a panacea for bad crypto, and it does create a risk of people thinking "oh, it passed all of the tests, it must be secure," while still implementing it overall incorrectly. But I still think it would mitigate these "foolish/easy" errors and allows devs to focus on proper overall implementation. Or does something like this already exist?
- lambda 13y ago
  http://dilbert.com/strips/comic/2001-10-25/ http://dilbert.com/strips/comic/2001-10-25/ The problem is that it's really hard to write unit tests to determine if you've gotten the crypto right. For one, the unit tests would have to have a standardized interface to your cryptographic protocol. But if you're using a standard cryptographic protocol, why would you be rolling your own implementation instead of using an existing, well tested and vetted one? Second, it's quite difficult, in an automated way, to look for the kinds of security vulnerabilities you would need to audit. Timing attacks may show up in different places for different software. Poorly seeded entropy is quite hard to detect; Debian systems were generating keys with only about 16 bits of entropy for years, which is enough that it's hard to detect in an automated way unless you are really looking for that specific breakage but is a devastating security hole. You may have bugs that are not crypto related at all but simple buffer overflows or the like. And so on. You could probably automate some of it. But on the whole, you need many good, experienced people regularly auditing the code. And it's a lot easier to get that by using an existing, widely used and widely audited library than by rolling your own.
- pbsd 13y ago
  If you're only worried that your PRNG doesn't look random, there's TestU01: http://www.iro.umontreal.ca/~simardr/testu01/tu01.html http://www.iro.umontreal.ca/~simardr/testu01/tu01.html However these are just statistical tests; they tell you nothing about how much actual entropy you're actually getting (cf. Debian). That said, it probably would have caught the Cryptocat bias.
  - 13y ago
stcredzero 13y ago
It's not just a matter of perfection in the field of programming. It's an entirely different field that happens to involve some of the same things and ideas. Just because you're a driver, it doesn't mean you're a qualified mechanic, and if you're a mechanic, it doesn't mean you're a forensic crash investigator. They are related in terms of subject matter, but they are not equivalent skill sets. As programmers, we are dealing with interfaces and movement/copying of data. Security deals with epiphenomenal leakage of access and data. It is not programming, though it involves programming.
tstactplsignore 13y ago
Why on Earth did the Cryptochat guy write his own cryptography functions in the first place? Couldn't he have used the Stanford crypto JS library?
- oinksoft 13y ago
  The inexperience and hubris of youth. We all have this to varying degrees, but those entirely new to the field for whom it is their first profession have it in spades (that's both a gift and a curse; great things are built by "naïve" trailblazers).
- tptacek 13y ago
  SJCL would have been helpful but still isn't a complete solution to the (exceptionally difficult, even for cryptography) problems they chose to tackle.
gravitronic 13y ago
Good, because you can't even spell it in your title.
santosha 13y ago
These aren't good reasons to not touch crypto, these are good reasons to not cook up your own. Use a standard implementation, and move along.
- dclusin 13y ago
  These also seem like good reasons not to use proprietary/closed source solutions. At least with cryptocat everyone know knows about the security issues now and take precautions as if their entire encrypted communications have been compromised. With proprietary solutions you have to rely on an honor system where you hope the vendor tells you there is an issue.
  - npsimons 13y ago
    Relevant: https://www.schneier.com/crypto-gram-9909.html#OpenSourceandSecurity https://www.schneier.com/crypto-gram-9909.html#OpenSourceand...
noonespecial 13y ago
The thing about crypto is that nobody can get it right the first time. It requires two things that most programmers have in relatively short supply. Radical transparency and radical humility.
- ww520 13y ago
  Agree 100%. Humility is especially a hard lesson to learn.
- tptacek 13y ago
  I mentioned on another crypto thread the frustrating fact that more than one professional crypto friend of mine is working on designs that could replace PGP, not to mention a lot of terrible ad hoc app crypto --- but because they're pro's, they're uncomfortable sharing designs until they're confident that they've fully validated them. That's what humility looks like: knowing you're an industry leading expert at cryptographic design and still waiting months or even years to publish so you can make sure you got things right. Compare and contrast.
taway2012 13y ago
This is not really the most insightful comment, but anyway. I found the article to be needlessly defeatist. I am not a crypto expert. I've read Practical Cryptography and have a lots of experience with software engineering in general. This article (yet again) loosely says "crypto" without specifying whether he's talking about "crypto protocols" or "crypto primitives" (I use "protocol" in a theoretical sense: saving a file piped through gpg with passphrase rememembered in memory constitutes a protocol). It's well understood that mere mortals shouldn't create "crypto primitives". But I would argue that we're soon going to reach the point where many software engineers will have to understand crypto protocol creation. Just like many software engineers in the past 10 years or so have had to become aware of multicore (NoSQL, horizontal scaling, Go/Rust concurrency, probably even async callbacks in Javascript etc are all different aspect of multicore, imho). I don't think we as a profession should abdicate our responsibility to store/transport data securely by just saying "crypto is hard; so don't do it". I also take issue with the claim that crypto code is either 100% working, or 0% working. From a crypto theory point-of-view, yes, that is how cryptographers think. But in practice, there is a VAST difference between an attack that requires 2^32 INTERACTIONS with a remote server and one that requires 2^32 COMPUTATIONS on the attackers machine. A cryptographer would say both attacks are equally easy (kinda like O(n) notation). Just my two cents. And finally, re: the RNG vulnerability in Cryptocat, that is very bad and just sloppy coding. But even that vulnerability required that the attacker compromise the private SSL key of cryptocat's server. Defense in depth FTW.
- tel 13y ago
  I don't think practical cryptographers ignore the difference between computations and interactions—there are different threat models and they are carefully studied. Part of the problem might be that a system designed to be safe against 2^32 interactions is deployed in a place where the system is vulnerable to attacks on the order of 2^32 computations. The problem I think the author is highlighting is that the mistake risk distribution is hard to understand. Some kinds of off by one errors may cause relatively small reductions in security margins. Some kinds may cause complete loss of system integrity. It's hard to distinguish between the two without extensive testing and expertise. Furthermore, the kind of user who would never tell you about your error is exactly the kind who will find it. Finally, loss of your security infrastructure is unlikely to cause just small visual discomfort to your users—it's likely to hurt them materially.
thewarrior 13y ago
So how does one go about writing crypto ?
- NegativeK 13y ago
  Assuming you're talking about implementing, and not using preexisting, vetted libraries: Spend a long time in the community. Listen closely to the people who have a good reputation. Have your code publicly vetted before it's ever used. Expect your code to be torn apart.
davidw 13y ago
All these "crypto.... scary!" things are right of course. But somehow tiresome. They're ripe for satire... something involving Chuck Norris being the only one perfect enough to encrypt stuff, just as he's able to compress random data. 100%. With his biceps.
- deleted 13y ago
  [deleted]
- obituary_latte 13y ago
  http://www.schneierfacts.com/facts/623 http://www.schneierfacts.com/facts/623
- Shank 13y ago
  I would agree, but for something as important as cryptography, I would prefer people error on the side of too cautious or repetitive if it means less people making the same mistake twice. It's the same reason why I don't mind repeated HN submissions if it's a good enough delay - the discussion was clearly relevant the first time, and new people have joined the community since then and deserve an equal chance to talk about the subject with new perspective.
  - zalambar 13y ago
    Caution is a good attitude to have when working on critical code with non-obvious modes of failure. However I agree with davidw; this "dont' touch it" or "we're not smart enough" attitude is tiresome. Couldn't we instead admit that this is a difficult problem which requires some engineering rigor to solve well and talk about how we can address such problems like professionals instead of hiding from them?
    - tptacek 13y ago
      Most people don't actually want to do their own surgery. Even if you put a scalpel in someone's hands, and gave them all the anesthesia, they still wouldn't be tempted to remove someone's appendix after reading an eHow article about it. The same isn't true of crypto. People know both intellectually and viscerally that they shouldn't be doing their own surgeries. But they only have an intellectual understanding that crypto is unsafe. A big part of that is because the harm caused by crypto mistakes are often an externality to the developer.
graham_king_3 13y ago
That attitude to crypto is pervasive, annoying, and wrong. We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography. Every developer needs to touch crypto. Encrypted communications needs to be our default. And yes, of course, we should prefer verified, standard algorithms (NSA Suite B, for example). It's OK to get it wrong, it's OK to fail forward, even with cryptography. ROT13 will protect you very well, if your attack vector is someone glancing over your shoulder for 1 second. As long as the code is open, and you're honest about what it does, you've made people a little bit safer. There's a fair amount of gloating around Cryptocat, but it protected people's communications from me, because I didn't know how to break it. So that's better than nothing.
- EthanHeilman 13y ago
  >We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography. We shouldn't, but we should provide tools that allow software engineers to securely design applications without having to be crypto experts, in much the same way I can write python code without being a kernel hacker. Two examples spring to mind: Authenticated https api calls and bcrypt. These both work securely without requiring deep knowledge and they are so easy to setup it is unlikely someone will roll their own.
- josephlord 13y ago
  You can PLAY with crypto, discuss it try things out and have fun with it. After you have been doing that and hanging out in the right circles for a few years, reading lots and probably breaking other people's ideas and implementations not just yours then you will be some sort of position to judge whether your work may be safe to unleash on the public as anything more than a low security experiment. One of the problems is with security and crypto is that the people who really understand it make fairly weak promises such as that it is "Pretty Good Privacy" but the incompetent, greedy or malicious make strong marketing claims about the security that they are offering. Emphasis on incompetent in the Cryptocat case. Crypto is an area where the Dunning Kruger effect[1] seems both especially strong and especially dangerous. [1] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
dobbsbob 13y ago
Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin. Also good thing the Truecrypt devs weren't scared of it, or the Debian devs, or the OpenBSD devs and others who gave us OpenSSH. Moxie Marlinspike doesn't seem to be scared of it either. According to him it's not impossible to learn simple, tried and true methods for crypto engineering that are all spelled out in Schneier's books and various white papers. These standards were completely ignored by the cryptocat guys (and ignored repeated warnings from auditors). So if you can read, comprehend and do bare minimum research of NIST standards you're pretty safe rolling your own crypto software if you know about attention to detail, the doom principal, PRNGs and their flaws, and know not to attempt to make your own primitives. If you guy's can push out incredibly complex and relatively secure financial trading software there's no reason you can't roll your own SHA-256 on your Android phone replacing SHA-1 FDE or even design Redphone like Moxie did. Would also help if you hung around hashcat forums, read Schneier's cryptogram newsletter, and watched some lectures about software crypto engineering.
- betterunix 13y ago
  "Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin." ...a system for which there is no security definition, no security proof, a known polynomial time attack (for some vague notion of "attack"), etc. I do not think this is the best example you can come up with. One of the problems here is that cryptography cannot just be cobbled together from component pieces. Things do not always compose securely. Bitcoin is not a signature system, so even if the ECDSA implementation is perfect it does not guarantee that Bitcoin is secure. One of the things that makes cryptography, especially in the public-key setting, difficult is the very precise assumptions and very precise definitions of security; it is easy to make an assumption that is not implied by a security definition, and very easy to violate a key assumption without even realizing it. Worse, cryptosystems must be composed with other software, and such compositions can be insecure (which is basically what happened with Skype). It's not that people should be scared away. Rather, we need to develop better tools that help programmers catch or avoid these kinds of bugs.
- dfc 13y ago
  Satoshi is more than likely one or more individuals with significant crypto experience. Open{SSH/BSD/SSL} developers have significant crypto experience. Don't get me wrong I am a huge Debian fanboy, but how much crypto code do Debian developers write?
betterunix 13y ago
I have said this before, but what we really need is the equivalent of SQL for cryptography. We need a language that can be used to describe what kind of security is needed from a cryptosystem and a compiler to turn that into code. It is not just that cryptography is hard to implement; it is also easy to use it incorrectly, compose it poorly with other systems (see the Skype attack), etc.
- dfc 13y ago
  I recently skimmed a giant manuscript about the creation of a language for defining cryptographic requirements and primitives (120ish pages). I seem to recall that the author was either from Stanford and/or had a name that begins with a "P". I wish I had saved the citation. Hopefully someone else will be able to recognize what I am referring to with my shoddy reference.
  - pbsd 13y ago
    That does sound like CAO [1,3,4], from the CACE [2] project. [1] https://eprint.iacr.org/2005/160 https://eprint.iacr.org/2005/160 [2] http://www.cace-project.eu/ http://www.cace-project.eu/ [3] http://www.cace-project.eu/downloads/deliverables-y2/CACE_D5.2_M18.pdf http://www.cace-project.eu/downloads/deliverables-y2/CACE_D5... [4] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113...
- tptacek 13y ago
  Why do you think that would be more valuable than something like Nacl?
loup-vaillant 13y ago
When you can't have bugs, you can have proofs. While unknown angles of attack can exists, it is still possible to prove that the known ones are closed. This is going to be costly…
16s 13y ago
I wrote some "home made" crypto about a year ago. It's a one-time pad implementation. http://16s.us/FreeOTP/nsa/ http://16s.us/FreeOTP/nsa/ The math behind OTP is pretty simple, but I may have made a mistake. I've posted the source code to crypto forums, HN, wilders security and emailed it to several prominent crypto developers/experts. No one seems to care nor want to look at it in-depth. I've worked as a dev where we encrypted research data using standard, industry-accepted crypto (RSA and symmetric AES, etc) as well. Having said that, I'm not an expert. And the real experts (Bruce Schneier) won't verify anything. They just say, "It's not been broken yet, which is a good indication." Dive in and write some crypto code. Do it and make mistakes. That's how you learn. Not every program is life or death/mission critical. And if you never do it, you won't learn how. We learn by making mistakes. Tarsnap is nice crypto code if you like C. It's easy to read too. I have no relation to Colin Percival or tarsnap. He's an expert, and even he makes mistakes: http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
- jessaustin 13y ago
  No one seems to care nor want to look at it in-depth. I'm not an expert, but I wouldn't look at an OTP implementation either. Key management is already hard enough. It's hard to imagine a useful system you could build on a one-time pad.
  - 16s 13y ago
    Anyone wanting to learn more about information theory, decrypting to multiple plaintext messages or unbreakable encryption would find it interesting. OTP is an edge case and it does not scale (I understand that), but is useful for small messages between two parties when privacy is paramount. Government states have used it. Also, I can't find any other OTP source code that compiles and works.
    - jessaustin 13y ago
      Sure, learning is good. Any introductory crypto class would consider OTP for a bit. But you seem to be asking people to critique the system as if it would be used for a non-educational purpose. (If that's not what you mean I apologize for misunderstanding.) That just seems really unlikely.
pnathan 13y ago
I don't like this attitude. It's really anti-hacker. Of course, the world is littered with cryptosystems that some foo thought would be secure and wasn't. XOR isn't encryption. ;) I would suggest that hackers interested in crypto take a sober and unafraid look at the history of crypto and then spend time breaking ciphers, "hacking" in all senses of the word. Read the crypto papers and work on the advanced math until you really and truly grasp "all the things". Pour those 10K hours in.... Crypto is hard. Doing it mostly right requires humility and hard study, and then you have a good chance of being wrong. Nothing to be afraid of if you understand the situation and understand the years and years it takes to really become good at it...
mistercow 13y ago
I feel kind of divided about using the Cryptocat as an example. On the one hand, yes, off-by-one errors (and similar simple mistakes) are really easy to make if you you're writing something with low feedback. But the Cryptocat example is frustrating because the code is so bad. Not in a "poorly written" sense, but in a "going about things in a completely insane way" sense. The code generates a random number between 0 and 1 not by dividing a 53 bit random number by 2^53, but by generating 16 decimal digits, with the rationale that 2^53 ≈ 10^16. If the code hadn't been trying to do the wrong thing in the first place, there wouldn't have been an opportunity for that off-by-one error. My point isn't that you'll be protected from simple classes of errors as long as you're coding sanely, but rather that that is the lesson you teach if you point to Cryptocat as your example. Crypto is hard, but you can't make that point very well by pointing to code written by someone who doesn't know the correct (and incredibly standard) solutions to common non-crypto problems.
lectrick 13y ago
He clearly doesn't touch unit tests, either, or he'd know that they would address ALL (as in, 100%) of his concerns here. Crypto is even easier to test than 99% of things... all you have is a couple of inputs, and an output. Boom, test cases.
- ethereal 13y ago
  I'd just like to point out that `cryptography' is _not_ just about testing that `decrypt(encrypt(msg)) == msg`. memfrob'ing a region of memory does this, but would we consider that a 'secure' encryption scheme? I don't think so . . . Even if it was -- how do you unit-test a PRNG to ensure the output is uniformly random? How do you ensure you don't have collisions in a hash function? How can you ensure that there's no replay attack on your protocol? How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma? These are all very real and valid cryptography concerns. Sorry if this sounds snarky, but in all seriousness -- I'm very curious as to how you would unit-test these.
  - contingencies 13y ago
    how do you unit-test a PRNG to ensure the output is uniformly random? NIST standard test suite @ http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_sof... How do you ensure you don't have collisions in a hash function? All hash functions have collisions, by definition, since they represent a unique checksum of a large amount of data in a smaller keyspace. What you are really asking is probably "how do you prove that you have difficult to predict collisions"? I don't know. (I assume that the mechanisms for doing that are based upon statistical analysis of the propagation breadth and speed of various single bit changes in the input stream over varying numbers of rounds?) How can you ensure that there's no replay attack on your protocol? A combination of session keys and message sequencing? (eg. Each message must include a hash of the last.) How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma? There's an entire field of computer science around formal proofs; I don't know enough about it to really comment, however a partial answer may lay in there. Essentially that means adopting a design-time proof strategy in your testing rather than a post-facto unit-testing proof strategy, though.
billforsternz 13y ago
The article implies that the off-by-one error in the Cryptocat random number generator is catastrophic. Correct me if I am wrong, but surely that is hardly the case. The random numbers generated are a tiny bit less uniformly distributed than they would be without the error. That's an imperfection but does it have any practical consequences at all ? I know that flaws like this can introduce weaknesses that are vulnerable to attacks, but my intuition tells me this flaw is very close to the "doesn't matter" end of the catastrophic->doesn't matter spectrum. I am more than willing to be educated by someone with specialised domain knowledge.
pasquinelli 13y ago
"Writing a testcase for this would have required complicated thinking and coding which would be as likely to contain an error as it was likely for the code to be tested to contain an error." i don't know the details, by why couldn't you just collect a million bits of supposedly random data from the generator and run it through the nist test suite? it's true that testing for randomness does require complicated thinking, but fortunately it's been done. standing on the shoulders of giants and whatnot.
motters 13y ago
But if few people bother themselves with encryption code then there are not many eyeballs on it and mistakes or backdoors become more likely. Probably encryption code should not be left entirely to the "experts" at NSA, Microsoft, etc.

77 points by fs111 13y ago

This point bears repeating every so often: cryptography is difficult, and those of us who haven't spent years in its mathematical bowels are not qualified to create usable algorithms. Meaning: the encryption code you wrote yourself is probably hackable. Easily hackable. I first encountered this in a classic essay by PGP's Phil Zimmerman: http://www.philzimmermann.com/EN/essays/SnakeOil.html http://www.philzimmermann.com/EN/essays/SnakeOil.html edit: fix incorrect link

stcredzero 13y ago
It's not just algorithms. Implementing the algorithms securely is also hard. Even using libraries implementing algorithms is hard. Actually, most problems are at the security protocol level. Implementing those is the hardest.
- area51org 13y ago
  Excellent point; I wish I'd thought to mention that. I spent a few years as a CISO, and honestly, I know that I really want anything to do with the security industry again, outside of making sure that systems and apps are as secure as I can make them. Why? Because security is a lot harder than most people recognize. Blowfish is an excellent symmetric encryption algorithm, but, as you say, it would be easy enough to implement it badly and end up with insecure, trusted code.
  - tptacek 13y ago
    Blowfish is not an excellent symmetric encryption algorithm. For instance, it has a 64 bit block size, which makes it riskier to use in CTR mode and makes some ciphertext malleability problems easier to exploit.
    - area51org 13y ago
      Shows you what I know. :-) I assumed because Schneier created it ...
danielweber 13y ago
Crypto is in two states: broken, and not yet broken. I'm reminded of Yeats: The best lack all conviction, while the worst Are full of passionate intensity. Anyone confident in their crypto is dangerous.
23david 13y ago
Great link! The takeaway for me is that in an ideal world we would be able to use only strong peer-reviewed crypto written by programmers experienced in codebreaking and cryptanalysis. Phil Zimmerman admits in that article that this is his ideal standard and yet his own PGP software doesn't meet his ideal. So we're in a situation where we have to make imperfect choices. Is there any reliable guide that discusses the current best practices in securing things like ssh, VPN, etc? I get the feeling that the preference of many of the infosec professionals on HN is that a properly configured SSH tunnel is the only secure way to communicate between machines on the Internet. ( IPSec VPN connections I guess are weaker?) So just use stunnel or autotunnel? Tunneling traffic imo seems like an inelegant hack, but are there any crypto libraries that are reliable? Crypto is hard, but to be fair it's also not easy to figure out what crypto to use if you want to rely on external libraries or systems like SSH.

schrodingersCat 13y ago

"Crypto can't be a «bit broken». It can't be «mostly working». Either it's 100% correct, or you shouldn't have bothered doing it at all. The weakest link breaks the whole chain." I completely agree. Ever seen a password hash mega-post on paste-bin? Bought to you by bad crypto. Saying "I don't know" is one of the hardest things to do, and also one of the most powerful. I applaud you for knowing your limits in this regard. I like to say crypto is like surgery, best left for the experts. You never want to "I kinda messed up that triple bypass," because there are major consequences for it. The same is true for virtually all aspects of cryptography. Thank you for this post! Edit: Here a link to a blog post that was discussed recently on HN that is pertinent: http://www.daemonology.net/blog/2013-06-17-crypto-science-not-engineering.html http://www.daemonology.net/blog/2013-06-17-crypto-science-no...

bhitov 13y ago
I disagree. You could, for example, unintentionally lose entropy without entirely breaking your crypto.

kGrange 13y ago

There ought to be a good set of FOSS unit tests for those who dare implement their own crypto. For instance, you let it hook in to your PRNG, and it'll tell you if the output is random-looking enough. It wouldn't be a panacea for bad crypto, and it does create a risk of people thinking "oh, it passed all of the tests, it must be secure," while still implementing it overall incorrectly. But I still think it would mitigate these "foolish/easy" errors and allows devs to focus on proper overall implementation. Or does something like this already exist?

lambda 13y ago
http://dilbert.com/strips/comic/2001-10-25/ http://dilbert.com/strips/comic/2001-10-25/ The problem is that it's really hard to write unit tests to determine if you've gotten the crypto right. For one, the unit tests would have to have a standardized interface to your cryptographic protocol. But if you're using a standard cryptographic protocol, why would you be rolling your own implementation instead of using an existing, well tested and vetted one? Second, it's quite difficult, in an automated way, to look for the kinds of security vulnerabilities you would need to audit. Timing attacks may show up in different places for different software. Poorly seeded entropy is quite hard to detect; Debian systems were generating keys with only about 16 bits of entropy for years, which is enough that it's hard to detect in an automated way unless you are really looking for that specific breakage but is a devastating security hole. You may have bugs that are not crypto related at all but simple buffer overflows or the like. And so on. You could probably automate some of it. But on the whole, you need many good, experienced people regularly auditing the code. And it's a lot easier to get that by using an existing, widely used and widely audited library than by rolling your own.
pbsd 13y ago
If you're only worried that your PRNG doesn't look random, there's TestU01: http://www.iro.umontreal.ca/~simardr/testu01/tu01.html http://www.iro.umontreal.ca/~simardr/testu01/tu01.html However these are just statistical tests; they tell you nothing about how much actual entropy you're actually getting (cf. Debian). That said, it probably would have caught the Cryptocat bias.
- 13y ago

stcredzero 13y ago

It's not just a matter of perfection in the field of programming. It's an entirely different field that happens to involve some of the same things and ideas. Just because you're a driver, it doesn't mean you're a qualified mechanic, and if you're a mechanic, it doesn't mean you're a forensic crash investigator. They are related in terms of subject matter, but they are not equivalent skill sets. As programmers, we are dealing with interfaces and movement/copying of data. Security deals with epiphenomenal leakage of access and data. It is not programming, though it involves programming.

tstactplsignore 13y ago

Why on Earth did the Cryptochat guy write his own cryptography functions in the first place? Couldn't he have used the Stanford crypto JS library?

oinksoft 13y ago
The inexperience and hubris of youth. We all have this to varying degrees, but those entirely new to the field for whom it is their first profession have it in spades (that's both a gift and a curse; great things are built by "naïve" trailblazers).
tptacek 13y ago
SJCL would have been helpful but still isn't a complete solution to the (exceptionally difficult, even for cryptography) problems they chose to tackle.

gravitronic 13y ago

Good, because you can't even spell it in your title.

santosha 13y ago

These aren't good reasons to not touch crypto, these are good reasons to not cook up your own. Use a standard implementation, and move along.

dclusin 13y ago
These also seem like good reasons not to use proprietary/closed source solutions. At least with cryptocat everyone know knows about the security issues now and take precautions as if their entire encrypted communications have been compromised. With proprietary solutions you have to rely on an honor system where you hope the vendor tells you there is an issue.
- npsimons 13y ago
  Relevant: https://www.schneier.com/crypto-gram-9909.html#OpenSourceandSecurity https://www.schneier.com/crypto-gram-9909.html#OpenSourceand...

noonespecial 13y ago

The thing about crypto is that nobody can get it right the first time. It requires two things that most programmers have in relatively short supply. Radical transparency and radical humility.

ww520 13y ago
Agree 100%. Humility is especially a hard lesson to learn.
tptacek 13y ago
I mentioned on another crypto thread the frustrating fact that more than one professional crypto friend of mine is working on designs that could replace PGP, not to mention a lot of terrible ad hoc app crypto --- but because they're pro's, they're uncomfortable sharing designs until they're confident that they've fully validated them. That's what humility looks like: knowing you're an industry leading expert at cryptographic design and still waiting months or even years to publish so you can make sure you got things right. Compare and contrast.

taway2012 13y ago

This is not really the most insightful comment, but anyway. I found the article to be needlessly defeatist. I am not a crypto expert. I've read Practical Cryptography and have a lots of experience with software engineering in general. This article (yet again) loosely says "crypto" without specifying whether he's talking about "crypto protocols" or "crypto primitives" (I use "protocol" in a theoretical sense: saving a file piped through gpg with passphrase rememembered in memory constitutes a protocol). It's well understood that mere mortals shouldn't create "crypto primitives". But I would argue that we're soon going to reach the point where many software engineers will have to understand crypto protocol creation. Just like many software engineers in the past 10 years or so have had to become aware of multicore (NoSQL, horizontal scaling, Go/Rust concurrency, probably even async callbacks in Javascript etc are all different aspect of multicore, imho). I don't think we as a profession should abdicate our responsibility to store/transport data securely by just saying "crypto is hard; so don't do it". I also take issue with the claim that crypto code is either 100% working, or 0% working. From a crypto theory point-of-view, yes, that is how cryptographers think. But in practice, there is a VAST difference between an attack that requires 2^32 INTERACTIONS with a remote server and one that requires 2^32 COMPUTATIONS on the attackers machine. A cryptographer would say both attacks are equally easy (kinda like O(n) notation). Just my two cents. And finally, re: the RNG vulnerability in Cryptocat, that is very bad and just sloppy coding. But even that vulnerability required that the attacker compromise the private SSL key of cryptocat's server. Defense in depth FTW.

tel 13y ago
I don't think practical cryptographers ignore the difference between computations and interactions—there are different threat models and they are carefully studied. Part of the problem might be that a system designed to be safe against 2^32 interactions is deployed in a place where the system is vulnerable to attacks on the order of 2^32 computations. The problem I think the author is highlighting is that the mistake risk distribution is hard to understand. Some kinds of off by one errors may cause relatively small reductions in security margins. Some kinds may cause complete loss of system integrity. It's hard to distinguish between the two without extensive testing and expertise. Furthermore, the kind of user who would never tell you about your error is exactly the kind who will find it. Finally, loss of your security infrastructure is unlikely to cause just small visual discomfort to your users—it's likely to hurt them materially.

thewarrior 13y ago

So how does one go about writing crypto ?

NegativeK 13y ago
Assuming you're talking about implementing, and not using preexisting, vetted libraries: Spend a long time in the community. Listen closely to the people who have a good reputation. Have your code publicly vetted before it's ever used. Expect your code to be torn apart.

davidw 13y ago

All these "crypto.... scary!" things are right of course. But somehow tiresome. They're ripe for satire... something involving Chuck Norris being the only one perfect enough to encrypt stuff, just as he's able to compress random data. 100%. With his biceps.

deleted 13y ago
[deleted]
obituary_latte 13y ago
http://www.schneierfacts.com/facts/623 http://www.schneierfacts.com/facts/623
Shank 13y ago
I would agree, but for something as important as cryptography, I would prefer people error on the side of too cautious or repetitive if it means less people making the same mistake twice. It's the same reason why I don't mind repeated HN submissions if it's a good enough delay - the discussion was clearly relevant the first time, and new people have joined the community since then and deserve an equal chance to talk about the subject with new perspective.
- zalambar 13y ago
  Caution is a good attitude to have when working on critical code with non-obvious modes of failure. However I agree with davidw; this "dont' touch it" or "we're not smart enough" attitude is tiresome. Couldn't we instead admit that this is a difficult problem which requires some engineering rigor to solve well and talk about how we can address such problems like professionals instead of hiding from them?
  - tptacek 13y ago
    Most people don't actually want to do their own surgery. Even if you put a scalpel in someone's hands, and gave them all the anesthesia, they still wouldn't be tempted to remove someone's appendix after reading an eHow article about it. The same isn't true of crypto. People know both intellectually and viscerally that they shouldn't be doing their own surgeries. But they only have an intellectual understanding that crypto is unsafe. A big part of that is because the harm caused by crypto mistakes are often an externality to the developer.

graham_king_3 13y ago

That attitude to crypto is pervasive, annoying, and wrong. We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography. Every developer needs to touch crypto. Encrypted communications needs to be our default. And yes, of course, we should prefer verified, standard algorithms (NSA Suite B, for example). It's OK to get it wrong, it's OK to fail forward, even with cryptography. ROT13 will protect you very well, if your attack vector is someone glancing over your shoulder for 1 second. As long as the code is open, and you're honest about what it does, you've made people a little bit safer. There's a fair amount of gloating around Cryptocat, but it protected people's communications from me, because I didn't know how to break it. So that's better than nothing.

EthanHeilman 13y ago
>We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography. We shouldn't, but we should provide tools that allow software engineers to securely design applications without having to be crypto experts, in much the same way I can write python code without being a kernel hacker. Two examples spring to mind: Authenticated https api calls and bcrypt. These both work securely without requiring deep knowledge and they are so easy to setup it is unlikely someone will roll their own.
josephlord 13y ago
You can PLAY with crypto, discuss it try things out and have fun with it. After you have been doing that and hanging out in the right circles for a few years, reading lots and probably breaking other people's ideas and implementations not just yours then you will be some sort of position to judge whether your work may be safe to unleash on the public as anything more than a low security experiment. One of the problems is with security and crypto is that the people who really understand it make fairly weak promises such as that it is "Pretty Good Privacy" but the incompetent, greedy or malicious make strong marketing claims about the security that they are offering. Emphasis on incompetent in the Cryptocat case. Crypto is an area where the Dunning Kruger effect[1] seems both especially strong and especially dangerous. [1] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

dobbsbob 13y ago

Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin. Also good thing the Truecrypt devs weren't scared of it, or the Debian devs, or the OpenBSD devs and others who gave us OpenSSH. Moxie Marlinspike doesn't seem to be scared of it either. According to him it's not impossible to learn simple, tried and true methods for crypto engineering that are all spelled out in Schneier's books and various white papers. These standards were completely ignored by the cryptocat guys (and ignored repeated warnings from auditors). So if you can read, comprehend and do bare minimum research of NIST standards you're pretty safe rolling your own crypto software if you know about attention to detail, the doom principal, PRNGs and their flaws, and know not to attempt to make your own primitives. If you guy's can push out incredibly complex and relatively secure financial trading software there's no reason you can't roll your own SHA-256 on your Android phone replacing SHA-1 FDE or even design Redphone like Moxie did. Would also help if you hung around hashcat forums, read Schneier's cryptogram newsletter, and watched some lectures about software crypto engineering.

betterunix 13y ago
"Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin." ...a system for which there is no security definition, no security proof, a known polynomial time attack (for some vague notion of "attack"), etc. I do not think this is the best example you can come up with. One of the problems here is that cryptography cannot just be cobbled together from component pieces. Things do not always compose securely. Bitcoin is not a signature system, so even if the ECDSA implementation is perfect it does not guarantee that Bitcoin is secure. One of the things that makes cryptography, especially in the public-key setting, difficult is the very precise assumptions and very precise definitions of security; it is easy to make an assumption that is not implied by a security definition, and very easy to violate a key assumption without even realizing it. Worse, cryptosystems must be composed with other software, and such compositions can be insecure (which is basically what happened with Skype). It's not that people should be scared away. Rather, we need to develop better tools that help programmers catch or avoid these kinds of bugs.
dfc 13y ago
Satoshi is more than likely one or more individuals with significant crypto experience. Open{SSH/BSD/SSL} developers have significant crypto experience. Don't get me wrong I am a huge Debian fanboy, but how much crypto code do Debian developers write?

betterunix 13y ago

I have said this before, but what we really need is the equivalent of SQL for cryptography. We need a language that can be used to describe what kind of security is needed from a cryptosystem and a compiler to turn that into code. It is not just that cryptography is hard to implement; it is also easy to use it incorrectly, compose it poorly with other systems (see the Skype attack), etc.

dfc 13y ago
I recently skimmed a giant manuscript about the creation of a language for defining cryptographic requirements and primitives (120ish pages). I seem to recall that the author was either from Stanford and/or had a name that begins with a "P". I wish I had saved the citation. Hopefully someone else will be able to recognize what I am referring to with my shoddy reference.
- pbsd 13y ago
  That does sound like CAO [1,3,4], from the CACE [2] project. [1] https://eprint.iacr.org/2005/160 https://eprint.iacr.org/2005/160 [2] http://www.cace-project.eu/ http://www.cace-project.eu/ [3] http://www.cace-project.eu/downloads/deliverables-y2/CACE_D5.2_M18.pdf http://www.cace-project.eu/downloads/deliverables-y2/CACE_D5... [4] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113...
tptacek 13y ago
Why do you think that would be more valuable than something like Nacl?

loup-vaillant 13y ago

When you can't have bugs, you can have proofs. While unknown angles of attack can exists, it is still possible to prove that the known ones are closed. This is going to be costly…

16s 13y ago

I wrote some "home made" crypto about a year ago. It's a one-time pad implementation. http://16s.us/FreeOTP/nsa/ http://16s.us/FreeOTP/nsa/ The math behind OTP is pretty simple, but I may have made a mistake. I've posted the source code to crypto forums, HN, wilders security and emailed it to several prominent crypto developers/experts. No one seems to care nor want to look at it in-depth. I've worked as a dev where we encrypted research data using standard, industry-accepted crypto (RSA and symmetric AES, etc) as well. Having said that, I'm not an expert. And the real experts (Bruce Schneier) won't verify anything. They just say, "It's not been broken yet, which is a good indication." Dive in and write some crypto code. Do it and make mistakes. That's how you learn. Not every program is life or death/mission critical. And if you never do it, you won't learn how. We learn by making mistakes. Tarsnap is nice crypto code if you like C. It's easy to read too. I have no relation to Colin Percival or tarsnap. He's an expert, and even he makes mistakes: http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

jessaustin 13y ago
No one seems to care nor want to look at it in-depth. I'm not an expert, but I wouldn't look at an OTP implementation either. Key management is already hard enough. It's hard to imagine a useful system you could build on a one-time pad.
- 16s 13y ago
  Anyone wanting to learn more about information theory, decrypting to multiple plaintext messages or unbreakable encryption would find it interesting. OTP is an edge case and it does not scale (I understand that), but is useful for small messages between two parties when privacy is paramount. Government states have used it. Also, I can't find any other OTP source code that compiles and works.
  - jessaustin 13y ago
    Sure, learning is good. Any introductory crypto class would consider OTP for a bit. But you seem to be asking people to critique the system as if it would be used for a non-educational purpose. (If that's not what you mean I apologize for misunderstanding.) That just seems really unlikely.

pnathan 13y ago

I don't like this attitude. It's really anti-hacker. Of course, the world is littered with cryptosystems that some foo thought would be secure and wasn't. XOR isn't encryption. ;) I would suggest that hackers interested in crypto take a sober and unafraid look at the history of crypto and then spend time breaking ciphers, "hacking" in all senses of the word. Read the crypto papers and work on the advanced math until you really and truly grasp "all the things". Pour those 10K hours in.... Crypto is hard. Doing it mostly right requires humility and hard study, and then you have a good chance of being wrong. Nothing to be afraid of if you understand the situation and understand the years and years it takes to really become good at it...

mistercow 13y ago

I feel kind of divided about using the Cryptocat as an example. On the one hand, yes, off-by-one errors (and similar simple mistakes) are really easy to make if you you're writing something with low feedback. But the Cryptocat example is frustrating because the code is so bad. Not in a "poorly written" sense, but in a "going about things in a completely insane way" sense. The code generates a random number between 0 and 1 not by dividing a 53 bit random number by 2^53, but by generating 16 decimal digits, with the rationale that 2^53 ≈ 10^16. If the code hadn't been trying to do the wrong thing in the first place, there wouldn't have been an opportunity for that off-by-one error. My point isn't that you'll be protected from simple classes of errors as long as you're coding sanely, but rather that that is the lesson you teach if you point to Cryptocat as your example. Crypto is hard, but you can't make that point very well by pointing to code written by someone who doesn't know the correct (and incredibly standard) solutions to common non-crypto problems.

lectrick 13y ago

He clearly doesn't touch unit tests, either, or he'd know that they would address ALL (as in, 100%) of his concerns here. Crypto is even easier to test than 99% of things... all you have is a couple of inputs, and an output. Boom, test cases.

ethereal 13y ago
I'd just like to point out that `cryptography' is _not_ just about testing that `decrypt(encrypt(msg)) == msg`. memfrob'ing a region of memory does this, but would we consider that a 'secure' encryption scheme? I don't think so . . . Even if it was -- how do you unit-test a PRNG to ensure the output is uniformly random? How do you ensure you don't have collisions in a hash function? How can you ensure that there's no replay attack on your protocol? How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma? These are all very real and valid cryptography concerns. Sorry if this sounds snarky, but in all seriousness -- I'm very curious as to how you would unit-test these.
- contingencies 13y ago
  how do you unit-test a PRNG to ensure the output is uniformly random? NIST standard test suite @ http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_sof... How do you ensure you don't have collisions in a hash function? All hash functions have collisions, by definition, since they represent a unique checksum of a large amount of data in a smaller keyspace. What you are really asking is probably "how do you prove that you have difficult to predict collisions"? I don't know. (I assume that the mechanisms for doing that are based upon statistical analysis of the propagation breadth and speed of various single bit changes in the input stream over varying numbers of rounds?) How can you ensure that there's no replay attack on your protocol? A combination of session keys and message sequencing? (eg. Each message must include a hash of the last.) How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma? There's an entire field of computer science around formal proofs; I don't know enough about it to really comment, however a partial answer may lay in there. Essentially that means adopting a design-time proof strategy in your testing rather than a post-facto unit-testing proof strategy, though.

billforsternz 13y ago

The article implies that the off-by-one error in the Cryptocat random number generator is catastrophic. Correct me if I am wrong, but surely that is hardly the case. The random numbers generated are a tiny bit less uniformly distributed than they would be without the error. That's an imperfection but does it have any practical consequences at all ? I know that flaws like this can introduce weaknesses that are vulnerable to attacks, but my intuition tells me this flaw is very close to the "doesn't matter" end of the catastrophic->doesn't matter spectrum. I am more than willing to be educated by someone with specialised domain knowledge.

pasquinelli 13y ago

"Writing a testcase for this would have required complicated thinking and coding which would be as likely to contain an error as it was likely for the code to be tested to contain an error." i don't know the details, by why couldn't you just collect a million bits of supposedly random data from the generator and run it through the nist test suite? it's true that testing for randomness does require complicated thinking, but fortunately it's been done. standing on the shoulders of giants and whatnot.

motters 13y ago

But if few people bother themselves with encryption code then there are not many eyeballs on it and mistakes or backdoors become more likely. Probably encryption code should not be left entirely to the "experts" at NSA, Microsoft, etc.