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

81–90 of 140 posts

Re: The Cryptographic Doom Principle

#81

Post by andrewflnr »

madez wrote: post #60
daeken wrote: post #51

Earlier quoted context omitted.

> People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of t…

I think to say we can't build safe cryptographic protocols is too strong. I'd say that it's very hard to design safe systems from the ground up. But it's still possible to realistically and practically work around certain threats without opening another vulnerability.

It's really not that hard, huh? Do you have some evidence or solid reasoning? Given that this is a hard question to get objectivity on, do you think you have more experience with crypto than daeken? If no, you should probably update your beliefs to consider daeken's opinion, rather than repeat your own without substantiation.

Re: The Cryptographic Doom Principle

#82

Post by daeken »

madez wrote: post #60
daeken wrote: post #51

Earlier quoted context omitted.

> People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of t…

I think to say we can't build safe cryptographic protocols is too strong. I'd say that it's very hard to design safe systems from the ground up. But it's still possible to realistically and practically work around certain threats without opening another vulnerability.

It's not realistic, because you will never consider every possible attack scenario. You may have considered timing attacks, but if you don't consider the way that the processor uses power when running through your algorithm, you may have just leaked key material. This sounds like an obscure case, right? Except that the Trezor bitcoin security appliance was just broken in that way last week.

Secure crypto comes from a lot of smart people repeatedly trying to destroy an algorithm and its implementation. It doesn't come from a super smart person building a cryptosystem; that's how we end up with DVD CSS.

Re: The Cryptographic Doom Principle

#83

Post by madez »

c22 wrote: post #72
madez wrote: post #42

Earlier quoted context omitted.

Okay, this is how I'd ad-hoc implement the scheme I described without the security problems you are commenting. A and B know each other and exchange the custom cipher securely. Imagine they each have a Raspberry Pi which does nothing else then to take each IP package sent from the other side and reverse the custom transform on the data. For each package that it sends to the other party it applies the custom transform…

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.

Re: The Cryptographic Doom Principle

#84

Post by im3w1l »

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 ->…

Wait are you telling me there are special classes of inputs that are unsafe to encrypt using the standard algorithms?

This sounds scary and please tell me more. In particular what happens in the pathological case where the input consists of 32/64/128/256 bit blocks, and in each block all bits are zero except the last one which may be one or zero?

Re: The Cryptographic Doom Principle

#85

Post by superuser2 »

shazow wrote: post #76
superuser2 wrote: post #44

Earlier quoted context omitted.

>enforces the culture of elitism in information security The NSA is elite. Nobody has any business trusting you to outsmart them unless you are also elite. This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess. Of course there is. It's a game of skill. Other people are more skilled than you, by a lot, and you're probably going to lose.

> This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess. A closer analogy would be berating everyone who tries to play chess unless they studied it for years and they are professional and renowned chessographers. :) Edit: If we're going to stretch the chess analogy further, it's important to note that the best chess players come from a very chess-pos…

>tries to play chess

Go ahead and play chess for fun, certainly, and you might become one of those grandmasters eventually, it's just that you shouldn't be betting people's privacy and potentially safety on the proposition that you already are one when you start.

Re: The Cryptographic Doom Principle

#86

Post by wglb »

JoachimSchipper wrote: post #75
tptacek wrote: post #61

Earlier quoted context omitted.

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.

Don't over-value being able to break crypto, though. Yes, it'll get people to skip the unauthenticated CBC, but exploiting a padding oracle is no guarantee that you'll be able to write e.g. a proper secure boot system, a fast and secure implementation of a low-level primitive, or that you'll get forward-security right - and there are quite a few levels above that...

The thing like going through all of the http://cryptopals.com/ exercises is that it raises your overall awareness (as of specific attacks) that this stuff is much more breakable than I thought. It is more enlightening than just how to protect against a specific attack.

Re: The Cryptographic Doom Principle

#87

Post by madez »

daeken wrote: post #82
madez wrote: post #60

Earlier quoted context omitted.

