Hot answers tagged

13

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/...


7

A common method for constant-time comparison goes $r←0$ for each bit/byte/word $x_i$ and $y_i$ to compare $r←r ∨ (x_i⊕y_i)$   where $∨$ stands for bitwise OR and $⊕$ stands for bitwise XOR all the $x_i$ match the corresponding $y_i$ if and only if $r$ is now $0$ The point is that the duration is independent of the data compared, thus measuring ...


6

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 ...


6

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 ...


4

The classic one that I can think of off the top of my head, that also happened relatively recently and posed a pretty widespread threat, was the Heartbleed bug. It was a big security vulnerability that would reveal authentication info in one of the most common ways communication gets encrypted over the internet, SSL/TLS. Most computers were affected, if I ...


4

You can (and should) do the reduction in constant time using masking. That is, instead of using the following (non-bitsliced) pseudo-C code to do the reduction: if ((result >> 8) & 1) { /* bit 8 is set: clear it and flip bits 0, 1, 3 and 4 */ result ^= 0x11b; } you can simply do: result ^= 0x11b * ((result >> 8) & 1); (...


4

Can a variable that is not explicitly computed correlate with the power consumption? Yes, and this can happen in several ways. When you say "not computed explicitly", I assume you mean that the computation is performed on a masked value or share instead. That is, the secret inputs (referred to as the key by the paper you link to) themselves do not ...


3

As far as we know, no: from a mathematical standpoint, exposure of the raw RSA private key operation does not leak the private key, or anything allowing to perform the raw RSA private key operation (such as another private key, or a factorization of the public modulus). We have no proof; but this has been well studied, and any advance in that direction would ...


3

Functions often become timing resistant by not using short circuit evaluation. There is conceivably a small performance price to be paid by not using short circuit evaluation. In reality, this is probably not a bottleneck or serious concern. Edit: It also might be possible that libsodiums function is faster anyways. I would have commented with this, but ...


3

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC. It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it ...


3

Sure you can do. There are many lattice attacks, using your second assumption, to ECDSA (which also applied to DSA). For instance see Smart and Howgrave-Graham and Shparlinski and Nguyen. All the lattice attacks base on finding small solutions (for the ephemeral key $k$ and the private key $a$) to the signing equation $sk-ra\equiv H(m)\pmod q.$ If you have ...


2

Here's a classic timing attack against SSH: http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf As SSH is an encrypted terminal, it would send a packet each time you press a key. As you type your password, for example, you leaked the length of your password and also the timing. This could be used to reconstruct your likely password and make it ...


2

Given some intermediate data $x$ as two shares $x=x_1\oplus x_2$ take some fresh random $r$ to calculate new shares $x_1' = ((x_1\oplus r)\oplus x_2)\oplus(n\oplus r)$ [parenthesis indicating the order of evaluation] and $x_2' = n$. Now you can use $x_1'$ ($=x\oplus n$) as input for both tables. The answer to "So how should it be computed?" is not at all. ...


2

The main advantage I have heard is reducing the amount of data the client has to send to the cloud. As said in A Comparison of the Homomorphic Encryption Schemes FV and YASHE: [...] ciphertext expansion (i.e. the ciphertext size divided by the plaintext size) of current FHE schemes is prohibitive (thousands to millions). For example using ...


2

Yes, string algorithms can be vulnerable to timing attacks. A very common example is string comparison. The best performing way to implement it in general is to compare two strings one character (or memory word) at a time and return inequality as soon as they don't match. However, this kind of a routine is vulnerable to timing attacks that can find the (...


2

Two answers to the question: It is about principles and reusability of the cryptographic primitives. Once there are implemented by insecure manner, nothing prevents reusing or misusing the insecure functionality later. TLS validation (during the SSL handshake) involves a secret as well - during the SSL handshake a piece of data is encrypted and sent over ...


2

Yes. A human surely is a physical component of the cryptosystem. Even if we ignore the "physical" aspect, we have implementation of a cryptosystem, other than brute force or theoretical weaknesses in the algorithms. If a key is not secure (ie. in the mind of a human who can be persuaded to divulge it), acquiring this password and bypassing the crypto ...


2

Cryptograph Network Security by William Stallings is pretty decent read I had to read in my crypto class. Each encryption method is different, the way you can test its effectiveness as a encryption method is by what they call avalanche effects , where by changing one bit in decryption it changes a lot of other bits throughout the process. Also I recommend ...


1

Most of side channel attacks are depends on algorithm and implementation. In several cases, power consumption is evidently visible in algorithm. For example in the algorithm for elliptic curve points multiplication, for computing $Q=k\cdot P$ we have following algorithm: Let $k$ be $l$ bit. Q=P for i from l-1 to 0 do Q = 2Q if k_i == 1 then Q = Q+P ...


1

I did not paid attention enough when reading the paper. The figure 2 illustrates the operation: So after the computation of $S'$ and $M$, at the first round, the $\texttt{AddRoundKey}$ step stay the same but in addition, the round key is xored with $n$. So if the block data is $x$, after the first $\texttt{AddRoundKey}$ we get $x \oplus k \oplus N$ (where ...


1

The advantage is: You can be quite confident that, if every other bit of the cryptography code you're working with is securely designed and side-channel resistant, you can rest assured that hex encoding/decoding won't introduce new vulnerabilities if you use libsodium's implementation. And if you throw caution to the wind here, you might be fine. None of ...


1

As you suggest, you can speedup the exponentiation using pre-computed values. However, you will face the following problems: the table with the precomputed values can become rather large, and the table lookup is in general not constant time. An example of how these problems can be addressed can be found in the Ed25519 implementation of Bernstein et al.; ...



Only top voted, non community-wiki answers of a minimum length are eligible