38 ms·

Making sure crypto remains insecure [pdf]

439 points by zorked 12y ago

larssorenson 12y ago
Very eerie. Scary to imagine that the very systems we rely on are fundamentally flawed even more so than generic "NSA back doors," but down to policy of implementation.
- goalieca 12y ago
  They keep saying China is a big enemy, so it would not be surprising if they have growing resources to start exploiting these kinds of vulnerabilities as well. Should stop backdooring stuff in the name of terrorism because the economic and political damage of enemy states with growing IT resources is far worse IMHO.
jamesfisher 12y ago
> Try to scare implementors away from constant-time software. e.g. “It will be too slow.” “It’s too hard to write.” More generally, try to scare implementors away entirely. "Never roll your own crypto." Leave it to the experts -- i.e., NSA.
- Nursie 12y ago
  Erm, no. There are good reasons not to roll your own and none are to do with the NSA. One is that your own is likely full of flaws that you can't see but an attacker will spot in seconds. It's easy to write crypto you can't break yourself.
  - tptacek 12y ago
    Not so much "easy" as "inevitable". Everyone can write crypto they can't break themselves.
jstalin 12y ago
In other words, all crypto is broken?
- GestureBased 12y ago
  All, before implementation.
- a1369209993 12y ago
  Technically, I think it is only saying that all crytpo you know is not broken is broken.
cryptolect 12y ago
So subtlety and obfuscation to make good ideas sound bad (serpent), and bad ideas attractive (in the interest of performance and practicality). So when any standards body recommends a particular cryptographic approach, we should ask why, and then why again.
- tete 12y ago
  Currently they say performance and performance again. Sometimes they say nothing. Sometimes there is a good reason, sometimes there isn't. Sometimes they want to protect, sometimes they want to attack. That's the problem when you give one institution the job to do both.
jvehent 12y ago
Bernstein on a "thought experiment", analyzing how government could have deliberately weakened cryptographic standards through various means. It's actually quite compelling, given that we know DES key size was weakened by the NSA back in the 70s, against IBM's will, and that we know Dual_EC_DRBG was backdoored also by the NSA a few years ago. Bernstein's main point is that we need independent, peer-reviewed, cryptography that doesn't depend on government standardization. This talk is mostly a justification for his own work on ChaCha20/Poly1305 and DNSCurve, that were designed to be fast, constant-time and padding resistant. But the talk doesn't make mention of alternatives, except for Serpent that should have been a better cipher than Rijndael in the AES competition. A good read. I would love to see broader adoption of ChaCha20 in OpenSSL and its standardization in TLS1.3. Google already supports it and it needs more attention from cryptographic before we start using it everywhere. It also seems that SHA-3 has failed to convince, and everyone is standardizing on SHA-2 instead, despite the computational cost. Maybe here too we need an alternative...
- higherpurpose 12y ago
  I would also like to see Curve25519 (as well as others) supported in all browsers. It really bothers me that while at least websites are making an effort to default to ECDHE encryption with PFS, they have to resort to using the low-performance, insecure and probably NSA-backdoored P-256 curve, because most browsers aren't supporting anything else right now.
  - sarciszewski 12y ago
    I agree. Through PECL, PHP is soon going to have curve25519 support http://pecl.php.net/package/libsodium http://pecl.php.net/package/libsodium There's already a Node-Sodium package... https://github.com/paixaop/node-sodium https://github.com/paixaop/node-sodium Why can't browsers support it natively? (e.g. through NSS)
  - jvehent 12y ago
    If anyone has the time and skills to implement these curves in NSS, I'm sure that the Firefox and Chrome security teams would be more than happy to enable them!
higherpurpose 12y ago
Dan, your sliders are hard to read online, because you make us read the same slide four times, just for an extra sentence on each. It's distracting. So please just put together the "full" slides when you put them online.
- tete 12y ago
  Most PDF readers have a presentation/full screen mode for this (even pdf.js in Firefox does). The nice thing about them is that PDFs work nearly everywhere (if they are made that way, which in this case appears to be true).
- pea 12y ago
  I've put them on Kivo, which might be easier to view and so people can annotate them. https://kivo.com/p/h985rFcI https://kivo.com/p/h985rFcI
- tptacek 12y ago
  The supposition here is that maybe Bernstein didn't consider that raw presentation foils were harder to read online than slideshows?
