16 ms·

This article cuts to the heart something I've wondered for a long time. The common advice in all the classic texts is that developers should not roll their own

by clord 10y ago

This article cuts to the heart something I've wondered for a long time. The common advice in all the classic texts is that developers should not roll their own crypto because smarter people have thought of more vulnerabilities and addressed them in battle-tested code. But news like this shows that there is an antithesis: the conventional encryption techniques are also potentially widely exploitable by state-level actors. Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use, I'd be complaining loudly every time someone wrote a bespoke library too. I'd be paying to publish books that recommend no one write their own crypto because it's just such a darned hard problem, especially with so many high quality alternatives out there tested and ready to go. Granted, one should certainly have a repulsion to to writing custom crypto for all of the many good reasons, but it makes me think it's worth putting in more than the minimal effort into it, especially when lives are on the line.

quickben 10y ago
Think of it this way: the propaganda worked.
- Godel_unicode 10y ago
  What do you think is propaganda, exactly? That crypto is hard to do well?
  - patall 10y ago
    I think he means that we are encouraged by propaganda to assume that all crypto is broken, so that we do not even attemp to use it as that would just take more time to implement with no additional security for us. "Why should I use Signal if it is no more save then WhatsApp but just less convienient?"
bsder 10y ago
> But news like this shows that there is an antithesis: the conventional encryption techniques are also potentially widely exploitable by state-level actors. Are they? Really? We know that NSA has lots of vectors for exploiting the system AROUND encryption. We have pretty solid evidence that the NSA has weakened some encryption standards to make them crackable. We DON'T have evidence that encryption developed outside the milieu of the NSA are equally crackable. And circumstantial evidence suggests quite the opposite. The problem is that there are lots of things to get right to get crypto right, and getting even one wrong leads to failure. Which is why we tell people not to roll their own encyption and to let the experts do it. Another problem with too many people rolling their own encryption is that it dilutes attention and no system gets sufficiently audited.
- rainloft 10y ago
  It took 33 years before it was publicly announced that GCHQ succeeded in deciphering Enigma codes. Every single time they used intercepted intelligence to their benefit, they made sure to leave false trails of other ways they could've known so the Germans wouldn't suspect. I would expect the NSA could hide it well.
  - WalterBright 10y ago
    I am still surprised that the Japanese and Germans did not figure out their codes had been broken. The disaster of the U-boot campaign was pretty good evidence of that, if nothing else. Besides, expecting a widely used and deployed cryptosystem to be uncompromised for years is absurd. They should have assumed it would be broken, and developed regular replacements.
    - antman 10y ago
      They organized airplane flyovers that "saw" the U-boats. The Germans did not know how many aircrafts were patrolling and whether it was a high or low probability of being spotted. If the British could not organize a parallel construction they simply let it go. They knew the plan for Crete invasion but they could not create a story on how they learned it so they preferred to lose naval control of the large part of the eastern Mediterranean sea. [0] [0] https://www.amazon.com/Churchill-Secret-Service-David-Stafford/dp/1909609137 https://www.amazon.com/Churchill-Secret-Service-David-Staffo...
      - WalterBright 10y ago
        The sub killers were waiting at meeting points for the U-boots and their "milk cows" so often that the obvious possibilities were: 1. the allies had enormous numbers of sub killers 2. the allies were incredibly lucky 3. Enigma was broken Waiting for proof before acting is not a sensible decision. (Even in WW1, the aviators regularly changed their codes used. They knew they were only good for a few days each.)
