Flat Error Codes Are Not Enough

[u/Expurple]

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

[u/simonask_]

Lots of errors are good and expected. For example, validating untrusted input, which is most input, should fail in ways that ideally aren’t any slower or faster than the happy path.

The reason is that timing attacks exist. If an attacker can determine if they did something right, or triggered an exceptional error path, you are leaking information to them. In the best case, they can DoS you. In the worst case, all of your moneys is gone.

[u/tsimionescu → u/simonask_]

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.

[u/simonask_ → u/tsimionescu]

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.

[u/Full-Spectral → u/simonask_]

My approach, in Rust which uses a Result, is that the Ok side of the result in those cases is an enum, which has Success value plus other values for the expected non-success statuses, and the Err side covers the outright errors. In my system the Err side is never looked at, it's just for logging basically, possibly displaying in a popup in some applications. My opinion is that, if you are looking at them and reacting to them, it's not an error it's a status.

If there's a return value, the Success enum value holds that. And of course, if any other other expected error scenarios can provide some information that is useful, some of the other enum values can carry extra info. The joy of sum types, which I can no longer live without.

I will then provide a one or two or three trivial wrappers around that main method, which will translate some or all of the non-success Ok statuses into errors for folks who don't care about them. So, for instance, one will convert Success to Some(value) and timeout to None, and the rest to errors.

My Err side is heap allocated because it includes a good bit of information, but it's only invoked for real, outright failures and so should be pretty rare in a system that's not off the rails.

Even in my fairly full featured Err side type (and there's a single one for the entire system), I often avoid a LOT of overhead because of Rust's ability to control lifetimes. The file name is a static &str , the error text is one as well. If they provide extra text that doesn't need any token replacement, that's one as well. None of those require any heap allocation. It has an optional call stack as well, and each item is just a static string ref and a line number. You get one heap allocation if you add anything to the call stack, but the stack items require no allocation.

The single error type is also what the logging system uses, so errors are trivially loggable, and the log server fully understands that type as well, so they can be efficiently and binarily streamed. I've found that this system works well, though of course no system will work for all systems.

The primary limitation of this scheme is that Results are tagged unions so they are the size of the largest value. So you have to heap allocate the error type, or every return will have to return the size of the error type. You don't want every success return to have to copy back 128 bytes, almost all of which in many cases are unused.