Taek 12y ago
I don't think that most of the problems stem from the NSA, most of the problems stem from the fact that security is hard, and we don't culturally have a proper appreciation of this. We love complexity, we love adding features and wrappers and creating libraries, and when it comes to security this complicates things very quickly. You end up with massive specifications, layers of dependencies, and lots of code. And in many cases a single bug in the code can compromise the entire system. In security, complexity is very much the enemy and we don't apply that mentality forcefully enough. The crypto world is evolving quickly, and new vulnerabilities appear. Backdoors appear, ciphers get compromised, this or that RNG is shown to be flawed, etc. And when something that your application uses gets broken, are you going to know? If you do know, are you going to be able to swap it out for something more secure, or is that going to cause a lot of pain and dev time? Lots of applications are going to prefer the single patch hotfix to the system redesign. And this introduces more weaknesses, because often the hotfix only addresses the single attack, and not the core vulnerability that made the attack possible. Future attacks may be harder, but they haven't been made impossible. (But... it's good enough, right? It'd be like, way harder now to create an attack... right?) Building properly secure applications is hard, because it requires you to be minimalist, modular, and it requires you to pay attention to the latest security problems and be aware of the types of problems you can introduce when you implement something. Security is incredibly nuanced and you have to be properly aware of all the nuances. A single weakness in your entire stack can affect your whole system if you haven't carefully configured your applications. Crypto is broken because crypto is hard, and application builders will take the easy way out, often without realizing that they're taking the easy way out. Although the NSA has been shown to be an issue, most of the problems seem to come from our own ignorance when trying to build secure applications, and there's no silver bullet. Creating reliably secure systems is only possible when working with simple systems. Right now, the Internet is built with a ton of complexity. Operating systems are built with a ton of complexity. There are many libraries with different implementations and they all interact together in ways that are difficult to track. (IE shellshock... who would have thought that Bash would be vulnerable?). We aren't going to have real security until we melt all of this complexity away, and until we train ourselves to view complexity as an enemy, and until we culturally appreciate how difficult and nuanced security is. And that's going to take a long time and a lot of effort.
tptacek 12y ago
This is a fun slide deck, but if you'll forgive me for sucking some of the mystique out of it: it's just a reframing of DJB's hobby horses: * The group that standardized AES rejected cache timing as a viable attack vector: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf --- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein's work for the last 15+ years) aren't taken seriously in industry. Also helpful to know: there's a defensible argument that Bernstein more or less started AES cache timing research. * Side-channel attacks weren't taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: http://www.isg.rhul.ac.uk/tls/Lucky13.html http://www.isg.rhul.ac.uk/tls/Lucky13.html * Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html * Protocols and constructions should be designed to minimize dependence on randomness, the way DJB's EdDSA does: http://ed25519.cr.yp.to/ed25519-20110926.pdf http://ed25519.cr.yp.to/ed25519-20110926.pdf * Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn't so much a hobby horse of DJB's as it is his entire research career: http://cr.yp.to/cv/research-net-20070115.pdf http://cr.yp.to/cv/research-net-20070115.pdf * DNSSEC, with its core design goals of "sign-only", "sign offline", and "sign from the root down" is a terrible idea. A sane design would look more like DNSCurve: http://dnscurve.org/ http://dnscurve.org/ (helps also to know that DJB has a longstanding feud with both the design team for BIND, the flagship DNSSEC implementation, and with Namedroppers, the IETF DNS standardization list). Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I'm certainly not trying to take him down a peg here. I just thought it might be interesting for people to know that this deck is less a revelation about cryptography than it is a survey of DJB's research over the last 15 years. I'm surprised he didn't take more time on RC4, which he was closely involved with breaking. The story about how something as dazzlingly broken as RC4 could have gotten so entrenched in the industry is much more interesting than the story about how AES was standardized despite its performance relying so much on table lookups.
- jvehent 12y ago
  I found this particular talk to be different that the usual DJB. It felt more like a self-reflection on why, despite being technically correct, his cryptographic solutions always fail to gain mainstream traction. I have a lot of respect for DJB and for the way he always challenges the status-quo. This talk is an excellent summary of the current issues in the crypto industry. But he ignores the fact that we use AES, SHA and RC4 because _it's easy to use them_. And his solutions are never easy to use. Make Nacl dead simple to use. Write clients and servers that use it. Integrate it into Firefox, Chrome, Dovecot, Nginx, Postfix, cUrl, etc... and people will slowly move away from TLS and its broken crypto.