rl3 10y ago
I recall an interview with William Binney where he suggested simply rearranging your message's payload at the protocol level would be enough to thwart automated analysis. It would require human attention, which is ultimately finite. The trade-off there is that it might draw unwanted attention. Such an approach may be more suited for use inside of a message already encrypted using standard means. It's worth noting that if there's no network interception angle, the NSA can easily penetrate all but the most hardened systems should they be so inclined.
- pandler 10y ago
  > rearranging your message's payload at the protocol level Do you have an example of how you might do that? Something like (real basic example) reversing a json payload? {"key": {}} becomes {{}: "yek"} Or is that too simplistic?
  - hackermailman 10y ago
    I was guessing changing the protocol, like adding or subtracting a few aes rounds to a ssh connection so a standard connection doesn't even speak your protocol and can't connect. This also reminds me of when somebody here wrote about meeting one of the cryptographers at a con for SHA3 (Blake?) and the guy shrugged off his efforts saying it was all for fun meaning whatever device you have is so completely back doored already either through sabotaged/weakened standards or outright (proprietary microcode) that believing any algorithm can keep a secret from nation state adversaries is laughable.
    - dom0 10y ago
      > believing any algorithm can keep a secret from nation state adversaries is laughable. Well, yeah, it is. Defence against (crypto-buzzword) state-level actors (SLAs) doesn't start with gpg and FDE, rather, with operational security, or, even better, not being a worthwhile target in the first place (if your briefcase of secret documents is already on CNN there is no need to infiltrate your stuff beyond gaining assurance that you don't have another briefcase - which is the thing you want to proof as publicly as possible to convince your highly paranoid adversary) There is that saying "never trust a computer you can't throw out the window". Computers are networked. You're trusting a network of computers, even if you don't use "networked functionality". Can you throw the internet out the window? Probably not! Hence, don't trust computers. People who trust computers to keep their secrets are foolish¹ (Trottel), so just don't. ¹ Notice how governments²³ trust computers to keep their secrets safe, and how admirably and totally that failed. Ask yourself, what wasn't leaked by Snowden? Stuff that wasn't in any computer in the first place! ² Or how celebrities trusted computers to keep their dickpics safe. ³ Or how companies trusted computers to keep their business secrets, well, uh, secret. To make my point another way: Computers are for disseminating information. If secrecy is more important than dissemination, then don't use a computer.
