3 ms·

This is not really the most insightful comment, but anyway. I found the article to be needlessly defeatist. I am not a crypto expert. I've read Practical Cryp

by taway2012 13y ago

This is not really the most insightful comment, but anyway. I found the article to be needlessly defeatist. I am not a crypto expert. I've read Practical Cryptography and have a lots of experience with software engineering in general. This article (yet again) loosely says "crypto" without specifying whether he's talking about "crypto protocols" or "crypto primitives" (I use "protocol" in a theoretical sense: saving a file piped through gpg with passphrase rememembered in memory constitutes a protocol). It's well understood that mere mortals shouldn't create "crypto primitives". But I would argue that we're soon going to reach the point where many software engineers will have to understand crypto protocol creation. Just like many software engineers in the past 10 years or so have had to become aware of multicore (NoSQL, horizontal scaling, Go/Rust concurrency, probably even async callbacks in Javascript etc are all different aspect of multicore, imho). I don't think we as a profession should abdicate our responsibility to store/transport data securely by just saying "crypto is hard; so don't do it". I also take issue with the claim that crypto code is either 100% working, or 0% working. From a crypto theory point-of-view, yes, that is how cryptographers think. But in practice, there is a VAST difference between an attack that requires 2^32 INTERACTIONS with a remote server and one that requires 2^32 COMPUTATIONS on the attackers machine. A cryptographer would say both attacks are equally easy (kinda like O(n) notation). Just my two cents. And finally, re: the RNG vulnerability in Cryptocat, that is very bad and just sloppy coding. But even that vulnerability required that the attacker compromise the private SSL key of cryptocat's server. Defense in depth FTW.

tel 13y ago
I don't think practical cryptographers ignore the difference between computations and interactions—there are different threat models and they are carefully studied. Part of the problem might be that a system designed to be safe against 2^32 interactions is deployed in a place where the system is vulnerable to attacks on the order of 2^32 computations. The problem I think the author is highlighting is that the mistake risk distribution is hard to understand. Some kinds of off by one errors may cause relatively small reductions in security margins. Some kinds may cause complete loss of system integrity. It's hard to distinguish between the two without extensive testing and expertise. Furthermore, the kind of user who would never tell you about your error is exactly the kind who will find it. Finally, loss of your security infrastructure is unlikely to cause just small visual discomfort to your users—it's likely to hurt them materially.
dlitz 13y ago
No, it's not just crypto primitives, it's crypto protocols, too. It's even designing other protocols that run on top of crypto protocols (see CRIME). Even implementing existing crypto primitives is hazardous: D.J. Bernstein's work on cache timing attacks against AES are proof of that. The problem with crypto is that it's a specialist profession that generalists think they can do. In reality, crypto is more like law than software engineering: You can't just reason it from first principles, and you can't write any tests that will tell you that it's working. You have to know the specific attacks that people are capable of, and come up with a strategy that will avoid not only the current attacks that you know about, but future attacks that haven't been discovered yet. You're tasked with building a system of obstacles that nobody will be able to find any clever workarounds for, and your adversaries are smarter than you, more numerous than you, more well-funded than you, they're experts in breaking crypto, and they're all from the future. That's not something a handful of engineers working in isolation can do. It takes the whole community years to even come close. Saying that software engineers can design crypto protocols is like saying that software engineers can be their own lawyers. A few can, but almost all engineers who think they know the law are wrong. Even lawyers routinely lose cases. The best we can do is to try to give them better tools to handle the common cases (e.g. Creative Commons, SSH, better APIs), and remind them to talk to the specialists before getting too creative.
- deleted 13y ago
  [deleted]
tptacek 13y ago
The whole purpose of Cryptocat is that people are supposed to be able to use it without trusting the integrity of the server. That's practically the project thesis of Cryptocat.

tel 13y ago

I don't think practical cryptographers ignore the difference between computations and interactions—there are different threat models and they are carefully studied. Part of the problem might be that a system designed to be safe against 2^32 interactions is deployed in a place where the system is vulnerable to attacks on the order of 2^32 computations. The problem I think the author is highlighting is that the mistake risk distribution is hard to understand. Some kinds of off by one errors may cause relatively small reductions in security margins. Some kinds may cause complete loss of system integrity. It's hard to distinguish between the two without extensive testing and expertise. Furthermore, the kind of user who would never tell you about your error is exactly the kind who will find it. Finally, loss of your security infrastructure is unlikely to cause just small visual discomfort to your users—it's likely to hurt them materially.

dlitz 13y ago

No, it's not just crypto primitives, it's crypto protocols, too. It's even designing other protocols that run on top of crypto protocols (see CRIME). Even implementing existing crypto primitives is hazardous: D.J. Bernstein's work on cache timing attacks against AES are proof of that. The problem with crypto is that it's a specialist profession that generalists think they can do. In reality, crypto is more like law than software engineering: You can't just reason it from first principles, and you can't write any tests that will tell you that it's working. You have to know the specific attacks that people are capable of, and come up with a strategy that will avoid not only the current attacks that you know about, but future attacks that haven't been discovered yet. You're tasked with building a system of obstacles that nobody will be able to find any clever workarounds for, and your adversaries are smarter than you, more numerous than you, more well-funded than you, they're experts in breaking crypto, and they're all from the future. That's not something a handful of engineers working in isolation can do. It takes the whole community years to even come close. Saying that software engineers can design crypto protocols is like saying that software engineers can be their own lawyers. A few can, but almost all engineers who think they know the law are wrong. Even lawyers routinely lose cases. The best we can do is to try to give them better tools to handle the common cases (e.g. Creative Commons, SSH, better APIs), and remind them to talk to the specialists before getting too creative.

deleted 13y ago
[deleted]

tptacek 13y ago

The whole purpose of Cryptocat is that people are supposed to be able to use it without trusting the integrity of the server. That's practically the project thesis of Cryptocat.