Animats 12y ago
He's right about the low entropy of many crypto random number generators. There are so many cases of this that it can't be by accident. 2013: Android random number flaw exploited for Bitcoin theft. http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/ http://arstechnica.com/security/2013/08/google-confirms-crit... Backdoor in RSA? http://arstechnica.com/security/2014/01/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer/ http://arstechnica.com/security/2014/01/how-the-nsa-may-have... Linus Torvalds insists on accepting Intel patch to use their hardware random number generator directly instead of just using it as one of multiple sources being XORed together. http://cryptome.org/2013/07/intel-bed-nsa.htm http://cryptome.org/2013/07/intel-bed-nsa.htm Then there are "features" in SSL/TLS which make little sense, such as the ability to change the cryptosystem during the connection. This includes changing it to "None". That's been exploited. http://www.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack http://www.praetorian.com/blog/man-in-the-middle-tls-ssl-pro...
- tptacek 12y ago
  Regarding Android: not only could it be an accident, it almost certainly is an accident. For instance: the Android RNG flaw didn't stem from a single coherent design flaw, but rather from the meta-flaw of relying on application-layer (or in this case runtime-layer) randomness, and not nailing the order of initialization in all the components. It's easy to see why this would have happened by accident: (a) the belief that runtime-layer randomness is better, more performant, more reliable on mobile platform and (b) the lack of understanding that a single central kernel-level RNG is superior to app-layer RNGs (which is a relatively modern idea). Regarding RSA: that's not a backdoor in RSA. That's a supposed backdoor in BSAFE, a library sold by RSA. The story pertains to BSAFE's support for the Dual-EC PKRNG. (Of the supposed backdoors propagated by the NSA, by the way, this is probably the most credible). I'm not sure what your allusion to Torvalds was meant to indicate. The SSL/TLS downgrade attack you linked to didn't have anything to do with the "None" ciphersuite, or re-negotiation.
  - Animats 12y ago
    I'm not sure what your allusion to Torvalds was meant to indicate. This. Right here is where Linus Torvalds sold out: https://lkml.org/lkml/2012/7/5/425 https://lkml.org/lkml/2012/7/5/425 FreeBSD didn't: http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...
pdkl95 12y ago
Re: timing attacks - can these be protected against by simply inserting into a protocol a mandatory random sleep that is strictly larger than the worst case run time of the crypto implementation? For example, if it takes up to 1s to run the crypto, would a protocol that required a usleep() of uniform_random(5s..10s)? Such a scheme would obscure any variations in timing, right? I ask because I have been thinking recently about the cost of "realtime", when many use-cases don't actually need it. Bittorrent exploits this idea - multicast is hard and most methods never really worked well enough to become popular. Then bittorrent comes along and gives up on the idea preserving an ordered, realtime-streamable transmission. In return, bittorrent got a lot of other features and became a very useful tool. As these slides mention - it is easy to be blinded by a supposed need to make everything fast. (brainstorming) Perhaps something like a modern variation on the batched store-and-forward used in the old FidoNet could be useful for non-interactive needs; instead of trying to save on long-distance fees it tries use ideas like the usleep("many seconds or more") and much larger (slower) key sizes. /* Given the tone of those slides, I would guess that DJB just saw PHK's amazing "Operation Orchestra" talk? BULLRUN? "PSYOPS for nerds"? The lesson is important either way. */
- MichaelGG 12y ago
  Adding random sleeps does not prevent timing attacks. It just adds noise making them a bit more work to pull off.
  - e12e 12y ago
    I suppose one (not very good) approach to "patching-in" constant run-time, would be to limit the runtime of every iteration to be that of the upper bound (possibly +some constant). I suspect that's pretty hard to actually do, and even if accomplished, would open up to other side-channel/timming attacks (eg: check cpu load, and infer timing).
  - robryk 12y ago
    But, if you have an upper bound on the time of the operation, you can wait until the bound elapses, so that your operation always takes that long.
