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

111–120 of 140 posts

Re: The Cryptographic Doom Principle

#111

Post by billyhoffman »

TorKlingberg wrote: post #18
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.

On its face I guess it is. But really, this is just another demonstration of maxim "Don't do work for untrusted parties". Yes, this applies to cryptography, but also to network protocol design, and even software design in general.

Recursive DNS lookup DoS attacks? You are doing work for some you don't know (random UDP packets)

The recent NTP DDoS amplification issues? Doing work for someone you don't know (Again. unauth-ed UDP packet trigging craploads of work)

Padded Oracle attacks in Crypto? Doing work for someone you don't know, and leaking data based on when something fails.

IP Source routing? Doing work for an untrusted party!

The moral of this story is verify what you have before you work on it. It all comes down to validating user input and user source.

Re: The Cryptographic Doom Principle

#112

Post by duaneb »

im3w1l wrote: post #84
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 ->…

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?

If you restrict the search space of the input, you also reduce the possible outputs, and that makes it easier to narrow down the key. However, it's only really plausible on very small inputs, another channel of attack (e.g. the ones illustrated in the article), or if you know something specific about the input.

TL;DR don't base64 without a reason because it gives the attacker more bytes with fewer values to work with.

Re: The Cryptographic Doom Principle

#115

Post by kkl »

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.

I do not have concerns with the mantra itself just it's usage and the entitlement that often comes along with using it. The top answer on this Stack Exchange question is a good example of what I believe to be proper usage of the mantra. http://security.stackexchange.com/questions/18197/why-should...

Re: The Cryptographic Doom Principle

#116

Post by a1a »

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.

Schneier's Law comes to mind

"Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break."

https://www.schneier.com/blog/archives/2011/04/schneiers_law...

Re: The Cryptographic Doom Principle

#117

Post by c22 »

madez wrote: post #100
c22 wrote: post #91

Earlier quoted context omitted.

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.

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

> Everyone cooks just with water.

The problem with applying this definition of "homegrown" is that it willfully ignores any distinction implied by the term and thus renders it semantically meaningless. This is a form of straw man.

Regardless, even if we assume that all crypto, at the time of writing, is equally likely to be safe, I posit that the security and cost of implementation benefits achieved by leveraging published techniques far outweighs the benefit of having an obscure fingerprint. This is because previously published methods have the advantage of selection and iterative hardening based on peer review.

Furthermore, I posit that even if you wrap your data in a matryoshka doll of encryption, each of these layers will be more secure when implemented using proven techniques.

For the same reasons I'd also argue that even if you were to develop your own cipher you would benefit more by publishing it than by keeping it a secret.

Another way to think about it is that "an attacker reading the documentation" should not be a failure mode of well-implemented crypto.

Speculating even deeper on the subject, it occurs to me that in the face of a global adversary (of whose automated cryptanalysis your proposal aims to thwart) displaying a unique fingerprint may actually be detrimental to the security of your data as it may flag it specifically for deeper inspection and manual analysis.

Re: The Cryptographic Doom Principle

#118

Post by c22 »

madez wrote: post #87
daeken wrote: post #82

Earlier quoted context omitted.

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.

The format of a discussion does not necessarily have to follow a strict pattern of point->counterpoint->point->counterpoint->win in order to be meaningful or useful to the participants and spectators.

Re: The Cryptographic Doom Principle

#119

Post by rcthompson »

pmalynin wrote: post #108
classicsnoot wrote: post #55

Earlier quoted context omitted.

Thank you for the link and the review. I start my CS degree in the Fall; i hope i can start and finish this before then.

For the love of all that is sacred, take advanced math and linear algebra.

I heartily agree with this sentiment. I have a friend who's a few years older than I am. He majored in CS, and told me in retrospect that he wished he had majored in mathematics instead. I took his advice, and, instead of doing CS major + a few math classes, I did math major + a few CS clases. I am now very glad that I did so. (For context, my friend and I are both data analysts now.)

Re: The Cryptographic Doom Principle

#120

Post by pmalynin »

rcthompson wrote: post #119
pmalynin wrote: post #108

Earlier quoted context omitted.

For the love of all that is sacred, take advanced math and linear algebra.

I heartily agree with this sentiment. I have a friend who's a few years older than I am. He majored in CS, and told me in retrospect that he wished he had majored in mathematics instead. I took his advice, and, instead of doing CS major + a few math classes, I did math major + a few CS clases. I am now very glad that I did so. (For context, my friend and I are both data analysts now.)

My comment comes from experience of being in progress of doing an Honors CS - Honors Math double major. After having completed Honors Calculus I/ II, Honors Linear Algebra Imy /II circuits in my first year I felt about 2-3 years ahead in my knowledge of mathematics and associated rigor -- this was especially evident when I was taking combined CS/EE courses and seeing student struggle with concepts that I thought were basic (infinimums, supremums, etc.) but apparently are not covered over the course of 2 years in the regular streams.
Post reply on HN