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

101–110 of 140 posts

Re: The Cryptographic Doom Principle

#101

Post by rudolf0 »

madez wrote: post #98
rudolf0 wrote: post #92

Earlier quoted context omitted.

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

The plausibility of a vulnerability in AES which reduces the search space by more than half of the key bits is essentially 0.

Re: The Cryptographic Doom Principle

#102

Post by stouset »

madez wrote: post #69
stouset wrote: post #54

Earlier quoted context omitted.

Technically correct is usually the least useful kind of correct. The root of this thread is extremely sound advice. Don't touch your own crypto unless you're an expert. If you're at the point where your security requirements are so sensitive that you can't possibly risk a break in an underlying well-known cipher, you should hire a real cryptographer and not dick around with inventing your own laughably-broken ciphers…

So I think it comes down to whether the root > I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. is a sound advice. I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert. Furthermore, I described a relatively simple protocol that monotonically increases the secu…

Nobody is arguing against tinkering with cryptography as a mechanism for learning. This advice is meant to stop people from writing homebrew encryption for real-world, production systems.

You described a relatively simple protocol that, at worst, does not decrease security in a theoretical sense with at least one critically-important and unmentioned caveat (don't use the same or related keys for both ciphers). In a practical sense, your simple protocol is likely a security disaster.

In the absolute best case, it really only defends against a break in the underlying cipher that is so thoroughly devastating that ciphertexts can be decrypted essentially for free. Even DES hasn't been broken this badly, and it's been considered broken for decades. The reason this is the case is that such a simple transform is only useful against an entity that is automatically decrypting ciphertexts on the wire en masse, and who isn't looking for your data specifically. Against a targeted adversary who can "merely" break AES with substantial effort, the additional cost such a transform would impose is completely negligible. In your example of a transform on top of a TLS connection, it would be completely obvious through packet analysis that the protocol was TLS, and your transform would be trivially understood and reversed after watching a few handshakes.

Re: The Cryptographic Doom Principle

#103

Post by tptacek »

derekp7 wrote: post #96
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.

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.

Same as "rolling your own crypto"; in fact, that's generally, except in extreme cases, exactly what we're referring to when we talk about people rolling their own.

Re: The Cryptographic Doom Principle

#104

Post by crpatino »

derekp7 wrote: post #96
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.

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.

You are probably going to get it wrong, not because there's anything bad with you, but because standard crypto libraries are too fine grained. The primitives are too low level, and you have to assemble sequences of calls in the right order and be in the watch for unexpected side effects.

I could tell you how I have gotten it wrong in the past, but there is no guarantee that I won't get it wrong again in a different way. So, the audit idea has it's merits, but you really want not to rely on the Linus Law of eyeballs. That means knowledgeable auditors who charge actual money for their time.

Re: The Cryptographic Doom Principle

#105

Post by stouset »

bitL wrote: post #62
3am wrote: post #47

Earlier quoted context omitted.

1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong. 2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects. 3) Trite sounds bites don't work in science either, and expert -/-…

Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellen…

> someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down

I'm sorry, but this is essentially never the case. This is no different than in other fields, for instance math or physics, where complete novices come in every day believing they've had a completely novel idea that will revolutionize the field. 999,999 times out of a million they haven't, and in the one remaining case they've come up with a solution in search of a problem.

"Oh, you've come up with a new cipher? Congratulations. Assuming it is secure, why should we use it ? Is it faster than existing ones? Simpler and more likely to be implemented correctly? Resistant to timing attacks? Resistant to CPU power analysis? Resistant to differential cryptanalysis? Suitable for low-CPU and low-memory embedded devices? Oh, none of these things? Gee, how interesting."

I'm reminded of http://www.scottaaronson.com/blog/?p=304

Re: The Cryptographic Doom Principle

#106

Post by Kalium »

bitL wrote: post #62
3am wrote: post #47

Earlier quoted context omitted.

1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong. 2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects. 3) Trite sounds bites don't work in science either, and expert -/-…

Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellen…

> Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact.