switch33 12y ago
Crypto insecurity is just one of many concerns and it is missing somewhat of the point. There will always be debate over it. There is a chilling effect that big tech companies in the US have been working on side channels for nearly any protocol that is ever developed. There needs to be research into side channel resistant crypto as well. But what about the bigger growing trend in computing that is causing more troubles (dependency growing system wrappers)?: Has anyone else noticed the trend for wrappers over increasingly larger and larger parts of operating systems? For example systemd (https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd) while good for providing automation provides even more system administration power by controlling package managers. Docker contains configuration information for the full app that is being deployed contained within that container as well. It will take quite some time to make docker more secure, and using it may contain some level of attacks. And hypervisors as well are larger and larger in size as well. There is becoming an increasing standard for the amount of code in frameworks, platforms, operating systems and more for interoperability. While these are good things that need to happen as fixes need to be quicker, they are also bad things in that they provide newer larger attack surfaces. Cloud computing is also becoming more and more rewarding for heavyset computation and sharing of resources. The ambiguity in choice of it all means that there will inevitably be a plethora of choices in the cloud. The dependencies in frameworks and how we develop software has continously grown over the years as well to the point that people are using things like versioneye: https://www.versioneye.com/ https://www.versioneye.com/ to sort changes in it all. While diversity is good and the cloud ecosystem is becoming more profitable. Why is there almost no security company focused on making the "cloud" tamper resistant? (i.e. monitoring docker containers and looking for misconfigurations etc even on github) There definitely should be a working effort in that retrospect. It is also equally problematic that cloud software will be ambiguous in design. Cloud software that is built to be fast may use a custom in-house Just-In-Time code engine for faster database or code execution which may be harder to really address security wise. In retrospect there are many security companies that are working towards securing the appstores, why should they not be working towards securing/integrating with cloud providers? There should also be more opensource security anti-viruses besides just clamav. For people to be secure there should be a newer trend into opensourcing specific security modules and working towards a functioning operational level of configuration/management security as well as malware detection.
pflanze 12y ago
A previous version of this slide set has been published and discussed here: https://news.ycombinator.com/item?id=8023812 https://news.ycombinator.com/item?id=8023812 I did put up a version of those older slides in markdown format on Github here: https://github.com/pflanze/slides-djb-20140710/blob/master/slides.md https://github.com/pflanze/slides-djb-20140710/blob/master/s... (Perhaps someone feels like forking and merging in the changes?)
meshy 12y ago
Does it seem ironic to anyone else that this was served over HTTP?

439 points by zorked 12y ago

Very eerie. Scary to imagine that the very systems we rely on are fundamentally flawed even more so than generic "NSA back doors," but down to policy of implementation.

goalieca 12y ago
They keep saying China is a big enemy, so it would not be surprising if they have growing resources to start exploiting these kinds of vulnerabilities as well. Should stop backdooring stuff in the name of terrorism because the economic and political damage of enemy states with growing IT resources is far worse IMHO.

jamesfisher 12y ago

> Try to scare implementors away from constant-time software. e.g. “It will be too slow.” “It’s too hard to write.” More generally, try to scare implementors away entirely. "Never roll your own crypto." Leave it to the experts -- i.e., NSA.

Nursie 12y ago
Erm, no. There are good reasons not to roll your own and none are to do with the NSA. One is that your own is likely full of flaws that you can't see but an attacker will spot in seconds. It's easy to write crypto you can't break yourself.
- tptacek 12y ago
  Not so much "easy" as "inevitable". Everyone can write crypto they can't break themselves.

jstalin 12y ago

In other words, all crypto is broken?

GestureBased 12y ago
All, before implementation.
a1369209993 12y ago
Technically, I think it is only saying that all crytpo you know is not broken is broken.

cryptolect 12y ago

So subtlety and obfuscation to make good ideas sound bad (serpent), and bad ideas attractive (in the interest of performance and practicality). So when any standards body recommends a particular cryptographic approach, we should ask why, and then why again.

tete 12y ago
Currently they say performance and performance again. Sometimes they say nothing. Sometimes there is a good reason, sometimes there isn't. Sometimes they want to protect, sometimes they want to attack. That's the problem when you give one institution the job to do both.

jvehent 12y ago

