7 ms·

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly

by madez 9y ago

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that would be a good start.

marcoperaza 9y ago
Sorry, but this is not good advice. Widely-used crypto implementations have had the benefit of years of analysis by dozens of high-expertise stakeholders who have a lot to lose should the crypto fail. Even that isn't always enough to catch all weaknesses and vulnerabilities. This cowboy-programming attitude being extended to security is no small part of why we are so vulnerable as a society to attacks on our computer systems that can compromise our core infrastructure[1], our secrets[2], and our economic security[3]. [1] Think weeks-long country-wide power outages [2] Think juicy blackmail material on anyone with their hands on levers of power. Look at the damage that North Korea's attacks did to Sony Pictures, for example. [3] Think small-scale attacks on services that even a single major company, or many small companies, rely on.
- madez 9y ago
  You are wrongly assuming I say to throw away the work of others. I never said so.
deleted 9y ago
[deleted]
dsacco 9y ago
> You can do crypto as a side-hobby and safely put it into production. No, you really can't, unless you stretch the definition of "side-hobby" to the point of breaking at the seams. I'd be shocked if a single person who professionally works in security or cryptography is going to agree with you in this thread. You need far more than a "little care" to assure that a new cryptographic library is safe. It's an endeavor suited to a collaborative academic or corporate environment, with robust human capital and strong oversight. I'm willing to accept that someone can safely implement a primitive or a construction in a new library with significant time, effort and feedback from others. But that level of effort doesn't really qualify as a side-hobby, and until the implementation was formally checked by professional cryptographers I'd consider it suspect. This is to say nothing of designing novel primitives or constructions, which I would consider as far removed from a "side-hobby" as a local 5K is to the Olympics. However, I absolutely think people should attempt to implement their own cryptography if they're curious about it and want to learn. Just don't use it in production and assume it's unsafe. People who work in the industry don't make these claims because we think it's fun, we do it because we've all seen the consequences.
- madez 9y ago
  We are talking in vague terms, but assume you want to encrypt some offline data. - You can just use any recommended (by whom?) tool. - Or you encrypt it with recommended tool with it's own dedicated key. Then you encrypt it again by whatever way you made up in five minutes, and you need only to ensure you didn't use the key material of the recommended tool. Then there you go, you just rolled your own not-unsafer crypto.
  - dsacco 9y ago
    That is not rolling your own crypto. Rolling your own would be relying on your custom construction, not double encrypting and relying on the known construction for safety. ...Furthermore I'm confused as to why someone would do that. If you already have a safe way to encrypt your plaintext and you're the only one with both keys, why would you bother double encrypting? You gain absolutely nothing because it's redundant, and you lose performance. What you're doing is tantamount to a weird sort of encoding that doesn't offer any benefit.
    - madez 9y ago
      Doing your own encryption does clearly not exclude also using other encryption. Or is implementing AES already not anymore doing your own encryption, because AES wasn't invented by you? You _always_ use work of others. Doing your own crypto can be used as way to safeguard against unknown vulnerabilities in the tools you would use otherwise. If the recommended library is safe, then fine, you are good to go. How do we know it is safe? My idea above is a way to increase the safety margin in a way that is orthogonal to the increase of the key space of the recommended tool. That sounds like a very good thing to me.
      - dsacco 9y ago
        I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you meant. If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot, and there are plenty of open source implementations that you can inspect if you don't trust the code. Finally, if you distrust the design of a known good algorithm, you're out of luck, because (again) you're almost certainly not going to come up with something better. If you do, by all means use it, but it's simply not likely whatsoever. And again: you're not increasing the safety margin by double encrypting, unless you know both algorithms and implementations are solid. And even if they both are, the safety margin improvement will be negligible compared to the decrease in performance.
DanBC 9y ago
> Of course, you can also do it wrong, but it is with little work possible to do it correctly. GCHQ loves people who think this. Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.
- ZoFreX 9y ago
  Game companies are a great example because: 1) they invest 6 or 7 figures in this (piracy prevention is big money) 2) they still get it wrong 3) they not only get it wrong, they get in wrong in ways that teenagers still in high school can break, let alone the NSA
  - dankent 9y ago
    Game companies are also a great example of a situation where a large group of people with time on their hands (teenagers still in high school) are motivated to look for vulnerabilities in the method used.
    - deleted 9y ago
      [deleted]
  - marcosdumay 9y ago
    The fact that piracy prevention can not be solved does not help them.
    - deleted 9y ago
      [deleted]
- madez 9y ago
  Just look at the major used crypto libraries and their CVE's. Everybody gets it wrong. I consider that a sane and sound assumption. But then you can combine stuff as I've for example written in another comment to roll your own crypto in five minutes, which is not-unsafer. There is cult around "Don't roll your own crypto" that is thought-policing.