cookiecaper 10y ago
I think the fact is that in most cases, you can't do much about government actors, especially not the US. All you can do is use the best crypto that's available and hope that the government hasn't cracked it yet (but you should always expect that the message will be as good as plaintext in 30 years). If you roll your own crypto, you're liable to have the guy down the street spot an issue in your custom implementation and walk out with all the goods before you realize what happened. Maybe the most technologically advanced spy agency in the world can decrypt some industry-standard encryption if your messages are interesting enough and it justifies the time-cost (police, prosecutors, and laypeople still can't), but probably someone on HN can pick out errors with your custom cryptography and render it useless, at least until you've really spent a great deal of time testing and refining it. That's the difference, IMO.
- wfunction 10y ago
  > If you roll your own crypto, you're liable to have the guy down the street spot an issue in your custom implementation and walk out with all the goods before you realize what happened. Isn't it quite obvious that you can have multiple layers of crypto? Like your own on top of a standard one? Why do you (and a lot of people, not just you) set up a silly strawman argument whenever talk of rolling your own crypto comes up in any online forum?
  - cookiecaper 10y ago
    Because many people would say "Why bother?", from both ends of the argument. Someone who is naively rolling their own crypto would say "Why should I waste time double-crypting everything and implementing wrappers when I'm investing all this time in my own super-cool crypto which no one can crack because I'm so awesome?" and someone else who is recommended against it would say "Why bother spending all that time duplicating work that's already been done for you by experts when your custom layer is just going to get compromised anyway?" So in short, for practical purposes, it's just not efficient, in either programming time or performance time. If you want to double-wrap, as it were, more power to you, but be aware of the costs. If you are going to double-wrap, it'd be best to wrap the payload in your custom package first and then standard second on the outside, so someone has to overcome the first barrier before they can find anything out about the custom/second barrier. That's a deterrent that would probably require man-time and sufficient interest if indeed the NSA can automatically decrypt current standard crypto. I also think there's a little bit of confusion here. When people say "Don't implement custom crypto", they usually mean "Don't implement your own crypto library to implement common standards and algorithms". Most people don't think they can create crypto that rivals the publicly-used cryptographic algorithms out there, so the issue is usually about whether that person should implement AES directly or through GnuTLS, etc. If the NSA has holes in AES and you implement it correctly, you haven't really accomplished anything. This is probably what you've been talking about, but I want to make sure that point is clear for any other readers. And just for a counterpoint, I remember an exchange on here by tpatceckd and cpercival many years ago where Thomas congratulated Colin on being one of the few to actually correctly implement industrial-grade crypto standards without using one of the major libraries. If either of them are reading and I'm misremembering, feel free to correct me, but the issue is less about stifling things or leaving backdoors for the powerful than it is about preventing the types of subtle but critically damaging bugs that run rampant through basically any code that hasn't been extensively battle-tested and matured in the crucible for years. Since encountering cryptography in the wild is a signal that you may be stumbling upon something high-value, it's definitely not the kind of thing that you normally want to be taking chances with. That risk profile that makes a tried-and-true-but-possibly-compromised-by-the-most-technically-advanced-people-on-earth implementation better than a I-just-rolled-this-at-home-so-I-know-the-NSA-hasn't-hidden-any-backdoors-in-it-but-probably-someone-will-crack-it-after-three-days implementation.
wfunction 10y ago
Thanks for saying exactly the same thing that's come to my mind over and over again. I would totally roll my own crypto on top of an existing cryptosystem if I could and if someone with this much computational power was in my threat model. That way I would get the best of both. Same goes for hashing by the way: I'd totally stack multiple hash functions on top of each other too. But in this I'd only stack cryptographic ones that have not yet been broken; I wouldn't roll my own.
- Taek 10y ago
  You never get the best if you roll your own. The problem is that there are many broad classes of attack that cover wide ranges of knowledge. If OpenSSL can't get TLS right, how do you expect to get your home-rolled crypto right? If you choose to roll your own, you will almost certainly have more vulnerabilities that are easier to find. Your gamble is that agencies like the NSA are already holding vulnerabilities to the common libraries, and that it's more expensive for them to break your weaker crypto (it will be weaker even if you are world class) because they have to take time to break it. Edit: stacking multiple hash functions naively is a bad idea as well. As a thought experiment, let's say that I have a hash function that is effectively (because the NSA broke it) as useful as converting the input to all zeroes. Stacking more hashes on top of that hash won't help you, because it will still be trivial to find collisions.
  - wfunction 10y ago
    >> I would totally roll my own crypto on top of an existing cryptosystem [...] That way I would get the best of both. > You never get the best if you roll your own. Did you even read my comment? I'm not talking about my own crypto on its own, I'm talking about my own crypto on top of an existing one. Two layers is at least as secure as a single one of either layer. It's as simple as that. There's just no argument to be made for your side here. ------------- EDIT: since you added an edit: > stacking multiple hash functions naively is a bad idea as well Really now? Reading on, though, you say: > Stacking more hashes on top of that hash won't help you Oh, I thought you said it's "bad"? Now you're just saying it "won't help". But that's neither a fact, nor the question in the first place. The question is whether it will hurt, and the answer is that it does not. Again, this is common sense. There's no argument to be made for your side against it.
feelix 10y ago
I wonder if a good way to go would be to implement standard encryption (AES in most cases), and then take that encrypted payload and encrypt it with your custom code that you designed. So even if it's actually true, and that you shouldn't roll your own encryption in practice, even if they do break yours they'll still have to get through the AES as well. So it's a no risk addition.
- 0x0 10y ago
  It's never a no-risk addition. Perhaps your custom code is buggy and ends up adding in random memory contents that happened to contain both your AES key and your custom crypto key, into the message payload ala heartbleed.
rlpb 10y ago
A contrary way of looking at this is that we can expect standard crypto implementations to switch to randomizing chosen primes. If you had been rolling your own, would you keep up to date with the state-of-the-art and switch, too? Most hand-rollers probably won't, IMHO, because they don't have enough resources to spare a person to keep up with the art, let alone keep their own implementations up to date with it. > ...I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use, I'd be complaining loudly every time someone wrote a bespoke library too. Sure. This is pretty standard adversarial stuff, though. It's up to researchers to figure things out and publish. I don't see any evidence that this isn't happening. This article is a perfect example!
mirimir 10y ago
There's some serious confusion here, I think. Maybe it's local [;)] but here goes ... > Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use ... Well, the article notes: > For the nerds in the audience, here’s what’s wrong: If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime. That prime is the "dhparam.pem". It's used in bootstrapping the encrypted connection. And it's my understanding that this is entirely distinct from the issue of "cherry-picked primes for well-understood algorithms in wide use". This vulnerability is simply using "standardized or hard-coded primes". Cipher vulnerabilities are about ... And that's where my understanding ends. Maybe someone can complete the argument. Or sort me out ;)
agumonkey 10y ago
cryptodiversity ?
alkonaut 10y ago
What if 2048 bit was the standard? What if people used multiple passes with different primes? (That may not give any improved security, I'm. not familiar with the details). It seems like a massive waste of energy and money to crack a few primes if the advantage you gain can be erased so quickly? I agree it seems like writing custom bad crypto is way better than good crypto that can be broken in bulk. (Using both kinds together seems clever). A good analyst can likely break my homemade crypto in twenty minutes, but that's orders of magnitude better than using a compromised strong crypto! Another question: Are good primes that hard to come by? Shouldn't apps generate new primes instead of re-using old ones? Last question: are there good cryptos that aren't sensitive to a state level actor that can factor primes in linear time?
- marcosdumay 10y ago
  > Are good primes that hard to come by? My laptop takes around 2 minutes to get a pair of 4k bits primes for DH parameters. The problem is that people want their installers to be instantaneous. Those 2 minutes are too long.
  - alkonaut 10y ago
    A popular app could ship with 100 different primes pre baked and pick one at random? Not perfect but 100x better than having one prime.
    - marcosdumay 10y ago
      If those primes are compromised, 100 of them are still useless.
      - alkonaut 10y ago
        Yes that's only useful under the original assumption of the article: that a state level actor must use a nontrivial part of its budget to factor one prime. The back of the envelope calculations if they did classical factorization is that one or a few 1024bit primes were possible but 100 were not. Of course next year they will have twice the CPU time, or a better quantum computer, so it's a short term win.
rahrahrah 10y ago
You're making the argument "If I apply good crypto plus crypto which might or might not be good, the worst case scenario is that I end up with crypto which is at least as good as the good crypto." You're the perfect example of Dunning-Kruger, where your skills at crypto are really bad so lack the knowledge to evaluate your crypto skills. You're exactly the kind of person that advice is aimed at.
- Helmet 10y ago
  This comment boils down to: you're wrong and you're stupid. Also, and quite ironically, you have misinterpreted and are misapplying the D.K. effect. Can you care to explain why the above wouldn't be true? Does an extra layer of bad crypto diminish the effectiveness of the good crypto? It doesn't seem like it would, and OPs statement reads more like a reasonable logical assumption, but I know very little about crypto, which is why I ask.
  - rahrahrah 10y ago
    No, I'm not misapplying DK > Does an extra layer of bad crypto diminish the effectiveness of the good crypto? Yes, you can find other children comment with specific examples. > It doesn't seem like it would More DK: you don't know enough to evaluate how much you know.
    - sbov 10y ago
      So rot13 will render my aes useless?
      - whatshisface 10y ago
        Possibly. If your rot13 takes longer to rotate a Z than it does and A, then it will leak your Zs through the AES. Similarly, you might accidentally write your own rot13 heartbleed.
        ENGNR 10y ago
Lagged2Death 10y ago
...the conventional encryption techniques are also potentially widely exploitable by state-level actors. That really depends on how you define "conventional encryption techniques." As is so often the case, this proposed line of attack isn't against the crypto proper, but against habitually poor implementation details. Human laziness, really. They're not picking the locks, they've found a way to steal the keys.
agwa 10y ago
Your comment shows a very dangerous misunderstanding of this issue. One of the reasons WeakDH/Logjam was so bad is because OpenSSL is so low-level that it forces application developers to supply their own DH parameters if they want to use Diffie-Hellman. Until recently, setting DH parameters required writing complicated code which required the application developer to understand obscure details of TLS like export ciphers, as well as whether it was safe to reuse temporary Diffie-Hellman keys. In other words, OpenSSL forced developers to do crypto to use Diffie-Hellman. Unsurprisingly, developers did a poor job, and we got WeakDH/Logjam/CVE-2016-0701 as a result. The answer is not more hand-rolled crypto as you suggest, but rather better crypto libraries written by experts that leave as few details to the application developer as possible.
- javajosh 10y ago
  So basically your point is that if app devs can't get DH parameters right, how on earth will they get the harder stuff right? I think that's a fine point, but you aren't really addressing the core concern, which is that "better crypto libraries written by experts" are precisely the ones most likely to be vulnerable to state actors doing massive prime computations. And by extension, state actors benefit from homogeneity of implementation. Even if it takes a day for a kid at the NSA to break my custom crypto, that's better than if I use homogenous crypto that takes 2ms to break. And if everyone is using bad custom crypto, that's a lot of time needed to break each one individually. The argument is very close to that against monolithic grain cultures that, while they have the best yields, resisitance to pests, and so forth, they are also more vulnerable to as-yet-unknown diseases. Bio-diversity is a good defense against that contingency.
  - agwa 10y ago
    No, because there's a simple solution to state actors doing massive computations: make the parameters so large (2048 bits in the case of DH) that the computations are infeasible. DH precomputation attacks are only a problem with smaller prime sizes (e.g. 1024 bits). Experts have always known to avoid small parameters, but developers copy-and-pasted them into their code without knowing they were bad.
ape4 10y ago
Perhaps the solution is an audited framework for rolling your own crypto. This way you just need to write one small module. But everything else is handled using secure professional ways - eg key exchange, memory wiping, etc.
Ar-Curunir 10y ago
You really believe the entire cryptographic community is so thoroughly morally compromised? The same community that has been investigating and fighting the NSA's wrongdoings? Crypto is hard; coming up with sound cryptographic primitives is highly nontrivial if you do not have the right training. Even if you have the mathematics to back it up, safely implementing the mathematics is in itself tricky, with all kinds of side channel attacks potentially breaking your scheme.
- jpitz 10y ago
  It's not necessarily that the whole community is compromised, it's that the goals of an organization devoted to signals intelligence align here with the guidance of the community, fostering what converges towards a monoculture.

by clord 10y ago

quickben 10y ago

Think of it this way: the propaganda worked.

Godel_unicode 10y ago
What do you think is propaganda, exactly? That crypto is hard to do well?
- patall 10y ago
  I think he means that we are encouraged by propaganda to assume that all crypto is broken, so that we do not even attemp to use it as that would just take more time to implement with no additional security for us. "Why should I use Signal if it is no more save then WhatsApp but just less convienient?"

bsder 10y ago

> But news like this shows that there is an antithesis: the conventional encryption techniques are also potentially widely exploitable by state-level actors. Are they? Really? We know that NSA has lots of vectors for exploiting the system AROUND encryption. We have pretty solid evidence that the NSA has weakened some encryption standards to make them crackable. We DON'T have evidence that encryption developed outside the milieu of the NSA are equally crackable. And circumstantial evidence suggests quite the opposite. The problem is that there are lots of things to get right to get crypto right, and getting even one wrong leads to failure. Which is why we tell people not to roll their own encyption and to let the experts do it. Another problem with too many people rolling their own encryption is that it dilutes attention and no system gets sufficiently audited.

rainloft 10y ago
It took 33 years before it was publicly announced that GCHQ succeeded in deciphering Enigma codes. Every single time they used intercepted intelligence to their benefit, they made sure to leave false trails of other ways they could've known so the Germans wouldn't suspect. I would expect the NSA could hide it well.
- WalterBright 10y ago
  I am still surprised that the Japanese and Germans did not figure out their codes had been broken. The disaster of the U-boot campaign was pretty good evidence of that, if nothing else. Besides, expecting a widely used and deployed cryptosystem to be uncompromised for years is absurd. They should have assumed it would be broken, and developed regular replacements.
  - antman 10y ago
    They organized airplane flyovers that "saw" the U-boats. The Germans did not know how many aircrafts were patrolling and whether it was a high or low probability of being spotted. If the British could not organize a parallel construction they simply let it go. They knew the plan for Crete invasion but they could not create a story on how they learned it so they preferred to lose naval control of the large part of the eastern Mediterranean sea. [0] [0] https://www.amazon.com/Churchill-Secret-Service-David-Stafford/dp/1909609137 https://www.amazon.com/Churchill-Secret-Service-David-Staffo...
    - WalterBright 10y ago
      The sub killers were waiting at meeting points for the U-boots and their "milk cows" so often that the obvious possibilities were: 1. the allies had enormous numbers of sub killers 2. the allies were incredibly lucky 3. Enigma was broken Waiting for proof before acting is not a sensible decision. (Even in WW1, the aviators regularly changed their codes used. They knew they were only good for a few days each.)

rl3 10y ago

I recall an interview with William Binney where he suggested simply rearranging your message's payload at the protocol level would be enough to thwart automated analysis. It would require human attention, which is ultimately finite. The trade-off there is that it might draw unwanted attention. Such an approach may be more suited for use inside of a message already encrypted using standard means. It's worth noting that if there's no network interception angle, the NSA can easily penetrate all but the most hardened systems should they be so inclined.

pandler 10y ago
> rearranging your message's payload at the protocol level Do you have an example of how you might do that? Something like (real basic example) reversing a json payload? {"key": {}} becomes {{}: "yek"} Or is that too simplistic?
- hackermailman 10y ago
  I was guessing changing the protocol, like adding or subtracting a few aes rounds to a ssh connection so a standard connection doesn't even speak your protocol and can't connect. This also reminds me of when somebody here wrote about meeting one of the cryptographers at a con for SHA3 (Blake?) and the guy shrugged off his efforts saying it was all for fun meaning whatever device you have is so completely back doored already either through sabotaged/weakened standards or outright (proprietary microcode) that believing any algorithm can keep a secret from nation state adversaries is laughable.
  - dom0 10y ago
    > believing any algorithm can keep a secret from nation state adversaries is laughable. Well, yeah, it is. Defence against (crypto-buzzword) state-level actors (SLAs) doesn't start with gpg and FDE, rather, with operational security, or, even better, not being a worthwhile target in the first place (if your briefcase of secret documents is already on CNN there is no need to infiltrate your stuff beyond gaining assurance that you don't have another briefcase - which is the thing you want to proof as publicly as possible to convince your highly paranoid adversary) There is that saying "never trust a computer you can't throw out the window". Computers are networked. You're trusting a network of computers, even if you don't use "networked functionality". Can you throw the internet out the window? Probably not! Hence, don't trust computers. People who trust computers to keep their secrets are foolish¹ (Trottel), so just don't. ¹ Notice how governments²³ trust computers to keep their secrets safe, and how admirably and totally that failed. Ask yourself, what wasn't leaked by Snowden? Stuff that wasn't in any computer in the first place! ² Or how celebrities trusted computers to keep their dickpics safe. ³ Or how companies trusted computers to keep their business secrets, well, uh, secret. To make my point another way: Computers are for disseminating information. If secrecy is more important than dissemination, then don't use a computer.