Bernstein on a "thought experiment", analyzing how government could have deliberately weakened cryptographic standards through various means. It's actually quite compelling, given that we know DES key size was weakened by the NSA back in the 70s, against IBM's will, and that we know Dual_EC_DRBG was backdoored also by the NSA a few years ago. Bernstein's main point is that we need independent, peer-reviewed, cryptography that doesn't depend on government standardization. This talk is mostly a justification for his own work on ChaCha20/Poly1305 and DNSCurve, that were designed to be fast, constant-time and padding resistant. But the talk doesn't make mention of alternatives, except for Serpent that should have been a better cipher than Rijndael in the AES competition. A good read. I would love to see broader adoption of ChaCha20 in OpenSSL and its standardization in TLS1.3. Google already supports it and it needs more attention from cryptographic before we start using it everywhere. It also seems that SHA-3 has failed to convince, and everyone is standardizing on SHA-2 instead, despite the computational cost. Maybe here too we need an alternative...

higherpurpose 12y ago
I would also like to see Curve25519 (as well as others) supported in all browsers. It really bothers me that while at least websites are making an effort to default to ECDHE encryption with PFS, they have to resort to using the low-performance, insecure and probably NSA-backdoored P-256 curve, because most browsers aren't supporting anything else right now.
- sarciszewski 12y ago
  I agree. Through PECL, PHP is soon going to have curve25519 support http://pecl.php.net/package/libsodium http://pecl.php.net/package/libsodium There's already a Node-Sodium package... https://github.com/paixaop/node-sodium https://github.com/paixaop/node-sodium Why can't browsers support it natively? (e.g. through NSS)
- jvehent 12y ago
  If anyone has the time and skills to implement these curves in NSS, I'm sure that the Firefox and Chrome security teams would be more than happy to enable them!

higherpurpose 12y ago

Dan, your sliders are hard to read online, because you make us read the same slide four times, just for an extra sentence on each. It's distracting. So please just put together the "full" slides when you put them online.

tete 12y ago
Most PDF readers have a presentation/full screen mode for this (even pdf.js in Firefox does). The nice thing about them is that PDFs work nearly everywhere (if they are made that way, which in this case appears to be true).
pea 12y ago
I've put them on Kivo, which might be easier to view and so people can annotate them. https://kivo.com/p/h985rFcI https://kivo.com/p/h985rFcI
tptacek 12y ago
The supposition here is that maybe Bernstein didn't consider that raw presentation foils were harder to read online than slideshows?

Taek 12y ago

I don't think that most of the problems stem from the NSA, most of the problems stem from the fact that security is hard, and we don't culturally have a proper appreciation of this. We love complexity, we love adding features and wrappers and creating libraries, and when it comes to security this complicates things very quickly. You end up with massive specifications, layers of dependencies, and lots of code. And in many cases a single bug in the code can compromise the entire system. In security, complexity is very much the enemy and we don't apply that mentality forcefully enough. The crypto world is evolving quickly, and new vulnerabilities appear. Backdoors appear, ciphers get compromised, this or that RNG is shown to be flawed, etc. And when something that your application uses gets broken, are you going to know? If you do know, are you going to be able to swap it out for something more secure, or is that going to cause a lot of pain and dev time? Lots of applications are going to prefer the single patch hotfix to the system redesign. And this introduces more weaknesses, because often the hotfix only addresses the single attack, and not the core vulnerability that made the attack possible. Future attacks may be harder, but they haven't been made impossible. (But... it's good enough, right? It'd be like, way harder now to create an attack... right?) Building properly secure applications is hard, because it requires you to be minimalist, modular, and it requires you to pay attention to the latest security problems and be aware of the types of problems you can introduce when you implement something. Security is incredibly nuanced and you have to be properly aware of all the nuances. A single weakness in your entire stack can affect your whole system if you haven't carefully configured your applications. Crypto is broken because crypto is hard, and application builders will take the easy way out, often without realizing that they're taking the easy way out. Although the NSA has been shown to be an issue, most of the problems seem to come from our own ignorance when trying to build secure applications, and there's no silver bullet. Creating reliably secure systems is only possible when working with simple systems. Right now, the Internet is built with a ton of complexity. Operating systems are built with a ton of complexity. There are many libraries with different implementations and they all interact together in ways that are difficult to track. (IE shellshock... who would have thought that Bash would be vulnerable?). We aren't going to have real security until we melt all of this complexity away, and until we train ourselves to view complexity as an enemy, and until we culturally appreciate how difficult and nuanced security is. And that's going to take a long time and a lot of effort.

tptacek 12y ago

