Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Current Crypto Best Practices

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Ask HN: Current Crypto Best Practices

#61

Post by mtrpcic »

bsder wrote: post #57
cvwright wrote: post #53

I'm surprised to see so few recommendations for libsodium. https://download.libsodium.org/doc/ For pretty much any crypto task that a "run-of-the-mill programmer" is likely to run into, they've got you covered. Secret key encryption: https://download.libsodium.org/doc/secret-key_cryptography/a... Password hashing: https://download.libsodium.org/doc/password_hashing/

I would go for TweetNaCl instead. The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous. Most people don't need SSL. Most people don't need a zillion choices. Most people need a single choice that actually works and is resistant to programmer error.

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an unused method is a huge risk.

Re: Ask HN: Current Crypto Best Practices

#62

Post by cjbprime »

mtrpcic wrote: post #61
bsder wrote: post #57

Earlier quoted context omitted.

I would go for TweetNaCl instead. The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous. Most people don't need SSL. Most people don't need a zillion choices. Most people need a single choice that actually works and is resistant to programmer error.

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an u…

Look into the history of OpenSSL vulns -- many are in obscure TLS paths that application developers did not intend to be supporting.

I think Heartbleed's even an example? Apparently there's some TLS ping ("heartbeat") command in the protocol that I'm pretty sure no-one actually asked for or uses in their applications, but there it is in the code, and so you're vulnerable as an application author.

Re: Ask HN: Current Crypto Best Practices

#63

Post by derefr »

cjbprime wrote: post #62
mtrpcic wrote: post #61

Earlier quoted context omitted.

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an u…

Look into the history of OpenSSL vulns -- many are in obscure TLS paths that application developers did not intend to be supporting. I think Heartbleed's even an example? Apparently there's some TLS ping ("heartbeat") command in the protocol that I'm pretty sure no-one actually asked for or uses in their applications, but there it is in the code, and so you're vulnerable as an application author.

That's a different kind of thing—TLS is an extensible protocol, where its various extensions (i.e. code paths) are activated by patterns of data on the wire. libsodium is just a set of components—you can know at compile time exactly which functions in libsodium will or will not ever be called by your program, and can, if you like, use a linker that does LTO to prune the majority of the library out.

Re: Ask HN: Current Crypto Best Practices

#64

Post by bsder »

mtrpcic wrote: post #61
bsder wrote: post #57

Earlier quoted context omitted.

I would go for TweetNaCl instead. The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous. Most people don't need SSL. Most people don't need a zillion choices. Most people need a single choice that actually works and is resistant to programmer error.

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an u…

> Isn't the attack surface limited to the methods used in the application though?

No, because the combination of how you put them together can make you vulnerable.

For example, if you are encrypting lots of messages that all have the same header, certain crypto algorithms can be made to leak the key.

Do you know which combinations those are? I sure don't by default.

The fact that an end programmer even has to think about this is the problem.

In any cryptosystem, the application programmer is the person who knows the least about crypto. If he has to make any decision, you can expect he will get it wrong.

Re: Ask HN: Current Crypto Best Practices

#65

Post by platz »

rqebmm wrote: post #46
hueving wrote: post #43

Earlier quoted context omitted.

TBH this doesn't really give you anything about best practices though. It's a bunch of base theory without anything about timing analysis, etc. It's nice to know information but I don't think it makes you a better 'secure' programmer.

This was a complaint I heard from several people I work with who took the course.

To my knowledge there has never been a timing attack documented in the wild on a remote server. They are only practical in offline scenarios with host access

Re: Ask HN: Current Crypto Best Practices

#66

Post by cvwright »

bsder wrote: post #64
mtrpcic wrote: post #61

Earlier quoted context omitted.

Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an u…

> Isn't the attack surface limited to the methods used in the application though? No, because the combination of how you put them together can make you vulnerable. For example, if you are encrypting lots of messages that all have the same header, certain crypto algorithms can be made to leak the key. Do you know which combinations those are? I sure don't by default. The fact that an end programmer even has to think a…

Good points. I was about to say something about how libsodium will take care of most of that for you.

For example, I thought they provided some facility for avoiding nonce reuse vulnerabilities by automatically generating pseudorandom nonces for the user.

But then I double checked their API docs and they don't do this at all! Argh!

Re: Ask HN: Current Crypto Best Practices

#67

Post by hueving »

platz wrote: post #65
rqebmm wrote: post #46

Earlier quoted context omitted.

This was a complaint I heard from several people I work with who took the course.

To my knowledge there has never been a timing attack documented in the wild on a remote server. They are only practical in offline scenarios with host access

Depends on what you mean by timing attack.

The only vulnerability of Tor, which heavily depends on cryptography, is timing analysis.

One of the most important lessons of cryptography is that it doesn't exist in a vacuum. Timing between messages and message sizes can be enough to end you.

Re: Ask HN: Current Crypto Best Practices

#68

Post by platz »

hueving wrote: post #67
platz wrote: post #65

Earlier quoted context omitted.

To my knowledge there has never been a timing attack documented in the wild on a remote server. They are only practical in offline scenarios with host access

Depends on what you mean by timing attack. The only vulnerability of Tor, which heavily depends on cryptography, is timing analysis. One of the most important lessons of cryptography is that it doesn't exist in a vacuum. Timing between messages and message sizes can be enough to end you.

I guess "timing analysis" means something else, more akin to correlation of meta-data. https://en.wikipedia.org/wiki/Timing_attack is pretty clear, so maybe I was referring to something else than the OP.

Re: Ask HN: Current Crypto Best Practices

#70

Post by cvwright »

platz wrote: post #65
rqebmm wrote: post #46

Earlier quoted context omitted.

This was a complaint I heard from several people I work with who took the course.

To my knowledge there has never been a timing attack documented in the wild on a remote server. They are only practical in offline scenarios with host access

Funny you should mention this in a thread about Dan Boneh's crypto class.

David Brumley and Dan Boneh, "Remote Timing Attacks Are Practical." In Proc. USENIX Security Symposium, 2003. https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Abstract

Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from an OpenSSL-based web server running on a machine in the local network. Our results demonstrate that timing attacks against network servers are practical and therefore all security systems should defend against them.

Post reply on HN