I think to say we can't build safe cryptographic protocols is too strong. I'd say that it's very hard to design safe systems from the ground up. But it's still possible to realistically and practically work around certain threats without opening another vulnerability.

It's not realistic, because you will never consider every possible attack scenario. You may have considered timing attacks, but if you don't consider the way that the processor uses power when running through your algorithm, you may have just leaked key material. This sounds like an obscure case, right? Except that the Trezor bitcoin security appliance was just broken in that way last week. Secure crypto comes from a…

The attack scenarios you described are against an implementation whereas I said your statement regarding protocols was too strong. Having that in mind, our comments don't disagree.

Re: The Cryptographic Doom Principle

#88

Post by kelson »

madez wrote: post #74
kelson wrote: post #65

Earlier quoted context omitted.

Was CC and KC both performed on the Pi? That introduces side channel attacks. Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC. Does the Pi include any remotely exploitable flaws? See before. If assume a perfect/non-exploitable CC/Pi, we may not degrade the security of KC. That key word, may, is the problem professional cryptogr…

> Was CC and KC both performed on the Pi? That introduces side channel attacks. I specifically said the RPi does nothing else but CC. > Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC. > Does the Pi include any remotely exploitable flaws? See before. The interface from the PC to the RPi should of course have the same security a…

> Thus the remote access to the RPi wouldn't pose a risk for using the protocol beside the obvious risks that you always get in such a scenario.

That risk didn't exist without the custom cipher construct (KC-system is still independently vulnerable as it was without the CC-system). This means the construct has increased the attack surface, potentially critically.

> The system I described is not trivially defeated because defeating it implies defeating KC.

Your system introduces potential new vectors to defeat KC. If KC were not broken, this construct likely weakens KC. If KC were broken, this construct may provide some minor protection. Whether it provides sufficient additional protection to actually protect the data from an adversary capable of breaking KC is extremely unlikely. Given KC is a peer-reviewed secure ciphersuite and CC is not, the emphasis should be on keeping KC secure - not weakening it to introduce an untested (likely insecure) ciphersuite in a custom composition. This is doubly the case given significant and on-going real-world costs of implementing and maintaining this custom solution.

> My point is that _if_ AES is broken without our knowledge, using the system I described can still make untargeted-surveillance impractical.

An adversary capable of automating AES decryption would already have automated weak-cryptosystem decryption. This adds nothing except cost, complexity, and faux security.

Re: The Cryptographic Doom Principle

#89

Post by im3w1l »

madez wrote: post #80
angry_octet wrote: post #66

Earlier quoted context omitted.

And it has the added benefit from the NSA's point of view that your connection/data is precisely fingerprinted as 'homebrew-crypto-1629: refer to analysis cell 2865JQ'. Then the computer is sub basement 19 goes 'ding!' and sends an automated SWAT team to your house.

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.

Re: The Cryptographic Doom Principle

#90

Post by fragmede »

exelius wrote: post #73
daeken wrote: post #51

Earlier quoted context omitted.

> People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of t…

> You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site. You'd probably be right on any other site; but I'm guessing there are a few people who do this for a living somewhere on HN.

> there are a few people who do this for a living somewhere on HN.

And Daeken would still be right.

You skipped over daeken's point, which would stand on HN or crypto.stackexchange.com where there are undoubtedly people more qualified to talk about crypto than HN.

Crypto is impossible to know if you got it right. Read that again. It's impossible to know that you got it right.

If you get it really wrong it'll be obvious to a competent cryptoanalyst, but if you get it a tiny bit wrong, and this is computer security related, so 'tiny bit wrong' is likely bad enough to render your protocol unusable, then it won't come out at first or second glance, and may even stand up to some fairly rigorous scrutiny.

Even RSA which has stood the test of time since 1977, is only considered 'safe' in so far as there's no algorithm better than brute force for factoring products of large primes - if someone came out with an algorithm tomorrow that trivialized factoring numbers, RSA would quickly get moved to the 'unsafe' list. And that's just on the crypto primitive.

There's all sorts of manner of other attacks against an implementation of a protocol to be considered too.

Post reply on HN