ectoplasm

Let's say you want as much money as you can get. This is probably not rational. Now let's say you have a choice of being given $5 or $10, which do you choose? Why was that not a rational choice? Because it's predicated on an irrational desire?

Which RFC 4122 are you not talking about, the one that came first or the one that came before?

Sorry, I'm kind of confused here. Why is the approach I'm defending considered random and not based on data? Is the generation of random hypotheses in general considered unscientific? What about fuzz testing or pharmaceutical R&D? What is the precise difference between hypotheses and assumptions in the context of the scientific method? What is the difference between the presence of a small portion of code being responsible and the code being more broadly responsible? Why the emphasis on presence?

> it seems that Vancouver has very sound fundamentals to sustain the higher prices.

Have you seen the pictures?

http://www.crackshackormansion.com/

Fundamentally I believe non-consensual violence is the result of suffering. I think isolating violent people and protecting yourself is much better than meting out arbitrary punishments. Consider that someone willing to punch a nurse in the chest over a turkey sandwich very likely has some kind of mental health issues. If the assault is actually a problem on the level of a crime, then call the police.

Wait a minute. First of all, the data is simply "there is a reproducible bug in the program". The real hypothesis is that a small, localized portion of the code is responsible for the defect. To find it, you can try binary search. If you have a better idea of the location, then by all means.

Second, when you have a bug and you write a unit test, you are effectively commenting out the entire codebase except for the function under test. When you have a compiler error, whether it's a syntax/semantics bug in your code or a bug in the compiler, sometimes you need to produce a minimal example, so you have to cut cut cut until the bug is just barely provoked. When you have a pipeline of data transforms, and the end result is suddenly borked, it can work to chop off half the transforms and look at the result. When latex is crashing for some unintelligible reason, just comment out half of your document and see if the problem goes away.

Sure it's really dumb if you're just excluding a* .c through m* .c (spaces due to HN formatting rules), but figuring out if the problem is in the first or second half of main is not outrageous. I don't think the guy was presenting it as the first step ("If you have no idea where your bug lives"), but I do agree that it comes across as a little naive, since he should have talked about all of the other techniques available first. So the problem isn't so much the lack of a hypothesis, but the inefficient experimental approach of using a brute force technique indiscriminately.

I think the last resort is reached a little sooner for some types of bugs and some experience levels (language, environment, codebase, programming), and yes in many cases it won't even do anything for you.

Personally I always liked dtrace. This guy gave a demo of it at my university once, I thought it was great, one of the best talks I've seen.

> And frankly, I think that sometimes, it should be okay for healthcare workers to interact with a patient like they are an asshole because THEY ARE.

Irritability is a part of suffering.

Binary search is not random permutation. The hypothesis is "problem lies in this half of the codebase". Hey, if your test passes after commenting out some stuff, great.

Out of thousands of rides, 90% of the time I get an immigrant cab driver. I find they're perfectly capable.

Look for a decrease in resubmissions, per this comment above:

https://news.ycombinator.com/item?id=10012199

I just use the comments page to find interesting discussions.

Another concern is a lower per capita federal tax base.

To me this sounds like admin trying to save money. I found some more discussion in a couple places:

http://blog.sethroberts.net/2014/02/17/cheating-at-caltech/

https://www.quora.com/Are-all-exams-at-Caltech-take-home-exa...

This stuff is so interesting. D.J. Bernstein is certainly prolific! It's cool how processor-specific that cache-based attack is. It's weird, I have a compilers background but (evidently) I've never even thought about timing attacks. There isn't a lot of overlap between the PL and crypto communities I guess. I know we used to use asm volatile with gcc but apparently that isn't even a guaranteed scheduling barrier anymore.

Anyway, my curiosity is satisfied for now, but thanks again for sharing, and keep posting about this stuff.

I think people want three things: 1) good; 2) different; 3) similar. If your work is good, all that matters is finding the right audience for it. People want things that are different from your past work and the cultural status quo, but they also want similarity, a connection. There are many artists who substantially change their output while remaining popular, but there are many who screw it up too.

Hey this is pretty interesting. Thanks for taking the time to explain. My first reaction was that you have to know the hash function for this attack to work, but I guess the salt serves the same purpose as hiding the hash function, and is more practical since then you can use a generic hash. Presumably someone figured out a way to prevent timing attacks against your own account - what is it?

Sure, assume that the hash takes data-dependent time, but that's the only vulnerability. I can see that this might reveal password length, but not easily beyond that. How does it work? Does SHA256 with salt take constant time?

In general, what is the most secure password scheme if you're looking to prevent timing attacks? Do you need real-time guarantees? You have enough material for a nice "evolution of secure password authentication" article here, if you ever wanted to write it up.

