We compare the hash of passwords, not the passwords.

@kelalaka This seems rather off-topic, as the question was not about secure credential storage, but about side-channel attacks. One side-effect of example code is that it's meant to illustrate a concept, and not being copy/paste ready for production.

Bear SSL ( Thomas Pornin) Constant time page

@kelalaka and when you don't find a user with the given username do you compare a hash of a dummy password (must be pre-hashed) to the given password so that you not leak whether the username exists?

Answer should mention that while side-channel attacks are a big and important thing, they are not the only reason why you shouldn't implement your own crypto.

@Tom you could elaborate with an answer yourself? The other reasons you're alluding to are what the question is asking about.

This is a good answer, but I don't think it's sufficiently complete. For asymmetric cryptography especially, you can have errors that only occur when specific inputs are given, even if your code passes all test vectors. This is a particular problem with ECC (and with upcoming post-quantum algorithms).

the "offending" code was removed at some point was that point an optimizer step during compilation?

As far as I know, it was commented out completely, as it was seen as "unnecessary". Since I couldn't find the exact commit that "broke" OpenSSL, I can't say for sure though

Why do you focus on side channel attacks? (And why do you say in a comment that the question was about side channel attacks?) You do mention other possible errors in your answer text, but in my opinion side channel attacks are the least of your worries concerning a home-grown implementation. There are whole classes of true coding errors which are easier to exploit. Errors which are only caught through extensive testing, review and field exposure, none of which a home coder can provide.

@PeterA.Schneider I personally believe that Side-Channel Attacks, along with Compiler-Optimizations, are the biggest things that a coder can easily miss when writing crypto-code themselves. If I were to write down everything that could go wrong, I could probably write for days and still not be complete. On a side note though, I never expected this question to blow up and receive this much wide-spread attention. Had I known, I would probably have structured my answer differently to be more exhaustive.

"Any input that I try that is longer or shorter than 8 characters will take a tiny bit less time to complete than any other input." It's worse than that. What a caller can do is align each password letter as the last byte of a mapped page of memory and call your function. When he's guessed the right first byte, an access to the second byte page faults and crashes... Caller now knows the first byte of the password and can repeat to guess the second, and so on

@SwissFrank If the first thing my function does is pull the password into an internal buffer for actual processing, then it faults before it even tries to validate the password. And if the validation is based on computing a salted hash of the password for comparison with a stored value, there is no way to know "I got one byte right", because a properly-designed hash function changes an average of half of the bits of the hash when one bit of input changes. (The movie War Games was totally wrong on this.)

Sure, Monty. My comment is in the context of someone naively coding the calculation right but not doing the details you mention.

It's also fine to implement your own crypto if you want to devote the time to become a crypto expert and actually understand the things that go wrong with crypto. It's easier to say, "Just never implement your own crypto" than the more nuanced, "Implementing crypto correctly is hard, and if you implement it yourself you are terribly likely to introduce gaping security holes, but if you want to get the expertise, it can be done!" Also from a financial perspective it's probably a stupid idea to write your own crypto. See: It's hard.

"seeding a PRNG with essentially random data is not bad" not quite; the problem was that either leaving the offending code in or taking it out were both potentially fatal. The code left in would result in undefined behaviour in C, which could result in arbitrary bugs. Obviously naively taking it out also caused a bug. The tools complaining were 100% correct; so too were those complaining about the solution. Crypto code!

@WayneWerner I doubt that the intention of OP was to ask if you could not implement AES on your own as a learning experience. If someone were to ask "Should I implement...?", it's usually because they also want to run that code.

"What if I want to compare the password Bdd3hHzj to the user input? Any input that I try that is longer or shorter than 8 characters will take a tiny bit less time to complete than any other input." - I feel like I'm missing something big here, but why would this be? surely only shorter input will take less time, and longer input will take more time?

@IanKemp In OP's example the code if(this.length != other.length) causes the check to exit early (== complete faster) whenever the strings being compared differ in length at all

so comparing e.g barf to barfed exits early, while comparing barf to bart exits after 4 iterations of the for loop only, in the answerer's example

@IanKemp I assumed that the string-implementation in said system knows the length of the string, thus calculating the length of a string will be O(1) for every input. Therefore comparing the lengths of two strings is also an operation of O(1).

Ergo, if you had many attempts to weed out other processing noise, or very fine timing of how long the function takes to compare, checking a string with the same length as the password would be slower then one with a different length, and every character that matches in both strings would make it slightly slower still

oh duh

thanks guys i'm dumb and it's friday afternoon

@IanKemp Regarding your comment about implementation errors: I specifically avoided an "If you implement Crypto, you'll do it wrong" approach, because many developers will consider this point null and void. "If I have a spec, I can implement it" is what most people will say. And to some degree, they will be right. The reason why I focused so much on side-channel attacks is because crypto code can be up to spec and still be broken.

Also thank you for the suggested edit. I hope that explanation makes things clearer for some.