cookiecaper 10y ago

I think the fact is that in most cases, you can't do much about government actors, especially not the US. All you can do is use the best crypto that's available and hope that the government hasn't cracked it yet (but you should always expect that the message will be as good as plaintext in 30 years). If you roll your own crypto, you're liable to have the guy down the street spot an issue in your custom implementation and walk out with all the goods before you realize what happened. Maybe the most technologically advanced spy agency in the world can decrypt some industry-standard encryption if your messages are interesting enough and it justifies the time-cost (police, prosecutors, and laypeople still can't), but probably someone on HN can pick out errors with your custom cryptography and render it useless, at least until you've really spent a great deal of time testing and refining it. That's the difference, IMO.

wfunction 10y ago
> If you roll your own crypto, you're liable to have the guy down the street spot an issue in your custom implementation and walk out with all the goods before you realize what happened. Isn't it quite obvious that you can have multiple layers of crypto? Like your own on top of a standard one? Why do you (and a lot of people, not just you) set up a silly strawman argument whenever talk of rolling your own crypto comes up in any online forum?
- cookiecaper 10y ago
  Because many people would say "Why bother?", from both ends of the argument. Someone who is naively rolling their own crypto would say "Why should I waste time double-crypting everything and implementing wrappers when I'm investing all this time in my own super-cool crypto which no one can crack because I'm so awesome?" and someone else who is recommended against it would say "Why bother spending all that time duplicating work that's already been done for you by experts when your custom layer is just going to get compromised anyway?" So in short, for practical purposes, it's just not efficient, in either programming time or performance time. If you want to double-wrap, as it were, more power to you, but be aware of the costs. If you are going to double-wrap, it'd be best to wrap the payload in your custom package first and then standard second on the outside, so someone has to overcome the first barrier before they can find anything out about the custom/second barrier. That's a deterrent that would probably require man-time and sufficient interest if indeed the NSA can automatically decrypt current standard crypto. I also think there's a little bit of confusion here. When people say "Don't implement custom crypto", they usually mean "Don't implement your own crypto library to implement common standards and algorithms". Most people don't think they can create crypto that rivals the publicly-used cryptographic algorithms out there, so the issue is usually about whether that person should implement AES directly or through GnuTLS, etc. If the NSA has holes in AES and you implement it correctly, you haven't really accomplished anything. This is probably what you've been talking about, but I want to make sure that point is clear for any other readers. And just for a counterpoint, I remember an exchange on here by tpatceckd and cpercival many years ago where Thomas congratulated Colin on being one of the few to actually correctly implement industrial-grade crypto standards without using one of the major libraries. If either of them are reading and I'm misremembering, feel free to correct me, but the issue is less about stifling things or leaving backdoors for the powerful than it is about preventing the types of subtle but critically damaging bugs that run rampant through basically any code that hasn't been extensively battle-tested and matured in the crucible for years. Since encountering cryptography in the wild is a signal that you may be stumbling upon something high-value, it's definitely not the kind of thing that you normally want to be taking chances with. That risk profile that makes a tried-and-true-but-possibly-compromised-by-the-most-technically-advanced-people-on-earth implementation better than a I-just-rolled-this-at-home-so-I-know-the-NSA-hasn't-hidden-any-backdoors-in-it-but-probably-someone-will-crack-it-after-three-days implementation.

wfunction 10y ago

Thanks for saying exactly the same thing that's come to my mind over and over again. I would totally roll my own crypto on top of an existing cryptosystem if I could and if someone with this much computational power was in my threat model. That way I would get the best of both. Same goes for hashing by the way: I'd totally stack multiple hash functions on top of each other too. But in this I'd only stack cryptographic ones that have not yet been broken; I wouldn't roll my own.

Taek 10y ago
You never get the best if you roll your own. The problem is that there are many broad classes of attack that cover wide ranges of knowledge. If OpenSSL can't get TLS right, how do you expect to get your home-rolled crypto right? If you choose to roll your own, you will almost certainly have more vulnerabilities that are easier to find. Your gamble is that agencies like the NSA are already holding vulnerabilities to the common libraries, and that it's more expensive for them to break your weaker crypto (it will be weaker even if you are world class) because they have to take time to break it. Edit: stacking multiple hash functions naively is a bad idea as well. As a thought experiment, let's say that I have a hash function that is effectively (because the NSA broke it) as useful as converting the input to all zeroes. Stacking more hashes on top of that hash won't help you, because it will still be trivial to find collisions.
- wfunction 10y ago
  >> I would totally roll my own crypto on top of an existing cryptosystem [...] That way I would get the best of both. > You never get the best if you roll your own. Did you even read my comment? I'm not talking about my own crypto on its own, I'm talking about my own crypto on top of an existing one. Two layers is at least as secure as a single one of either layer. It's as simple as that. There's just no argument to be made for your side here. ------------- EDIT: since you added an edit: > stacking multiple hash functions naively is a bad idea as well Really now? Reading on, though, you say: > Stacking more hashes on top of that hash won't help you Oh, I thought you said it's "bad"? Now you're just saying it "won't help". But that's neither a fact, nor the question in the first place. The question is whether it will hurt, and the answer is that it does not. Again, this is common sense. There's no argument to be made for your side against it.

feelix 10y ago

I wonder if a good way to go would be to implement standard encryption (AES in most cases), and then take that encrypted payload and encrypt it with your custom code that you designed. So even if it's actually true, and that you shouldn't roll your own encryption in practice, even if they do break yours they'll still have to get through the AES as well. So it's a no risk addition.

0x0 10y ago
It's never a no-risk addition. Perhaps your custom code is buggy and ends up adding in random memory contents that happened to contain both your AES key and your custom crypto key, into the message payload ala heartbleed.

rlpb 10y ago

A contrary way of looking at this is that we can expect standard crypto implementations to switch to randomizing chosen primes. If you had been rolling your own, would you keep up to date with the state-of-the-art and switch, too? Most hand-rollers probably won't, IMHO, because they don't have enough resources to spare a person to keep up with the art, let alone keep their own implementations up to date with it. > ...I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use, I'd be complaining loudly every time someone wrote a bespoke library too. Sure. This is pretty standard adversarial stuff, though. It's up to researchers to figure things out and publish. I don't see any evidence that this isn't happening. This article is a perfect example!

mirimir 10y ago

There's some serious confusion here, I think. Maybe it's local [;)] but here goes ... > Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use ... Well, the article notes: > For the nerds in the audience, here’s what’s wrong: If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime. That prime is the "dhparam.pem". It's used in bootstrapping the encrypted connection. And it's my understanding that this is entirely distinct from the issue of "cherry-picked primes for well-understood algorithms in wide use". This vulnerability is simply using "standardized or hard-coded primes". Cipher vulnerabilities are about ... And that's where my understanding ends. Maybe someone can complete the argument. Or sort me out ;)

