The Cryptographic Doom Principle
thoughtcrime.org
The Cryptographic Doom Principle
1–10 of 140 posts
Re: The Cryptographic Doom Principle
#2I 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.
Re: The Cryptographic Doom Principle
#3I 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 rely solely on custom cryptography.
Re: The Cryptographic Doom Principle
#4I 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.
> Use a pre-existing cryptography package that has been written properly instead.
Okay, name one that has been written properly that the average web developer is going to encounter.
I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development).
PGP? OTR? Axolotl? These aren't part of your standard dev environment.
Mcrypt? Hasn't been touched since 2007. There is at least a patch for a bug in the 64-bit implementation of CAST-256 that has been sitting, unmerged, for six years.
Libsodium is the best we have, and you need PECL access to install it.
OpenSSL is labyrinthine. http://stackoverflow.com/a/29331937/2224584
It's still messy, despite the past year of attention from the security industry, but it's getting better.
This library offloads its underlying cryptography to OpenSSL because it's the best we got:
https://github.com/defuse/php-encryption/
Maybe Python, Ruby, and Node developers have better options available to them. But 83% of the Internet runs PHP, and having a properly written cryptography package just isn't a trivial bar to leap over.
Re: The Cryptographic Doom Principle
#5I 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…
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.
Re: The Cryptographic Doom Principle
#6Earlier 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…
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.
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.
Re: The Cryptographic Doom Principle
#7I 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…
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 -> effectively 16-bits).
Here's a link to a practical case of unsafe composition (in hashing): http://blog.ircmaxell.com/2015/03/security-issue-combining-b...
A bit more detail on randomly composing encryption algorithms: http://blog.cryptographyengineering.com/2012/02/multiple-enc...
edit: It would be better to compose CC(KC(P)) so CC can't leak any information about P or degrade KC. Any reluctance to show the world the output of CC should suggest the low-practical-value of CC.
Re: The Cryptographic Doom Principle
#8Earlier 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…
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 custom cipher CC, when applied to ciphertext encrypted by AES, somehow leaked any information about the plaintext, then I have accidentally made a cryptanalysis breakthrough that has thwarted hundreds of professional crypto people.
This is unlikely.
Re: The Cryptographic Doom Principle
#9Earlier 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 ->…
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.
Re: The Cryptographic Doom Principle
#10Earlier 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.
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 a small part of the plaintext (for example, a field in an HTTPS request they could send with CSRF) and they were able to use known properties of the CC to get some information to leak into the message length -- namely, if the message fragment they controlled appeared elsewhere in the request, the gzip encoding would be shorter, and hence the encrypted request would be shorter. This is something that happens even with a "perfect" KC that no one could break.
[1]: http://en.wikipedia.org/wiki/CRIME
This is one of the defining characteristics of cryptography to me -- there are no perfect cyphers, there are only good systems. Littering extra cryptography around nearly always decreases security. The most secure system is the simplest system that works.