Ok, fine, so there are no real-time, optimization, or scheduling guarantees in C / C++ and it's better to be safe than sorry. But why does it actually matter if either the hash function or hash value comparison takes data-dependent time? How can you use that information to recover the password?

There is a binary test for a programmer: someone with basic proficiency in a Turing-complete language. I like this answer on SO about what that is:

https://programmers.stackexchange.com/questions/132385/what-...

> In general, for an imperative language to be Turing-complete, it needs:

1. A form of conditional repetition or conditional jump (e.g., while, if+goto)

2. A way to read and write some form of storage (e.g., variables, tape)

For a lambda-calculus–based functional language to be TC, it needs:

1. The ability to abstract functions over arguments (e.g., lambda abstraction, quotation)

2. The ability to apply functions to arguments (e.g., reduction)

--

Note that you can be a programmer without ever having touched a computer, people have been coming up with algorithms and integrating them into systems for ages.

> I’m the PhD who wrote the original article. I’m delighted a high school student worked so hard and wrote so well.

He's certainly not doing himself any favors with this condescending appeal to authority. In general, the exchange between Jensen and Fried is a perfect example of how to handle a nasty person with grace.

Often you can even take the same dress and dress it up to accompany someone in a suit or dress it down to accompany someone in jeans and a t-shirt.

Wow, maybe I have a future in cryptography!

Anyway, why exactly isn't the hash function constant-time? I don't understand this, the hashes I've played with for hashtables are just a bunch of bit shifts. Is it only message length?

Oh, I don't live in NYC, but we have rent stabilization here and the landlord is allowed to increase the rent by a percentage of the current rent plus a percentage of the amount spent on repairs and renovations. If NYC doesn't compensate landlords for repairs, which in turn means they don't want to do them, I agree that is horrible.

Why is rent stabilization bad? All it does is stop the rent from going up too much while you are living there. I wouldn't want to be a tenant without it - who wants to be forced to move because the rent went up by too much? As soon as you leave, the landlord can sign a new lease at whatever rent they like. That is distinct from "rent control" in NYC, which caps rents and is a much stronger measure, but only applies to tenants living in the same place since July 1st 1971, or March 31 1953 if it's an apartment in a 1 or 2 family home.

https://en.wikipedia.org/wiki/Rent_control_in_New_York

You're right, there's a hard limit on password length. That might be fatal if you're using diceware, I don't know if you could accommodate passwords that big. As for the set of strings, just assume it's every string possible, so 256^8 strings for an 8 byte password. That's only 16384 petabytes.

All of the perfect hash functions I've found require knowing all of the keys ahead of time. You might not be able to fit 16384 PB on your hard drive or in memory. (Hey, I don't know. You could work at LLNL.) But I think that if you knew you might use any key in the space, and you didn't insist on a minimal perfect hash, i.e. one where there is a 1:1 mapping from hashes back to keys, that you could write such a function without having all of the keys.

If you did this, you'd also need to prove you were generating a unique and effectively random hash. If I was a crypto academic, that might be an interesting line of research. I'd be kind of surprised if nobody ever tried this though, and there's probably a decent amount of literature to pore over. I guess most people use perfect hashes for hashtables and not as a defense against timing attacks.

Why do you think YC finances HN?

Also, it's quite possible to watch TV shows for free without advertisements.

And, how do you get around product placement?

A perfect hash is a function in the mathematical sense in that there is a unique output for each input. So, hash the stored password ahead of time, and hash the challenge password after receiving it, and then compare the two hashes. You don't need collision detection, since a match can only come from two identical keys. You don't generate passwords for people, although you could, as long as you don't reveal your hash function. There are useless perfect hashes, like "password + 1", and there are much better ones that produce near-random output.

"Bait and switch"?

What happens if nobody yells their guesses and people only talk to one other person at a time? That's more like what happens with real estate agents.

Ah, mastermind. I think you mean the ones that take more time on average contain a letter from the password, not less. Anyway, good point.

I was thinking you could maintain an array of flags to indicate whether you've compared a certain position before, and a count of all the compared positions so far.

Alright, here are my other ideas:

1) Properly chosen 8-character passwords are pretty strong, right? So why not copy all of the 8-bit chars into a u64 and compare that directly? You can treat longer passwords as a series of 8-char passwords. Assumes a machine that won't short circuit on u64_a == u64_b. Less effective for 32-bit. The compiler won't undo this since it's an optimization (1x aligned 64-bit compare is more efficient than 8x 8-bit compares, seven of which are unaligned).

2) Introduce a random delay after the byte-wise comparison is done that is up to 10x the length of the comparison. The comparison variance gets lost in delay variance. I know, a mitigation, but it's effective. Combine with random selection of characters for more effectiveness.

3) Use a perfect hash of the password. You don't need to compare keys after a perfect hash.

Thanks for humoring me.

Let's assume you're right. Why can't you choose characters to compare randomly, until you've compared them all?