This is a fun slide deck, but if you'll forgive me for sucking some of the mystique out of it: it's just a reframing of DJB's hobby horses: * The group that standardized AES rejected cache timing as a viable attack vector: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf --- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein's work for the last 15+ years) aren't taken seriously in industry. Also helpful to know: there's a defensible argument that Bernstein more or less started AES cache timing research. * Side-channel attacks weren't taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: http://www.isg.rhul.ac.uk/tls/Lucky13.html http://www.isg.rhul.ac.uk/tls/Lucky13.html * Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html * Protocols and constructions should be designed to minimize dependence on randomness, the way DJB's EdDSA does: http://ed25519.cr.yp.to/ed25519-20110926.pdf http://ed25519.cr.yp.to/ed25519-20110926.pdf * Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn't so much a hobby horse of DJB's as it is his entire research career: http://cr.yp.to/cv/research-net-20070115.pdf http://cr.yp.to/cv/research-net-20070115.pdf * DNSSEC, with its core design goals of "sign-only", "sign offline", and "sign from the root down" is a terrible idea. A sane design would look more like DNSCurve: http://dnscurve.org/ http://dnscurve.org/ (helps also to know that DJB has a longstanding feud with both the design team for BIND, the flagship DNSSEC implementation, and with Namedroppers, the IETF DNS standardization list). Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I'm certainly not trying to take him down a peg here. I just thought it might be interesting for people to know that this deck is less a revelation about cryptography than it is a survey of DJB's research over the last 15 years. I'm surprised he didn't take more time on RC4, which he was closely involved with breaking. The story about how something as dazzlingly broken as RC4 could have gotten so entrenched in the industry is much more interesting than the story about how AES was standardized despite its performance relying so much on table lookups.

jvehent 12y ago
I found this particular talk to be different that the usual DJB. It felt more like a self-reflection on why, despite being technically correct, his cryptographic solutions always fail to gain mainstream traction. I have a lot of respect for DJB and for the way he always challenges the status-quo. This talk is an excellent summary of the current issues in the crypto industry. But he ignores the fact that we use AES, SHA and RC4 because _it's easy to use them_. And his solutions are never easy to use. Make Nacl dead simple to use. Write clients and servers that use it. Integrate it into Firefox, Chrome, Dovecot, Nginx, Postfix, cUrl, etc... and people will slowly move away from TLS and its broken crypto.

Animats 12y ago

He's right about the low entropy of many crypto random number generators. There are so many cases of this that it can't be by accident. 2013: Android random number flaw exploited for Bitcoin theft. http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/ http://arstechnica.com/security/2013/08/google-confirms-crit... Backdoor in RSA? http://arstechnica.com/security/2014/01/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer/ http://arstechnica.com/security/2014/01/how-the-nsa-may-have... Linus Torvalds insists on accepting Intel patch to use their hardware random number generator directly instead of just using it as one of multiple sources being XORed together. http://cryptome.org/2013/07/intel-bed-nsa.htm http://cryptome.org/2013/07/intel-bed-nsa.htm Then there are "features" in SSL/TLS which make little sense, such as the ability to change the cryptosystem during the connection. This includes changing it to "None". That's been exploited. http://www.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack http://www.praetorian.com/blog/man-in-the-middle-tls-ssl-pro...

tptacek 12y ago
Regarding Android: not only could it be an accident, it almost certainly is an accident. For instance: the Android RNG flaw didn't stem from a single coherent design flaw, but rather from the meta-flaw of relying on application-layer (or in this case runtime-layer) randomness, and not nailing the order of initialization in all the components. It's easy to see why this would have happened by accident: (a) the belief that runtime-layer randomness is better, more performant, more reliable on mobile platform and (b) the lack of understanding that a single central kernel-level RNG is superior to app-layer RNGs (which is a relatively modern idea). Regarding RSA: that's not a backdoor in RSA. That's a supposed backdoor in BSAFE, a library sold by RSA. The story pertains to BSAFE's support for the Dual-EC PKRNG. (Of the supposed backdoors propagated by the NSA, by the way, this is probably the most credible). I'm not sure what your allusion to Torvalds was meant to indicate. The SSL/TLS downgrade attack you linked to didn't have anything to do with the "None" ciphersuite, or re-negotiation.
- Animats 12y ago
  I'm not sure what your allusion to Torvalds was meant to indicate. This. Right here is where Linus Torvalds sold out: https://lkml.org/lkml/2012/7/5/425 https://lkml.org/lkml/2012/7/5/425 FreeBSD didn't: http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...