Crypto is an environment where a single mistake can get people killed. The stakes are very high. We're not talking about a slight rendering error in CSS here. This is not an appropriate place to be universally warm, fuzzy, encouraging, and forgiving of mistakes. This is incredibly serious stuff that must be treated appropriately seriously - and everyone attempting to touch the field needs to understand that.

In addition, stouset is right. The frequency with which apparently novel ideas are actually novel is much, much, much smaller than a naive guess would lead one to expect. I've watched people attempt to introduce ideas that strike them as novel, only to discover that they're just creating exploitable weaknesses, right here on Hacker News.

Re: The Cryptographic Doom Principle

#107

Post by stouset »

madez wrote: post #42
kelson wrote: post #36

Earlier quoted context omitted.

> I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong. Per the other thread, this is overwhelmingly likely to decrease overall security without any practical benefit. > My scheme adds security through obscurity which may be worth the trouble. It adds potential side channels and likely no benefit over KC alone. You've sidelined many potent…

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…

This protects only against an attacker who has broken AES so thoroughly that they can essentially surveil TLS traffic en masse at no cost.

To a targeted attacker, TLS is trivially identifiable through packet analysis. After a few handshakes, your transform (as mentioned elsewhere, reverse some nybbles and XOR against a constant) will be fully understood and broken with likely less effort than it cost you to build in the first place.

Re: The Cryptographic Doom Principle

#108

Post by pmalynin »

classicsnoot wrote: post #55
bradleyjg wrote: post #22

Earlier quoted context omitted.

That's good advice, and I've given it myself, but that doesn't mean you shouldn't read and play around with cryptography if it interests you. I implemented a simplified version of the referenced Vaudenay attack as part of Dan Boneh's Cryptography I course on courseara+. The course was very interesting, and also fun. I'm not ready to go out and implement my own cryptography, but knowing a bit about the subject makes m…

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.

Re: The Cryptographic Doom Principle

#109

Post by kyberias »

sarciszewski wrote: post #43
tekromancr wrote: post #34

Earlier quoted context omitted.

Rectal-Numerical Generation...

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

It slightly decreases the validity of the page when it states that ASP.NET is a programming language.

Re: The Cryptographic Doom Principle

#110

Post by derekp7 »

tptacek wrote: post #103
derekp7 wrote: post #96

Earlier quoted context omitted.

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.

Same as "rolling your own crypto"; in fact, that's generally, except in extreme cases, exactly what we're referring to when we talk about people rolling their own.

So what are my options then? I could put out an initial version that shows what I want to accomplish, then either have it reviewed heavily, or see if I can get someone who's more of an expert to give it a go based on those specifications. Here's the problems I have so far, which I know I'm out of my depth:

1) In order to keep the backup software's deduplication functionality (and to minimize the server trusting the client), I need to have the IV (initialization vector) be a computed value based on the file's contents (so that multiple copies of the same file on the clients will encrypt to the same contents going to the backend server). I know that _This will leak some data_ (i.e., you may not want an attacker to know that a given set of files are the same contents). So I plan on making this optional -- either the user gets to take advantage of dedup, or better encryption.

2) To do number 1 above, I was planning on taking a hash of the file, encrypting that with the users key, then using that as a predictable IV. You will still have a unique IV per unique file, but I don't know enough to see if this can leak any other data. It looks like RFC 5297 describes an approach similar to this, but I think it is for a different use case.

3) I need the backup server to know which version of an encryption key the client used. That is, if the client changes keys between backups, I need the server to instruct the client to do a full backup, not incremental. So I can either have the client provide a version number for the key (or if using a keyfile, use the datestamp of the file as a version string), or I can encrypt a given string using the key, and use a hash of the encrypted string as the key version number. (Note, in no case will I ever be storing a hash of the plaintext of the client's files on the backup server, as that too can leak information)

My apologies if the above makes any experts here cringe, but as I mentioned my constraint is to have same-content files encrypted to the same target contents (for dedup purposes), although I will give the user to turn that off and use a random IV for better security (and give up dedup).

Post reply on HN