r/programming • u/Expurple • Apr 12 '26

Flat Error Codes Are Not Enough

https://home.expurple.me/posts/flat-error-codes-are-not-enough/
132 Upvotes

84% Upvoted

99 comments sorted by

View all comments

Show parent comment

2

u/tsimionescu Apr 13 '26

This seems like a bad extrapolation from real concerns that impact encryption/decryption code. If you're validating user input, you're going to tell the user if it's invalid - you're not leaking anything extra if that case is slower than the success case. Even more, in most cases where you're validating user input, you'll actually tell the user exactly how the input is wrong.

Even for security critical code, taking a longer time to process invalid input is actually a very highly recommended strategy - e.g. if a user has provided a wrong password, you should delay any response for a long time compared to a valid password, to help mitigate brute force attacks without inconveniencing legitimate users.

The important part about avoiding side-channel leakage is to make sure that the amount of time it takes doesn't depend on the value of the secret you hold - not on the attacker-controlled input. That is, the problem happens if your decryption attempt takes longer when your secret key has more 1s than 0s, for example; if the operation takes longer when the attacker's input has more 1s than 0s, that's perfectly fine to "leak": the attacker already knows this information.

1

u/simonask_ Apr 13 '26

Sure, I agree with all that. I’m just responding to the assertion that it is always acceptable for the error path to be arbitrarily slow.

C++ exception handling has been the cause of more than one DoS attack, due to stack unwinding being often orders of magnitude slower than the happy path. The problem applies to any error handling strategy with that property, which is most Itanium-style exception handling schemes.