by madez 9y ago

marcoperaza 9y ago

Sorry, but this is not good advice. Widely-used crypto implementations have had the benefit of years of analysis by dozens of high-expertise stakeholders who have a lot to lose should the crypto fail. Even that isn't always enough to catch all weaknesses and vulnerabilities. This cowboy-programming attitude being extended to security is no small part of why we are so vulnerable as a society to attacks on our computer systems that can compromise our core infrastructure[1], our secrets[2], and our economic security[3]. [1] Think weeks-long country-wide power outages [2] Think juicy blackmail material on anyone with their hands on levers of power. Look at the damage that North Korea's attacks did to Sony Pictures, for example. [3] Think small-scale attacks on services that even a single major company, or many small companies, rely on.

madez 9y ago
You are wrongly assuming I say to throw away the work of others. I never said so.

deleted 9y ago

[deleted]

dsacco 9y ago

> You can do crypto as a side-hobby and safely put it into production. No, you really can't, unless you stretch the definition of "side-hobby" to the point of breaking at the seams. I'd be shocked if a single person who professionally works in security or cryptography is going to agree with you in this thread. You need far more than a "little care" to assure that a new cryptographic library is safe. It's an endeavor suited to a collaborative academic or corporate environment, with robust human capital and strong oversight. I'm willing to accept that someone can safely implement a primitive or a construction in a new library with significant time, effort and feedback from others. But that level of effort doesn't really qualify as a side-hobby, and until the implementation was formally checked by professional cryptographers I'd consider it suspect. This is to say nothing of designing novel primitives or constructions, which I would consider as far removed from a "side-hobby" as a local 5K is to the Olympics. However, I absolutely think people should attempt to implement their own cryptography if they're curious about it and want to learn. Just don't use it in production and assume it's unsafe. People who work in the industry don't make these claims because we think it's fun, we do it because we've all seen the consequences.

madez 9y ago
We are talking in vague terms, but assume you want to encrypt some offline data. - You can just use any recommended (by whom?) tool. - Or you encrypt it with recommended tool with it's own dedicated key. Then you encrypt it again by whatever way you made up in five minutes, and you need only to ensure you didn't use the key material of the recommended tool. Then there you go, you just rolled your own not-unsafer crypto.
- dsacco 9y ago
  That is not rolling your own crypto. Rolling your own would be relying on your custom construction, not double encrypting and relying on the known construction for safety. ...Furthermore I'm confused as to why someone would do that. If you already have a safe way to encrypt your plaintext and you're the only one with both keys, why would you bother double encrypting? You gain absolutely nothing because it's redundant, and you lose performance. What you're doing is tantamount to a weird sort of encoding that doesn't offer any benefit.
  - madez 9y ago
    Doing your own encryption does clearly not exclude also using other encryption. Or is implementing AES already not anymore doing your own encryption, because AES wasn't invented by you? You _always_ use work of others. Doing your own crypto can be used as way to safeguard against unknown vulnerabilities in the tools you would use otherwise. If the recommended library is safe, then fine, you are good to go. How do we know it is safe? My idea above is a way to increase the safety margin in a way that is orthogonal to the increase of the key space of the recommended tool. That sounds like a very good thing to me.
    - dsacco 9y ago
      I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you meant. If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot, and there are plenty of open source implementations that you can inspect if you don't trust the code. Finally, if you distrust the design of a known good algorithm, you're out of luck, because (again) you're almost certainly not going to come up with something better. If you do, by all means use it, but it's simply not likely whatsoever. And again: you're not increasing the safety margin by double encrypting, unless you know both algorithms and implementations are solid. And even if they both are, the safety margin improvement will be negligible compared to the decrease in performance.

DanBC 9y ago

> Of course, you can also do it wrong, but it is with little work possible to do it correctly. GCHQ loves people who think this. Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.

ZoFreX 9y ago
Game companies are a great example because: 1) they invest 6 or 7 figures in this (piracy prevention is big money) 2) they still get it wrong 3) they not only get it wrong, they get in wrong in ways that teenagers still in high school can break, let alone the NSA
- dankent 9y ago
  Game companies are also a great example of a situation where a large group of people with time on their hands (teenagers still in high school) are motivated to look for vulnerabilities in the method used.
  - deleted 9y ago
    [deleted]
- marcosdumay 9y ago
  The fact that piracy prevention can not be solved does not help them.
  - deleted 9y ago
    [deleted]
madez 9y ago
Just look at the major used crypto libraries and their CVE's. Everybody gets it wrong. I consider that a sane and sound assumption. But then you can combine stuff as I've for example written in another comment to roll your own crypto in five minutes, which is not-unsafer. There is cult around "Don't roll your own crypto" that is thought-policing.