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

Everything you need to know about cryptography in 1 hour (2010) [pdf]

daemonology.net

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#91

Post by aianus »

Nimi wrote: post #88
aianus wrote: post #87

Earlier quoted context omitted.

SSL usually terminates at the load balancer. A quick googling found this guide to setting up SSL on ELB: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...

Yes, but what happens to the client authentication when it migrates between servers? Do I write a cookie to the client saying "authenticated as user X"? Encrypt the cookie? Sign the cookie? It sounds one would need to write cryptographic code to do that...

You write a cookie to the client containing some random key and associate that key to the user on your backend in the shared db. Since it's just random data, you don't need to sign or encrypt the cookie and SSL takes care of protecting it in transport.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#92

Post by Nimi »

aianus wrote: post #91
Nimi wrote: post #88

Earlier quoted context omitted.

Yes, but what happens to the client authentication when it migrates between servers? Do I write a cookie to the client saying "authenticated as user X"? Encrypt the cookie? Sign the cookie? It sounds one would need to write cryptographic code to do that...

You write a cookie to the client containing some random key and associate that key to the user on your backend in the shared db. Since it's just random data, you don't need to sign or encrypt the cookie and SSL takes care of protecting it in transport.

Does this random value need to be unpredictable?

And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can't. Now, it seems likely you and I can hash out the details of an acceptable solution in this discussion (in fact, I think once you take the steps to make sure the random source isn't predictable, you're good, but even this is slightly crypto-related), but how would the average developer know this? How would he go from "don't write crypto code" to this? In my humble opinion, simply saying "don't write crypto code" isn't a solution, and there are good reasons why this hasn't worked so far.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#93

Post by aianus »

Nimi wrote: post #92
aianus wrote: post #91

Earlier quoted context omitted.

You write a cookie to the client containing some random key and associate that key to the user on your backend in the shared db. Since it's just random data, you don't need to sign or encrypt the cookie and SSL takes care of protecting it in transport.

Does this random value need to be unpredictable? And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can…

Yes, it needs to be as unpredictable as possible.

Usually this sort of code is already present and well tested in whatever web framework you're using and there's just no good reason to write it again yourself. Best case is you wasted your time, worst case it's buggy and insecure.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#94

Post by NAFV_P »

bazzargh wrote: post #89
NAFV_P wrote: post #69

Disclaimed: I know sweet f-a about cryptography, and was expecting 100% of this pdf to go straight over my head. On the other hand, why is the author using "i++" in a preamble of a for loop?

That's the style in C-like languages. http://en.wikipedia.org/wiki/For_loop#C.2FC.2B.2B ... also used in Java, Javascript, Perl, Php, Bash (and many more I'm sure).

> That's the style in C-like languages.

That style is in many cases inefficient.

  /* summation of successive integers */
  /* don't worry, this should not cause overflow in a 32-bit signed integer type */
  volatile int i=0;
  int j=0;
  for( ; i
Being declared as volatile, the compiler will not attempt to optimise the for loop and change the code that increments i in the preamble from postfix to prefix. I will admit this is an extreme example, but I often see examples on the internet of simple for loops written in this manner when prefix is more suitable and simpler for the cpu to execute. Postfix increments of integer types involve making a local copy (y) of the variable to increment (x), then incrementing x and returning y. Prefix increments merely involve incrementing x. The former method is rather expensive.

On the other hand, it would make sense to use postfix on something like [0].

[0] http://en.wikipedia.org/wiki/Duff's_device#Original_version

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#95

Post by archwisp »

tptacek wrote: post #82
cperciva wrote: post #67

Earlier quoted context omitted.

I was skipping the details because Thomas and I have had this argument here at least a dozen times, and I figured that people were getting sick of it by now. To summarize the arguments: Both CTR+HMAC and combined AEAD modes, correctly implemented and correctly used, will keep you safe against existing published attacks. Thomas takes the view that "correctly implemented and correctly used" is a problem, and I'll accep…

I love your summary about cat-sharing startups vs. C code for internet-facing daemons, but the cat-sharing people can't usually afford our rates for crypto work; most of my experience comes from code built by people with lots of experience. Also, if you asked me who was more likely to get crypto right, the Django web guy or the C daemon guy, I'd bet on the Django guy every time . Betting against crypto implemented in…

First off, do not interpret my comments as trying to provide any sort of advice to anyone. I am merely expressing frustration.

I have to agree with Colin's [1] point.

The standard libraries for the languages I see in assessments most often just don't include AEAD constructions. And when public libraries exist, they haven't been properly assessed.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#96

Post by KMag »

M4v3R wrote: post #60
cperciva wrote: post #8

The reason this is being (re)posted now is that I gave this talk at a Polyglot Vancouver meetup last night. Freed from the constraint of a conference schedule I actually took about 90 minutes to go through this talk this time (followed by another 30 minutes of questions).

Hey, I found a small typo in the presentation. On page 80, in "good" code sample, you can see: x |= MAC_computed[i] − MAC_computed[i]; It probably should be something like: x |= MAC_computed[i] − MAC_received[i];

Or better yet

    x |= MAC_computed[i] ^ MAC_received[i];
If they're not careful and the numeric type being subtracted is wider than CPU registers, depending on architecture, the compiler-generated carry code to implement wider-than-register subtraction may introduce timing attacks. Wider-than-register xor is much much less likely to have such issues.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#97

Post by pbsd »

NAFV_P wrote: post #94
bazzargh wrote: post #89

Earlier quoted context omitted.

That's the style in C-like languages. http://en.wikipedia.org/wiki/For_loop#C.2FC.2B.2B ... also used in Java, Javascript, Perl, Php, Bash (and many more I'm sure).

