4 ms·

> 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

> 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.
- cookiecaper 10y ago
  >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. Quite a typo here. Replying to clarify as edit timeout has already expired. I meant you should use the standard wrapper on the outside layer so it appears to be ordinary until someone breaks down that first layer.
  - wfunction 10y ago
    I don't see where the typo was, it sounded fine to me. In fact I referred to it in this comment: https://news.ycombinator.com/item?id=13200070 https://news.ycombinator.com/item?id=13200070
eternalban 10y ago
> multiple layers of crypto Unless you are just encrypting stored information ('storing secrets'), I don't see what this gets you in the long run as an approach for 'communicating secrets'. - at least one comment in this thread points out the fact that the very machines you use are likely compromised at multiple levels. - you are communicating over a custom stack, e.g. your own chat system. Either this stack is a secret or published. If former, see above. If latter, the custom mix algo is also public. I think the approach you advocate could work against non-state actors (Surveillance Inc., PIs, etc.), but if your local state actor with legal ability to stick a bag over your head is interested, it is useless. In context of OP and RT decryption by NSA, your signal would raise flags given that known methods fail to decrypt it. So you'll get flagged, and "your" machine will likely gets to chat with its government peers via factory installed backdoor to spill the beans. Given all this, the consensus advice of "don't roll your own" possibly boils down to practical advice: the standard is vetted and is effective against non-state actors, and your innovations may simply reduce the standard protection, but they will not gain you anything (since the non-state actor is already frustrated by standard crypto anyway.) If your game is NSA level actors, you really shouldn't be storing and communicating with computers.
- wfunction 10y ago
  > your innovations may simply reduce the standard protection I've spent a ton of time debunking this myth. Read my other comments; this can only happen if you don't use independent keys or if you somehow break the encryption. I'm not going to waste more time explaining it. > but they will not gain you anything Same as above.

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.

cookiecaper 10y ago
>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. Quite a typo here. Replying to clarify as edit timeout has already expired. I meant you should use the standard wrapper on the outside layer so it appears to be ordinary until someone breaks down that first layer.
- wfunction 10y ago
  I don't see where the typo was, it sounded fine to me. In fact I referred to it in this comment: https://news.ycombinator.com/item?id=13200070 https://news.ycombinator.com/item?id=13200070

eternalban 10y ago

> multiple layers of crypto Unless you are just encrypting stored information ('storing secrets'), I don't see what this gets you in the long run as an approach for 'communicating secrets'. - at least one comment in this thread points out the fact that the very machines you use are likely compromised at multiple levels. - you are communicating over a custom stack, e.g. your own chat system. Either this stack is a secret or published. If former, see above. If latter, the custom mix algo is also public. I think the approach you advocate could work against non-state actors (Surveillance Inc., PIs, etc.), but if your local state actor with legal ability to stick a bag over your head is interested, it is useless. In context of OP and RT decryption by NSA, your signal would raise flags given that known methods fail to decrypt it. So you'll get flagged, and "your" machine will likely gets to chat with its government peers via factory installed backdoor to spill the beans. Given all this, the consensus advice of "don't roll your own" possibly boils down to practical advice: the standard is vetted and is effective against non-state actors, and your innovations may simply reduce the standard protection, but they will not gain you anything (since the non-state actor is already frustrated by standard crypto anyway.) If your game is NSA level actors, you really shouldn't be storing and communicating with computers.

wfunction 10y ago
> your innovations may simply reduce the standard protection I've spent a ton of time debunking this myth. Read my other comments; this can only happen if you don't use independent keys or if you somehow break the encryption. I'm not going to waste more time explaining it. > but they will not gain you anything Same as above.