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

ZumoDrive rolls a hard six

daemonology.net

Post reply on HN
Print view View original

61–70 of 74 posts

Re: ZumoDrive rolls a hard six

#61

Post by briansmith »

cperciva wrote: post #51
briansmith wrote: post #42

Earlier quoted context omitted.

Is the content going to be much different than your "Cryptographic right answers" post?: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

My talk is basically an expansion of that blog post.

It would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?

Re: ZumoDrive rolls a hard six

#62

Post by tptacek »

cperciva wrote: post #59
tptacek wrote: post #20

Earlier quoted context omitted.

Recommending that developers implement their own cryptography after watching you talk for an hour is pretty close to professional malpractice. Most professionals --- including many who have done a lot more crypto that you --- would recommend the exact opposite . Here's an easier argument that lands in the same place: if you roll your own crypto, and it breaks, you will look incompetant. Everybody will ask, "why didn'…

Recommending that developers implement their own cryptography after watching you talk for an hour is pretty close to professional malpractice. You should hear my talk before you accuse it of constituting professional malpractice.

I concede this point until May.

Re: ZumoDrive rolls a hard six

#63

Post by cperciva »

briansmith wrote: post #61
cperciva wrote: post #51

Earlier quoted context omitted.

My talk is basically an expansion of that blog post.

It would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?

RSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up".

AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?

Re: ZumoDrive rolls a hard six

#64

Post by tptacek »

cperciva wrote: post #54
tptacek wrote: post #19

If you're going to write an article overtly bashing your competitors, you should do better than picking on them for saying "military-grade cryptography". The fact of the matter is that the only real differentiator between Zumodrive and Tarsnap is the integrity of the code that implements the service. Nobody is going to break TLS in order to get Zumodrive data. Cryptography has exactly one implication for attackers: i…

you should do better than picking on them for saying "military-grade cryptography" Have you read Schneier's "snake oil" post? It's all about "how you can pre-judge products from their advertising claims" -- Schneier's words, not mine. You see a classic snake-oil claim, and you immediately know that they're getting stuff wrong. it's been a long time since someone found an OpenSSL flaw that would move the dials for an…

Have you read anything I've said about Schneier? Sorry, I don't hang on his words quite the same way you seem to be.

You're also taking Schneier out of context. Schneier was talking about genuinely batshit products like VMA and TriStrata, products that claimed to have redefined encryption or to use 4 meg keys. He wasn't talking about people claiming that AES was military grade.

The terrible thing about OpenSSL for an attacker is that everyone has already attacked it. NUL characters broke it. CA's with MD5 broke it. Session resumption broke it. As an attacker, how I wish I had something other than OpenSSL to work with! I could break it with NUL characters! It'll rely on MD5 somewhere!

You wrote your post as a security guy. You have a conflict of interest. I think you stepped over the line. You clearly disagree. Let's agree to disagree.

Re: ZumoDrive rolls a hard six

#65

Post by briansmith »

cperciva wrote: post #63
briansmith wrote: post #61

Earlier quoted context omitted.

It would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?

RSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up". AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?

The arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it.

The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet.

Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about.

Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.

Re: ZumoDrive rolls a hard six

#66

Post by cperciva »

tptacek wrote: post #64
cperciva wrote: post #54

Earlier quoted context omitted.

you should do better than picking on them for saying "military-grade cryptography" Have you read Schneier's "snake oil" post? It's all about "how you can pre-judge products from their advertising claims" -- Schneier's words, not mine. You see a classic snake-oil claim, and you immediately know that they're getting stuff wrong. it's been a long time since someone found an OpenSSL flaw that would move the dials for an…

Have you read anything I've said about Schneier? Sorry, I don't hang on his words quite the same way you seem to be. You're also taking Schneier out of context. Schneier was talking about genuinely batshit products like VMA and TriStrata, products that claimed to have redefined encryption or to use 4 meg keys. He wasn't talking about people claiming that AES was military grade. The terrible thing about OpenSSL for an…

He wasn't talking about people claiming that AES was military grade.

Well, no. But only because AES didn't exist yet. Saying "this is secure because it uses 256-bit AES" is just as bogus as saying "this car will be fast because it has a powerful engine" -- and the CNSS knows it, which is why NSA-approved cryptography consists of "an approved algorithm; an implementation that has been approved for the protection of classified information in a particular environment; and a supporting key management infrastructure"... not just the algorithm itself.

I'm having trouble understanding how someone who wrote "if you're typing the letters A-E-S into your code, you're doing it wrong" fails to grasp the bogosity inherent in "using AES makes this military grade". I thought you'd be cheering me on at this point.

Re: ZumoDrive rolls a hard six

#67

Post by cperciva »

briansmith wrote: post #65
cperciva wrote: post #63

Earlier quoted context omitted.

RSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up". AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?

The arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it. The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can im…

There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself.

The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SHA256 or evaluate-a-polynomial-over-a-finite-field-then-AES-encrypt. The latter is possible to do in constant time, but takes some work; the former is almost impossible to do not in constant time. As for performance, I haven't done any tests, but just given the bit-complexity of finite field multiplication, I'm sure HMAC-SHA256 is much faster.

For the record, I would never recommend AES-CBC-SHA. That's an absolutely horrible construction which nobody should ever use.

Re: ZumoDrive rolls a hard six

#68

Post by briansmith »

cperciva wrote: post #67
briansmith wrote: post #65

Earlier quoted context omitted.

The arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it. The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can im…

There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself. The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SH…

Well, mobile phones are a huge market for this stuff right now. I've found that regular DHE adds latency perceivable by the end user in my mobile apps, because they have to wait for the (fast but heavily-loaded) server to calculate the modular exponentiation, and then they have to wait for their slow phone's processor to calculate the modular exponentiation.

When I said AES-CBC-SHA, I meant AES-CBC-HMAC-SHA. The TLS ciphersuites are named without explicitly saying "HMAC"; e.g. TLS_RSA_WITH_AES_128_CBC_SHA is RSA key exchange with AES-128 in CBC mode as the bulk cipher, authenticated with HMAC-SHA1.

The practical problem that people will have with your advice is that they will want to implement it using TLS (despite your recommendation not to use SSL), and TLS doesn't have any standard AES-CTR-[HMAC-]SHA256 cipher suites; there's only standards for AES-CBC-[HMAC-]SHA, AES-GCM, and AES-CCM.

Re: ZumoDrive rolls a hard six

#69

Post by cperciva »

briansmith wrote: post #68
cperciva wrote: post #67

Earlier quoted context omitted.

There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself. The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SH…

Well, mobile phones are a huge market for this stuff right now. I've found that regular DHE adds latency perceivable by the end user in my mobile apps, because they have to wait for the (fast but heavily-loaded) server to calculate the modular exponentiation, and then they have to wait for their slow phone's processor to calculate the modular exponentiation. When I said AES-CBC-SHA, I meant AES-CBC-HMAC-SHA. The TLS…

Yes, I assumed you meant AES-CBC-HMAC-SHA. But CBC mode is horrible, and nobody should use SHA any more.

And I agree that out of AES-CBC-SHA, AES-GCM, and AES-CCM, the best choice is AES-GCM. But my advice was primarily directed towards people not using TLS.

Re: ZumoDrive rolls a hard six

#70

Post by shabda »

> So as you can see, the Cylons have many hurdles to overcome in order to take over ZumoDrive and your data.

Isnt that essentially wrong? The cycolns have to overcome exactly ONE hurdle to steal the data. (Not a security guy by any strech of definition.)

Post reply on HN