# Tag Info

6

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...

3

Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ...

2

For a given prime $p$, there are many choices for the generator $g$, but $g$ cannot be completely arbitrary. As the name hints, $g$ is supposed to be a generator of the multiplicative group $(\mathbb{Z}/p\mathbb{Z})^*$, that is, it must have the property that the set of its powers modulo $p$ $\{g^1 \bmod p, g^2 \bmod p, g^3 \bmod p, \ldots, g^{p-1} \bmod ... 2 XTS has been designed for disk encryption, where an attacker typically has access to the disk only a single time (when they steal/confiscate the device). When an attacker sees several ciphertexts encrypted using the same key, they can tell which blocks differ between the versions, but not the content of the blocks. Compare this with CTR mode, which leaks ... 1 Knowing the message$m_j$should not help you to get$r_j$. In-fact, ElGamal is assumed to be CPA secure (assuming that DDH is hard). Meaning that even if we choose two different plaintexts and give them to alice and she is encrypting only one of them, we won't be able to know which one she encrypted. You can easily show that if you could retrieve$r_j\$ ...

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