48
Here's a very simple timing side channel attack that you might even see in movies. Suppose you're trying to log in to a computer with a password, and the victim compares your password byte by byte but stops early if there's a mismatch:
for (i = 0; i < n; i++)
if (password[i] != input[i])
return EFAIL;
How do you attack this?
Try a password like ...
30
In comparison against CBC mode and HMAC, GCM mode is quite commonly better alternative. But, I'll go to detail where it neccessarily is not. Just like Richie Frame, I also do not agree that CBC + HMAC is always the best comparison target. I've added few other details. Hope you find them useful.
Against CBC and HMAC
I'll discuss downsides first.
The ...
28
Yes, side-channel attacks are practical and a real concern, if the past is indicative of the future.
I've been professionally involved with Smart Cards since the mid eighties, and have repeatedly witnessed deployed systems vulnerable to many forms of side-channel attacks; examples:
RAM buffer not cleared at reset, readable (with standard command Get ...
28
The current Argon2 draft RFC, I think, provides a good, reasonably brief answers to this question. TL;DR: most people will indeed want to use Argon2id and not the "pure" variants.
The introduction summarizes the issues quite well:
Argon2 has one primary variant: Argon2id, and two supplementary variants: Argon2d and Argon2i. Argon2d uses data-depending ...
27
C comparison operators (strictly relational < <= > >= and equality == !=) yield 1 if the condition is satisfied and 0 if not. On some implementations (compilers) depending on the CPU and sometimes options, this may be implemented by code something like:
; int a = ..., b = ...;
; int x = a > b;
move a, r0
compare r0, b ; sometimes subtract ...
22
Yes, AES-NI was specifically designed to be constant-time and thus offers better side-channel protection than (some) software implementations. Note however that these day there exist quite fast side-channel resistant software implementations for AES, which are in-use by the better crypto libraries. AES-NI mainly offers a speed advantage over these ...
22
The theory is: don't try to write timing-safe code in JVM-languages or other essentially-interpreted-but-perhaps-sometime-compiled languages; rather
Use timing-safe libraries called from the comfort of the JVM-language. Typical example: in a JavaCard that passed Common Criteria evaluation to EAL5+ with AVA_VAN.5 augmentation, it is a safe bet that AES (when ...
22
I recently wrote a big page on how big integers are implemented in BearSSL. There are several ways to represent integers in RAM and compute operations on them; also, note that for cryptography, we usually need big modular integers, which is not the same as big plain integers. BearSSL's code is constant-time, thus nominally immune to timing attacks (subject ...
19
The paper explains why. Preventing the OS from interrupting the AES computation is part of Bernstein's proposed method of defense against cache-based timing attacks. Let me sketch the argument for you:
The early part of the paper explains that if the time is variable, then it introduces a risk of timing attacks. Sections 3-6 demonstrate that such an ...
18
Writing constant-time cryptographic code is certainly possible in Java or similar languages (e.g. C#). However you have to do it properly.
"Constant-time" here means that the observable time-related behaviour does not depend upon secret data. It does not mean that execution time is always the same, but only that the variations are not correlated with the ...
18
This is an attempt to an Explain me like I'm five style answer:
Assume you have a bank vault with a mechanical combination lock. Your cipher in this case is "combination lock". On first sight it has two channels that the attacker can see and interface to: The rotation on the input dial (an input channel) and the open/close status of the vault door (an ...
17
The book Cryptography Engineering devotes part of a chapter to this topic. Overwriting sensitive data with zeroes is a good start, but there are lots of other considerations.
If you rely on a language's default object destruction behavior to zero the memory, it's possible for an unexpected error to prematurely halt the program's execution without it ...
16
With regards to timing-based side channels (those that can potentially be exploited remotely, as opposed to, say, power analysis), the AES-NI opcodes are constant-time. See for instance Intel Intrinsics Documentation, that describes the C-like function that can be used to leverage these opcodes: the opcode throughput and latency are fixed, which means "...
16
As already said by fgrieu in his answer, this is possible.
There are multiple ways to protect deterministic ECDSA against fault attacks, but these ways will depend on your fault model.
If you consider only a single fault model, then any construct requiring the attacker to perform two faults to achieve his goal will be an acceptable countermeasure... On the ...
15
I believe that it is for two reasons:
Nontable based implementations of AES are possible, but (assuming you don't have AES-NI or something similar) are significantly slower than table based implementations (perhaps $10\times$ to $20\times$ slower)
For a lot of uses, timing attacks aren't particularly relevant (as either the attacker can't get the start/stop ...
14
If a single bit was known through all states in AES, which would cause the most information to leak?
If you are an attacker and could watch one bit of AES-128 for 10 rounds, which bit would you choose to recover the most useful information? I feel it would be a bit in the key schedule.
Actually, I'd expect a leak of one of the internal state bits would give the attacker more information.
The key schedule is static, and so if you leak 10 bits, well, you ...
12
It mostly has to do with the real world influence of memory caches.
A cache is a small amount of fast memory; when you read from memory, the contents are placed in this fast memory (possibly along with adjacent locations); if you read from the location again, you read it from the fast memory (which, of course, proceeds much faster).
Hence, if you read a ...
11
Here's the next step in the iteration, which should be easy to understand:
Let's call the oracle on 2P and 4P:
Answer (even,even) means, that $P<N/4$ (this is still easy: Otherwise either 2P or 4P would be greater than N).
Answer (even,odd) means $N/4<P<N/2$.
(odd,even) means $N/2<P<3N/4$
and (odd,odd) means $3/4N<P<N$.
Actually, ...
10
A cryptographical algorithm can't be immune or not immune to side channel attacks; this is because a side channel attack attacks the implementation and not the actual algorithm. Any algorithm that uses secret data can be implemented in a way that has side channel attacks, and any algorithm can be implemented in a way that may be resistant (the hard-core ...
10
Obligatory XKCD: coercion (or/and bribery) works. Other usual strategies are
Rigging the particular machine used by the data owner.
Otherwise spying key-presses on that machine to obtain the password.
Password search (including by compromising this user's other passwords and trying variations); that's an industry that has several professional-looking offers,...
10
It basically depends on what you consider side-channel attacks.
If you consider time/cache side channel attacks than chacha20 has been design with resistance to such attacks in mind while AES didn't.
In fact, AES is vulnerable to these kind of attacks (as they were invented after AES was designed). But, hardware implementations, such as AES-NI are ...
10
Yes, ECDSA (including deterministic) can be protected against fault attacks. An idea is to check any computed signature (by the verifier's algorithm) before releasing the signature (and not releasing anything if the verification fails; perhaps, zeroing the key and declaring the device faulty or under attack).
That's a pretty general technique applicable to ...
10
Side channel attacks are variably understood as excluding or including fault attacks. Let's start with the excluding definition, where side channel attacks monitor a device running some security-critical process, without deliberately attempting to alter its normal operation.
The most straightforward and perhaps earliest form of side channel attack is ...
9
The approach with which I solved the problem is indeed as @tylo suggested. Initially we know that the target plaintext $P$ is within the bounds $[0,N]$ where the lower bound $LB=0$ and the upper bound $UB=N$.
Now we iterate the following algorithm $log_{2}N$ times to find P from the original intercepted ciphertext $C$
$C' = (2^{e}\mod N) * C$
if (Oracle(C'...
9
The obvious way of implementing ChaCha20 involves nothing but additions, fixed rotations, and XORs. All of these are constant time, so the obvious way of implementing ChaCha20 is secure against timing attacks. The main way that ChaCha20 is made faster -- SIMD -- does not change this.
On the other hand, the obvious way of implementing AES uses table ...
9
I would like to complete poncho's answer by mentioning a point that has not been discussed here.
On top of being an internal state which directly depends on plaintexts (resp. ciphertexts) and the key if you attack the first round (resp. the last one), making hypothesis on S-box output (resp. input) allows to exploit the non-linearity of this operation. ...
9
Not in the least. Forget it.
This is written from my experience which is with Java, but all JVM languages will have similar insurmountable problems. There are issues with compile time and run time optimisations that make the byte code almost impossible to predict. And the optimisations majorly and subtly change with each major /minor release. You'd have ...
9
Blinding protects against some side channels attacks in RSA: those that target variations in timing or other side channel information as a known function of $C$ (or $C^d\bmod n$ should that end up to be available).
As noted in the question, blinding is pointless against the most basic (Simple) Power Analysis attack, which determines the bits of the private ...
8
Yes, timing attacks are relevant to real-world implementations of crypto. Yes, as that paper demonstrates, these attacks can be carried out in real life: real networks are fast enough to allow these attacks.
It is also important to understand that some network services do provide timestamps that leak information about how long the operation took on the ...
8
At least for compiled languages it should also be possible to have
tools that perform static analysis on machine code, shouldn't it?
Indeed, such tools exist. There are companies specialized in this domain which provide this kind of tools (see this datasheet for example). But you should note that an only software tool will not be able to detect all ...
Only top voted, non community-wiki answers of a minimum length are eligible
