Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cryptographic Doom Principle

thoughtcrime.org

Post reply on HN
Print view View original

11–20 of 140 posts

Re: The Cryptographic Doom Principle

#11

Post by [deleted] »

dustyleary wrote: post #8
jxcl wrote: post #5

Earlier quoted context omitted.

That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.

I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my…

[deleted]

Re: The Cryptographic Doom Principle

#12

Post by sarciszewski »

madez wrote: post #9
kelson wrote: post #7

Earlier quoted context omitted.

This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block ->…

CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.

Cascade Ciphers were out of scope. Moxie was addressing the order of operations for authentication and encryption.

Re: The Cryptographic Doom Principle

#13

Post by kelson »

madez wrote: post #9
kelson wrote: post #7

Earlier quoted context omitted.

This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block ->…

CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.

You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce side channel attacks. Per the previous link, this is likely only practicable on entirely separate machines.

Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptographic protocol trivial to break. Any such at-scale effort would already include attacks against typical bad-custom-crypto (because they're extremely easy and common), in addition to the AES attacks. Cascading ciphers, particularly weak ones, will not stop the NSA.

edit: addressed information leak if CC & KC share keys/resources

Re: The Cryptographic Doom Principle

#14

Post by schoen »

kelson wrote: post #7
madez wrote: post #3

Earlier quoted context omitted.

This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't r…

This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block ->…

Why does expanding the underlying data that way "substantially degrade the security of a block-based cipher"? Can you think of a generic way that an adversary can gain an advantage against the block cipher because of this transformation/restriction of the plaintext?

(I appreciate the link to Matthew Green's post; I don't think his analysis of the effect of composition is as pessimistic as yours.)

Re: The Cryptographic Doom Principle

#15

Post by madez »

sirclueless wrote: post #10
madez wrote: post #6

Earlier quoted context omitted.

Rendering KC useless by using CC as I described is equivalent to breaking KC. There is no other way of messing with KC when used the way I said. And you won't break KC by chance with your CC. Many people respond like you did and they simply didn't think about what I've said and repeat old ideas. I hate people.

This is not a true statement. CC may leak information about the plaintext in ways that KC can't handle, even without breaking it. For example, applying CC might deterministically affect the message length. One of my favorite cryptographic attacks ever was of this form, known as the CRIME attack [1]. It was a "partial plaintext" attack, where the "CC" in question was plain old gzip. Basically the attackers controlled…

Read this thread again. Your statement is not correct since CC never gets to see the plaintext. CC is just a bijective function on (blocksize of KC) bits.

Re: The Cryptographic Doom Principle

#16

Post by [deleted] »

dustyleary wrote: post #8
jxcl wrote: post #5

Earlier quoted context omitted.

That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.

I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my…

[deleted]

Re: The Cryptographic Doom Principle

#17

Post by schoen »

madez wrote: post #9
kelson wrote: post #7

Earlier quoted context omitted.

This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterprise systems today). This means CC would effectively expand the underlying data 200% (0xA1 -> 0x4131) and substantially degrade the security of a block-based cipher (32-bit block ->…

CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.

I think cascading ciphers might be a good idea, but if you're following Kerckhoff's rule, if your system achieves significant use and there is a cryptographic weakness, you should assume an adversary will exploit it even if it's different from the weaknesses of other systems.

I guess there's an economic argument to be made that millions or billions of pairs of communicating parties could develop their own individual means of at least obfuscating their communications so that nobody could expect to find searchable plaintext after decryption. But the economic effort that the pairs of parties invested in creating their obfuscations may have been wasted because if the same level of time or effort had instead been spent to improve mainstream cryptography, it might have yielded major qualitative security improvements for the "official" stuff.

Re: The Cryptographic Doom Principle

#18

Post by TorKlingberg »

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

This article is clearly written for the experts who are implementing cryptography.

Re: The Cryptographic Doom Principle

#19

Post by madez »

kelson wrote: post #13
madez wrote: post #9

Earlier quoted context omitted.

CC doesn't get to see the plaintext in the construct I explained. CC is just a bijective function on (blocksize of KC) bits. The author of the mentioned blog ignores the fact that cascading ciphers like I described breaks automated cryptoanalysis which is a necessity for mass surveillance in a world with wide-spread cryptography.

You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce side channel attacks. Per the previous link, this is likely only practicable on entirely separate machines. Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptogra…

Thanks for agreeing that we don't lose security when using my construct.

> Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptographic protocol trivial to break.

Yes, but it would involve highly paid cryptoanalysts. The reason for my first comment is first of all to disprove the root of this thread. Secondly, it makes surveillance more expensive while it's free for us.

Re: The Cryptographic Doom Principle

#20

Post by stouset »

madez wrote: post #3
mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't r…

Technically, you're correct. In the real world, you're not.

This mythical protocol just encrypts a blob and sends it over the wire. But real protocols involving cryptography are significantly more complicated, because they often need to authenticate other parties, cryptographically bind all the messages in a session, preserve forward secrecy, preserve anonymity of one of the communicating parties, etc.

Now the problem isn't that you are simply applying your own cipher to the output of a strong cipher. It's that you've now got to implement a damn protocol, because nothing in the world supports your cipher. And that implementation is inevitably going to have more exploitable flaws than a well-maintained open-source project that doesn't implement your bogocipher.

Cryptography is hard, and it's not just the primitives that are ripe for gotchas. Combining primitives, implementing primitives, designing protocols, implementing protocols, and generally anything involving touching something anywhere in the entire stack is fraught with danger. As a rule, the more crypto-related lines of code you write, the more likely it is you have introduced weaknesses rather than added strength.

Post reply on HN