agumonkey 10y ago

cryptodiversity ?

alkonaut 10y ago

What if 2048 bit was the standard? What if people used multiple passes with different primes? (That may not give any improved security, I'm. not familiar with the details). It seems like a massive waste of energy and money to crack a few primes if the advantage you gain can be erased so quickly? I agree it seems like writing custom bad crypto is way better than good crypto that can be broken in bulk. (Using both kinds together seems clever). A good analyst can likely break my homemade crypto in twenty minutes, but that's orders of magnitude better than using a compromised strong crypto! Another question: Are good primes that hard to come by? Shouldn't apps generate new primes instead of re-using old ones? Last question: are there good cryptos that aren't sensitive to a state level actor that can factor primes in linear time?

marcosdumay 10y ago
> Are good primes that hard to come by? My laptop takes around 2 minutes to get a pair of 4k bits primes for DH parameters. The problem is that people want their installers to be instantaneous. Those 2 minutes are too long.
- alkonaut 10y ago
  A popular app could ship with 100 different primes pre baked and pick one at random? Not perfect but 100x better than having one prime.
  - marcosdumay 10y ago
    If those primes are compromised, 100 of them are still useless.
    - alkonaut 10y ago
      Yes that's only useful under the original assumption of the article: that a state level actor must use a nontrivial part of its budget to factor one prime. The back of the envelope calculations if they did classical factorization is that one or a few 1024bit primes were possible but 100 were not. Of course next year they will have twice the CPU time, or a better quantum computer, so it's a short term win.

rahrahrah 10y ago

You're making the argument "If I apply good crypto plus crypto which might or might not be good, the worst case scenario is that I end up with crypto which is at least as good as the good crypto." You're the perfect example of Dunning-Kruger, where your skills at crypto are really bad so lack the knowledge to evaluate your crypto skills. You're exactly the kind of person that advice is aimed at.

Helmet 10y ago
This comment boils down to: you're wrong and you're stupid. Also, and quite ironically, you have misinterpreted and are misapplying the D.K. effect. Can you care to explain why the above wouldn't be true? Does an extra layer of bad crypto diminish the effectiveness of the good crypto? It doesn't seem like it would, and OPs statement reads more like a reasonable logical assumption, but I know very little about crypto, which is why I ask.
- rahrahrah 10y ago
  No, I'm not misapplying DK > Does an extra layer of bad crypto diminish the effectiveness of the good crypto? Yes, you can find other children comment with specific examples. > It doesn't seem like it would More DK: you don't know enough to evaluate how much you know.
  - sbov 10y ago
    So rot13 will render my aes useless?
    - whatshisface 10y ago
      Possibly. If your rot13 takes longer to rotate a Z than it does and A, then it will leak your Zs through the AES. Similarly, you might accidentally write your own rot13 heartbleed.
      - ENGNR 10y ago

Lagged2Death 10y ago

...the conventional encryption techniques are also potentially widely exploitable by state-level actors. That really depends on how you define "conventional encryption techniques." As is so often the case, this proposed line of attack isn't against the crypto proper, but against habitually poor implementation details. Human laziness, really. They're not picking the locks, they've found a way to steal the keys.

agwa 10y ago

Your comment shows a very dangerous misunderstanding of this issue. One of the reasons WeakDH/Logjam was so bad is because OpenSSL is so low-level that it forces application developers to supply their own DH parameters if they want to use Diffie-Hellman. Until recently, setting DH parameters required writing complicated code which required the application developer to understand obscure details of TLS like export ciphers, as well as whether it was safe to reuse temporary Diffie-Hellman keys. In other words, OpenSSL forced developers to do crypto to use Diffie-Hellman. Unsurprisingly, developers did a poor job, and we got WeakDH/Logjam/CVE-2016-0701 as a result. The answer is not more hand-rolled crypto as you suggest, but rather better crypto libraries written by experts that leave as few details to the application developer as possible.

javajosh 10y ago
So basically your point is that if app devs can't get DH parameters right, how on earth will they get the harder stuff right? I think that's a fine point, but you aren't really addressing the core concern, which is that "better crypto libraries written by experts" are precisely the ones most likely to be vulnerable to state actors doing massive prime computations. And by extension, state actors benefit from homogeneity of implementation. Even if it takes a day for a kid at the NSA to break my custom crypto, that's better than if I use homogenous crypto that takes 2ms to break. And if everyone is using bad custom crypto, that's a lot of time needed to break each one individually. The argument is very close to that against monolithic grain cultures that, while they have the best yields, resisitance to pests, and so forth, they are also more vulnerable to as-yet-unknown diseases. Bio-diversity is a good defense against that contingency.
- agwa 10y ago
  No, because there's a simple solution to state actors doing massive computations: make the parameters so large (2048 bits in the case of DH) that the computations are infeasible. DH precomputation attacks are only a problem with smaller prime sizes (e.g. 1024 bits). Experts have always known to avoid small parameters, but developers copy-and-pasted them into their code without knowing they were bad.

ape4 10y ago

Perhaps the solution is an audited framework for rolling your own crypto. This way you just need to write one small module. But everything else is handled using secure professional ways - eg key exchange, memory wiping, etc.

Ar-Curunir 10y ago

You really believe the entire cryptographic community is so thoroughly morally compromised? The same community that has been investigating and fighting the NSA's wrongdoings? Crypto is hard; coming up with sound cryptographic primitives is highly nontrivial if you do not have the right training. Even if you have the mathematics to back it up, safely implementing the mathematics is in itself tricky, with all kinds of side channel attacks potentially breaking your scheme.

jpitz 10y ago
It's not necessarily that the whole community is compromised, it's that the goals of an organization devoted to signals intelligence align here with the guidance of the community, fostering what converges towards a monoculture.