51
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 ...
32
In comparison to CBC mode and HMAC, GCM mode is quite a commonly better alternative. But, I'll go to detail where it necessarily is not. Just like Richie Frame, I also do not agree that CBC + HMAC is always the best comparison target. I've added a few other details. Hope you find them useful.
Against CBC and HMAC
I'll discuss downsides first.
The ...
32
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 ...
28
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 ...
25
How to confirm my implementation is constant time? I'm in scala using bouncy castle from Java.
This code is not constant time, for no platform is specified. Computing platforms that run in constant time or cycles are the exception. I don't know any device with internet and video currently for sale that does. That's actually contributing to make attacks ...
23
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 ...
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 ...
20
This is an attempt to an Explain to 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". At 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 ...
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 ...
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
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).
(even,odd) means $N/4\le P<N/2$.
(odd,even) means $N/2\le P<3N/4$
(odd,odd) means $3/4N\le P<N$.
If you continue with ...
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 ...
14
Yes, you can; you can use Batcher's Merge Exchange algorithm, paired with a constant time/access compare-and-swap routine (which reads two elements from locations A and B, and writes the larger element into location A and the smaller element into location B).
This takes $O(n (\log n)^2)$ time, which makes it not quite as fast as other sort algorithms; ...
13
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
Blinding protects against some side-channel attacks in RSA: those that target variations in the 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 ...
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 ...
10
Physically speaking, the crucial quantity is the signal to noise ratio: if a little bit of signal comes out on a given channel but also a whole lot of random noise, and you have no a-priori way of telling them apart, then extraction of the secret becomes exponentially inefficient.
Actually, it becomes quadratically inefficient.
For example, if you have a ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