pdkl95 12y ago

Re: timing attacks - can these be protected against by simply inserting into a protocol a mandatory random sleep that is strictly larger than the worst case run time of the crypto implementation? For example, if it takes up to 1s to run the crypto, would a protocol that required a usleep() of uniform_random(5s..10s)? Such a scheme would obscure any variations in timing, right? I ask because I have been thinking recently about the cost of "realtime", when many use-cases don't actually need it. Bittorrent exploits this idea - multicast is hard and most methods never really worked well enough to become popular. Then bittorrent comes along and gives up on the idea preserving an ordered, realtime-streamable transmission. In return, bittorrent got a lot of other features and became a very useful tool. As these slides mention - it is easy to be blinded by a supposed need to make everything fast. (brainstorming) Perhaps something like a modern variation on the batched store-and-forward used in the old FidoNet could be useful for non-interactive needs; instead of trying to save on long-distance fees it tries use ideas like the usleep("many seconds or more") and much larger (slower) key sizes. /* Given the tone of those slides, I would guess that DJB just saw PHK's amazing "Operation Orchestra" talk? BULLRUN? "PSYOPS for nerds"? The lesson is important either way. */

MichaelGG 12y ago
Adding random sleeps does not prevent timing attacks. It just adds noise making them a bit more work to pull off.
- e12e 12y ago
  I suppose one (not very good) approach to "patching-in" constant run-time, would be to limit the runtime of every iteration to be that of the upper bound (possibly +some constant). I suspect that's pretty hard to actually do, and even if accomplished, would open up to other side-channel/timming attacks (eg: check cpu load, and infer timing).
- robryk 12y ago
  But, if you have an upper bound on the time of the operation, you can wait until the bound elapses, so that your operation always takes that long.

switch33 12y ago

Crypto insecurity is just one of many concerns and it is missing somewhat of the point. There will always be debate over it. There is a chilling effect that big tech companies in the US have been working on side channels for nearly any protocol that is ever developed. There needs to be research into side channel resistant crypto as well. But what about the bigger growing trend in computing that is causing more troubles (dependency growing system wrappers)?: Has anyone else noticed the trend for wrappers over increasingly larger and larger parts of operating systems? For example systemd (https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd) while good for providing automation provides even more system administration power by controlling package managers. Docker contains configuration information for the full app that is being deployed contained within that container as well. It will take quite some time to make docker more secure, and using it may contain some level of attacks. And hypervisors as well are larger and larger in size as well. There is becoming an increasing standard for the amount of code in frameworks, platforms, operating systems and more for interoperability. While these are good things that need to happen as fixes need to be quicker, they are also bad things in that they provide newer larger attack surfaces. Cloud computing is also becoming more and more rewarding for heavyset computation and sharing of resources. The ambiguity in choice of it all means that there will inevitably be a plethora of choices in the cloud. The dependencies in frameworks and how we develop software has continously grown over the years as well to the point that people are using things like versioneye: https://www.versioneye.com/ https://www.versioneye.com/ to sort changes in it all. While diversity is good and the cloud ecosystem is becoming more profitable. Why is there almost no security company focused on making the "cloud" tamper resistant? (i.e. monitoring docker containers and looking for misconfigurations etc even on github) There definitely should be a working effort in that retrospect. It is also equally problematic that cloud software will be ambiguous in design. Cloud software that is built to be fast may use a custom in-house Just-In-Time code engine for faster database or code execution which may be harder to really address security wise. In retrospect there are many security companies that are working towards securing the appstores, why should they not be working towards securing/integrating with cloud providers? There should also be more opensource security anti-viruses besides just clamav. For people to be secure there should be a newer trend into opensourcing specific security modules and working towards a functioning operational level of configuration/management security as well as malware detection.

pflanze 12y ago

A previous version of this slide set has been published and discussed here: https://news.ycombinator.com/item?id=8023812 https://news.ycombinator.com/item?id=8023812 I did put up a version of those older slides in markdown format on Github here: https://github.com/pflanze/slides-djb-20140710/blob/master/slides.md https://github.com/pflanze/slides-djb-20140710/blob/master/s... (Perhaps someone feels like forking and merging in the changes?)

meshy 12y ago

Does it seem ironic to anyone else that this was served over HTTP?