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

91–100 of 140 posts

Re: The Cryptographic Doom Principle

#91

Post by c22 »

madez wrote: post #83
c22 wrote: post #72

Earlier quoted context omitted.

Why not just use a different mature and trusted cipher on the relaying nodes?

That would give you security against different threats. I chose a custom cipher for 2 reasons: 1. It gives some security even when assuming that all publicly known ciphers are broken. 2. It works specifically by using a custom cipher which is normally considered bad and thus makes the results unintuitive. I think that makes it interesting.

Are you just attempting to argue the pedantic point that some theoretical subset of homebrew crypto applications may actually be secure? Because taken as practical advice your position requires a lot of awfully strong assumptions.

Re: The Cryptographic Doom Principle

#92

Post by rudolf0 »

madez wrote: post #70
rudolf0 wrote: post #63

Earlier quoted context omitted.

Exactly. And if the first cipher is a secure cipher, with no obvious sign it'll be broken any time soon (like AES), why not just use it instead of wrapping it over some homebrew solution?

Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.

That seems ridiculous for 2 reasons.

First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES.

Second, if you're assuming the NSA seriously has the capability to break AES within the next 10 years, then obscuring it with a homebrew cipher is pointless, because they've probably already used their AES decryption capability to find many other ways into your system (through a hosting provider, ISP, domain registrar, DNS provider, admin accounts of coworkers...).

Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary).

I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother?

Re: The Cryptographic Doom Principle

#93

Post by madez »

schoen wrote: post #17
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.

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…

I'm well aware that it doesn't stop a devoted attacker. But it needs a devoted attacker. That is the import point which you also recognized (beside many others). Even a devoted attacker has it harder because cracking a code with known algorithm and unknown key is easier than cracking a code with unknown algorithm and unknown key. Even more if the unknown algorithm is not available.

I think your argument that the effort put in custom ciphers maybe should be put in mainstream ciphers instead is interesting.

Tinkering around with custom ciphers can teach you a lot. Maybe you have not the knowledge or no idea how to attack/improve mainstream ciphers.

However, if you can make a difference for mainstream ciphers, of course that's what we need.

Re: The Cryptographic Doom Principle

#94

Post by richo »

If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.

Re: The Cryptographic Doom Principle

#95

Post by eru »

tekromancr wrote: post #49
sarciszewski wrote: post #43

Earlier quoted context omitted.

Um, no. http://w3techs.com/technologies/overview/programming_languag... Currently 82%, last time I checked it was 83%.

Looks legit. My apologies. I was unsure of how they would even go about determining that, but after reading their methodology and limitations, it seems that is a somewhat representative number.

It looks like they count by domains. Around 80% sounds right for PHP by that measure.

Re: The Cryptographic Doom Principle

#96

Post by derekp7 »

tptacek wrote: post #61
kkl wrote: post #35

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless. --EDIT-- I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow…

The modern argument isn't "don't roll your own crypto". It's "don't build with crypto until you've learned how to break crypto". There are plenty of resources for people to learn how to do that online. Skipping that step and then shipping weak crypto is inexcusable.

What about using existing crypto libraries (such as OpenSSL) to add crypto to an existing project? I'm adding encryption to an open source backup tool I'm working on, planning on using AES from OpenSSL. Would it be enough to document exactly what I'm doing, and put out a call for an audit of the methods that are being used? I really want to make sure I get this right.

Re: The Cryptographic Doom Principle

#97

Post by madez »

im3w1l wrote: post #89
madez wrote: post #80

Earlier quoted context omitted.

To fingerprint the connection/data by the used cipher they would need to break KC. If they are able to break KC they can fingerprint you also when you only use KC.

The output of KC is not necessarily completely random. It can contain some metadata. Like "encrypted with KC4096bits, initialization vector is 490282348992489, length of ciphertext is 26728 bytes". When you pass this through a bad cipher it may create a characteristic fingerprint.

I think you confuse cipher with protocol.

To make it clear: for me a cipher is a bijective function on arrays of a predefined length.

Re: The Cryptographic Doom Principle

#98

Post by madez »

rudolf0 wrote: post #92
madez wrote: post #70

Earlier quoted context omitted.

Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.

That seems ridiculous for 2 reasons. First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. Second, if you're assuming the NSA seriously has the capabilit…

> First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES.

If you can break a set of ciphers it's trivial to determine which was used for a connection, if one was used; You just try each.

The whole point is to hide which is the real cipher to make it more costly to attack you. Making it more costly for the attacker is what we want.

> Second, (...)

This is no argument for or against the scheme I presented.

> Even quantum algorithms are only able to halve the bits of the key search space (so 2^256 will become 2^128, which is still mostly infeasible even against a government adversary).

Breaking a cipher means to not have to search all the key space. That's the definition of a broken cipher.

> I don't think your suggestion would decrease security, if implemented perfectly (which is unlikely), even if the cipher is insecure and vulnerable to cryptanalysis. But I don't think it would increase security either. And since it wouldn't increase it, yet may decrease it in practice due to an implementation flaw which compromises both ciphers, why bother?

We disagree on the practicality of implementing it without adding another vulnerability to your system.

Re: The Cryptographic Doom Principle

#99

Post by sas »

richo wrote: post #94

If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.

it's like Pascal's Wager for security

Re: The Cryptographic Doom Principle

#100

Post by madez »

c22 wrote: post #91
madez wrote: post #83

Earlier quoted context omitted.

That would give you security against different threats. I chose a custom cipher for 2 reasons: 1. It gives some security even when assuming that all publicly known ciphers are broken. 2. It works specifically by using a custom cipher which is normally considered bad and thus makes the results unintuitive. I think that makes it interesting.

Are you just attempting to argue the pedantic point that some theoretical subset of homebrew crypto applications may actually be secure? Because taken as practical advice your position requires a lot of awfully strong assumptions.

Every crypto is homebrown - just maybe not in your home.

Everyone cooks just with water.

The scheme I talked about is not entirely homebrew. It consists of a mainstream cipher KC and a custom cipher CC to unite the best of both worlds: Robustness of mainstream crypto with obscurity of homebrew crypto.

Post reply on HN