> That's the style in C-like languages. That style is in many cases inefficient. /* summation of successive integers */ /* don't worry, this should not cause overflow in a 32-bit signed integer type */ volatile int i=0; int j=0; for( ; i Being declared as volatile, the compiler will not attempt to optimise the for loop and change the code that increments i in the preamble from postfix to prefix. I will admit this is…

Have you actually tried your example? Even at -O0, it results in the exact same code: http://goo.gl/kDEFnU

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#98

Post by Robin_Message »

graycat wrote: post #84
DanBC wrote: post #81

Earlier quoted context omitted.

You know that this is a presentation, right? And that the symbols will be defined in the talk? There are better ways to ask someone to define their symbols.

It's simple: Instead of just n , write "For a positive integer n ". Instead of just k , write "For a key k ". It's simple. Look, guys, 'n' just does not abbreviate 'integer', and 'k' does not abbreviate 'key'. Yes, yes, yes, I know; I know; and we should all know, that while too often people write, say, O(ln(n)) saying nothing about either 'n' or 'O', it's darned bad mathematical writing. If in some context n is a po…

It's simple: it's a slide, so it should never, ever have excess verbiage on it. Otherwise, you don't know how to use simple English properly. Good authors never say more than necessary. I wouldn't trust someone who's presentation skills were so bad they wrote "n (a natural number)" when it was blinding obvious from the context.

And remember, dogma is always wrong.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#99

Post by tptacek »

archwisp wrote: post #95
tptacek wrote: post #82

Earlier quoted context omitted.

I love your summary about cat-sharing startups vs. C code for internet-facing daemons, but the cat-sharing people can't usually afford our rates for crypto work; most of my experience comes from code built by people with lots of experience. Also, if you asked me who was more likely to get crypto right, the Django web guy or the C daemon guy, I'd bet on the Django guy every time . Betting against crypto implemented in…

First off, do not interpret my comments as trying to provide any sort of advice to anyone. I am merely expressing frustration. I have to agree with Colin's [1] point. The standard libraries for the languages I see in assessments most often just don't include AEAD constructions. And when public libraries exist, they haven't been properly assessed.

Can you be more specific? Because this assertion didn't ring true to me based on my own experience, and less than 5 minutes of Googling appears to refute it:

* OpenSSL supports AEAD through CCM and GCM (and OpenSSL's GCM uses PCLMUL and shouldn't have the obvious cache leak)

* Botan supports AEAD through OCB, GCM, CCM, EAX, and SIV(!).

* Java JCE with the Bouncycastle provider (extremely popular) does AEAD with GCM, CCM, and OCB

* .NET stack languages get AEAD through CCM or GCM.

* Crypto++ supports AEAD with GCM, CCM, and EAX.

* Golang supports AEAD through GCM in the standard library (I did implement a crappy OCB myself, but the go.crypto package probably has a better one).

What bases aren't covered here? Bear in mind that most languages get their crypto through bindings to OpenSSL.

Re: Everything you need to know about cryptography in 1 hour (2010) [pdf]

#100

Post by graycat »

Robin_Message wrote: post #98
graycat wrote: post #84

Earlier quoted context omitted.

It's simple: Instead of just n , write "For a positive integer n ". Instead of just k , write "For a key k ". It's simple. Look, guys, 'n' just does not abbreviate 'integer', and 'k' does not abbreviate 'key'. Yes, yes, yes, I know; I know; and we should all know, that while too often people write, say, O(ln(n)) saying nothing about either 'n' or 'O', it's darned bad mathematical writing. If in some context n is a po…

It's simple: it's a slide, so it should never, ever have excess verbiage on it. Otherwise, you don't know how to use simple English properly. Good authors never say more than necessary. I wouldn't trust someone who's presentation skills were so bad they wrote "n (a natural number)" when it was blinding obvious from the context. And remember, dogma is always wrong.

It's not "blindingly obvious": Or, for one, for some, or for all?

And there are many more symbols undefined than just n; just read the document. E.g., there is k. Now what is k? "Blindingly obvious"? Nope.

The author actually did say a little about his x; not saying what k was was poor mathematical writing in any sense.

And there were many more symbols.

I'm talking about rock solidly, standard good mathematical writing and not "dogma".

You are refusing to acknowledge or learn a simple and elementary but important lesson in mathematical writing, and your excuses are not serious responses. You are just angry and fighting. As much as it irritates you, I'm fully correct, and my remarks are fully appropriate.

Yes, computer science and practical computing have a lot of difficulty in such writing lessons; as fields, in writing, computer science and practical computing have quality way, way below that of, say, math or physics although the document of the OP is not nearly the worst example. For the worst example, the competition is severe.

For your

"And remember, dogma is always wrong." sounds pretty dogmatic.

Your response deliberately attempts to be insulting, is not really responsive to anything I submitted, and is not serious, constructive, or appropriate, and I will not respond to you further.

Post reply on HN