Bsrgvty

I came across the cryptography python package, and noticed it had the following about reporting security vulnerabilities:

Examples of things we wouldn’t consider security issues:
Using a variable time comparison somewhere, if it’s not possible to articulate any particular program in which this would result in problematic information disclosure.

I thought having no variable time comparisons was one of the things cryptography implementations ensured to be secure. Should this be a goal of all secure cryptography libraries? If not, under what conditions does it not make a difference to security whether or not a constant time comparison is used?

No, they are not always a risk, and indeed, it is impossible to build a practical cryptographic library where every function is constant time.

Take, for instance, a decryption function. In a real-world cryptographic library, it is going to be faster to decrypt a 10 byte message than a 10 gigabyte message. You could theoretically create a library where decryption was constant time for any message of supported size, but that would be absurd, so you have a variable time function that leaks (useless) information about the size of the message being decrypted. One of the specific reasons that this isn't an issue is the assumption that the attacker may have information about the message size is built into the security proofs. Security properties are generally designed to only assume security for messages of a specific size, and since they don't apply to messages of different sizes, there is no impact to the designed security of a system if message size affects function completion timing.

In other cases, timing may be potentially sensitive, but a function may be designed to eliminate any information an attacker could use against the function. Double-MAC'ing is one example of this. Evaluation of a MAC is very definitely a function that is sensitive to timing attacks. In an (for example) encrypt then MAC scheme, you compare a MAC sent with a ciphertext with a MAC freshly computed against the ciphertext, a timing attack could allow an adversary to repeated submit modified ciphertext/MAC combinations and iteratively compute a valid MAC without knowing the correct secret key. If, however, on every comparison you re-MAC the MAC with an ephemeral key and re-compare, it doesn't matter if there are timing issues. The ephemeral key in the second MAC will prevent an adversary from being able to iteratively produce a correct MAC because the new ephemeral key produced for each subsequent evaluation will thwart the effort to discover valid bits.

Variable time comparisons will leak information. If there is no harm in revealing the data being compared, then there is no issue with using variable time comparisons. If it is crucial that it remain secret, then use constant time comparison.

Some variable time comparisons that are exploitable in theory might be hard to exploit in practice. The quality of timing data that a hacker is able to collect might not be good enough for a timing attack to succeed in certain real world contexts.

For example, a timing attack is more difficult if the software processing secret information is running on hardware that already has inconsistent, unpredictable run times (for identical inputs); even if someone has access to nanosecond precise timing data.

If the secret information also isn't that sensitive and has a short lifespan, then the risk associated with such a timing attack might be too small to worry about.

However, there are ways to work around noisy timing data. Maybe a hacker uses other side channels to supplement timing data. Maybe he sends your server specific requests that makes timing more predictable. And of course he can perform the attack many times and sort of average out the noise.

(As a developer, if you're not sure, then use constant time operations. Don't just assume it's too hard to exploit.)

Things that definitely should not be compared using a variable time algorithm:

• Secret (symmetric) keys or private (asymmetric) keys


• Message authentication tags


• Messages (or hashes of messages) containing secrets


• Hard-coded (or user configurable) secrets

Examples for which it may or may not matter:

• Public keys


• Ciphertext


• Public IP addresses


• Public identifiers (excluding personally identifiable information)

Remember that compromising user privacy can be a security issue. (Even if you don't personally think you need to keep some kinds of information private.) Therefore developers should still consider side channel attacks, even when working with data you might not think is that sensitive.

First, cryptography is a broad term and the Python cryptography library does not only include primitives but also X.509 handling etc.

The main question is if the timing issues can be used by an attacker to get secrets or reduce the complexity of the problem and thus the time to get secrets to a value which makes attacks realistic. This means for one that the attacker can measure the time with sufficient granularity in the first place. This is for example usually not the case with complex web applications where variations in network latency and execution time of SQL queries etc will likely make small timing differences in the cryptographic operations impossible to measure from remote. Note that early use of cryptography as in the TLS handshake still might be affected since in this early stage all the other overhead and variations in the application have not much affect yet.

It also means that the attacker can run enough experiments in order to finally extract the secrets. The details depends on how much information is actually leaked from the timing differences but it often practically unfeasible.

And then there might simply be less complex attacks possible. If it is a local application it might be cheaper to just reverse engineer it instead of treating it mostly as a black box. Of course if the application is for example included in some tamper resistant enclosure (like with smartcards) then timing attacks or other side channels (like radiation, variations in used power, ...) might actually be the only way.

In summary: resistance against timing attacks is relevant if a) the timing difference can be measured with sufficient granularity and b) enough experiments can be done and c) no obviously cheaper attacks are possible. Given that especially a) and b) depend a lot on the actual use case it is more important that the cryptographic primitives are resistant, since they might be used in a broad variety of use cases.

The primary purpose of avoiding variable time comparison was to prevent unintended information disclosure leading to timing based attacks on the application.

For example, take a look at Padding Oracle attack and Time based Blind SQL Injection attack. Clearing up all the variable time comparisons in the program comes at a certain cost which the cryptography python package is trying to avoid since they don't see any information disclosure due to those cases.

It is easy to miss such use cases for security relevant code, so I'd prefer to avoid variable time comparisons.

The important thing about leaked information, is to identify what information is leaked, given a certain set of circumstances, and what the attacker would know, and/or control.

For example, lets take password checking. Old, plaintext passwords in the bad old days were often compared one character at a time, by a library with no thought about security. This means that if you got the first letter of the password right, it would take slightly longer than if you got the first letter wrong (since it would take the time to check the second letter). You could try every possible first letter, until you hit the right one, then that first letter plus every possible second letter, and so forth. This way, you could reduce the work needed from 64^6 to 64*6 (assuming 6 symbols from a set of 64 possible symbols).

Even if you hash the password before checking it, you could apply the same to precalculated rainbow tables - find a password with a hash starting with byte 00, if that takes longer to check than a password starting with 01, then you can eliminate all passwords with a hash not starting with 01.

In the example of encryption, if the message being decrypted is supplied by the attacker, then they know how big it is. If it takes twice as long to read a message twice as long, they don't learn anything new from that.

If, on the other hand, it takes longer to decrypt a message if the KEY is different, then the time it took to decrypt a message gives you information about the key, information not otherwise known by the attacker.