Hot answers tagged

12

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


7

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


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


5

Often people build hardware that contains cryptographic algorithms, and they are worried about what happens if that hardware falls into the hands of an attacker. Historically, there have been several approaches to making it harder for the attacker, often used in some combination: Hardware and cryptographic algorithms specifically chosen or designed to ...


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

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

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

Good blinding requires good randomness. Randomness is a hard requirement, especially for embedded systems. In a similar vein, the DSA and ECDSA signature algorithms require a strongly random integer (called k) for each signature, and several implementations have failed to use random enough values, with hilarious consequences; the most well-known case is Sony ...


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


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

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


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

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


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