The Stack Overflow podcast is back! Listen to an interview with our new CEO.

# Tag Info

1

Would adding more rounds to AES increase security? Not really. The cheapest known attacks on AES today are essentially generic key searches. That is, they don't really depend on the details of AES itself. If you increased the number of rounds, that would slightly raise the cost of testing each key, but it would also raise the cost of using your AES ...

1

TLDR: from a theoretical standpoint counting the number of block encryptions for known plaintext attack, what's proposed increases security by less than 3 keys bits (or less assuming many messages). From a practical standpoint, what's proposed is pointless, because one layer of AES-256 is more than safe enough against all except attacks targeting the ...

2

The property that you are looking for is the "online" property of a stream cipher. CCM was however developed for packet encryption where the size of the data is known beforehand. So CCM lacks the strict online requirements for an online cipher. However, since the cipher underneath still uses counter mode, the encryption itself can still be performed on each ...

1

No, 128-bit NTRU private key will retain its security when encrypted by AES-256 using a properly generated/derived key. Suppose 2 ciphertexts, 1 NTRU, 1 IES-ECC, both are 128-bit secure, what you have right now is 2 ciphertexts requiring $2^{128}$ work to recover the plaintext without having the corresponding private key. This is true even if the encoded ...

3

Question: is it safe to use the DERIVED key, where the ORIGINAL key is the same, but the salt is different every time? No, but the reason is a little tricky. First, forget AES-CBC—you should use an authenticated cipher like AES-GCM (if you must use AES) or NaCl crypto_secretbox_xsalsa20poly1305, and focus on the security contract. AES-CBC is hard to use ...

2

For key derivation use PBKDF2, Bcrypt, Scrypt, or better use Argon2id. Argon was the winner of the Password Hashing Competition question: is it safe to use the DERIVED key , where the ORIGINAL key is the same, but the salt is different every time? If you use a different randomly generated salt, you will be fine. You can also append a counter to the ...

1

I assume you were thinking about changing the block cipher inside the CTR construction, i.e., instead of encrypting each counter with AES, you would encrypt with "3AES". First, notice that 3DES normally uses three keys and not two. Three-keys 3DES has 112-bit security level, while two-keys 3DES has around 80-bit. So, I'm assuming you want to use CTR mode ...

3

It would not improve security at all. For AES-CTR mode, encryption and decryption use the same algorithm: generate the key stream using the counter and then XOR the plaintext with it. Because of that, step 1 and 3 would completely cancel each other out, and you would be left with the "decryption" in step 2. If you'd just use the first two steps then you ...

7

First of all, GCM is a form of counter mode. Which means that unlike with e.g. cipher block chaining, the output of one block depends on exactly one block of input. Worse, yet: You can modify a single bit and the decrypted result will differ in exactly that bit. Because if you are honest, a block cipher in counter mode is not a "block cipher" at all, but a (...

3

The practical answer is that you should almost certainly be using authenticated encryption, in which case authenticating an individual encrypted message requires you to process all of it anyway. Once you throw in this element, random access into encrypted data becomes not a matter of message encryption modes, but rather of how to split your data into a ...

0

Which of the two types of Argon2 is the best for password-based key derivation? As noted by Forest if you are unsure always choose Argon2id. How can I use Argon2 with a predefined salt? From a library for Argon2 Usage: ./argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m memory] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] ...

2

what value or iteration count is enough? So in NIST SP 800-63B a baseline of 10,000 iterations is recommended. Going below that is a really bad idea. Now of course the actual guidance is "do as many iterations as you can afford", which usually amounts to "do as many as your users are willing to wait for". If 65,000 already take 1 second and your users will ...

1

I want to know if the following would also be equally secure Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305. In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis ...

7

We don't know. Although it seems unlikely to the extreme that there is some kind of mathematical equation that gets easier to solve when the second key relies on the first key, we probably cannot prove it. So that's it for the theoretical problems. One practical problem is that when the key for confidentiality is obtained by the adversary (e.g. through a ...

7

The other answers are great, but I wanted to call out an interesting feature of modern cryptography. Your question asked: I thought, why even use AES or DES or any other complex way for encrypting data when there are far simpler ways, like just generating a random (pseudorandom) bitstream, and XOR'ing it with the data or secret message? In point of fact, ...

2

...random enough.. Let's just focus on that as it forms the nub of your question. Yes,$$\text{random (pseudorandom) bitstream} \oplus \text{secret message}$$ is very simple, works and is in common usage. But the first term in this encryption function masks great (and necessary) complexity. In order to be secure, the bitstream must comprise independent ...

10

We use more complex encryption algorithms than XOR with a random or pseudo-random keystream for a number of reasons: In order to get a short secret key in symmetric encryption. XOR with a true random stream (One Time Pad) requires storing or/and transfering a secret keystream the size of the data to encipher, which is utterly impractical. Replacing the ...

4

You could use a one-time pad, which does grant confidentiality when properly employed, but then you would have many non-trivial problems: Your message or messages would have to be quite short because generating letters in a truly random manner usually takes a bit of time and effort (rolling dice). One-time pads only have limited practical use. You cannot ...

1

What you're describing would be a One-Time-Pad. The OTP would actually be perfectly secure, but the first problem is in the issue that you have to generate a bit stream using a cryptographically secure pseudorandom number generator (CSPRNG) instead of a usual pseudorandom number generator. But even that doesn't pose a particularly large problem. Keep also in ...

8

TL;DR: GCM provides excellent performance with the best security properties we expect from ciphers today (AEAD). GCM use CTR to build a stream cipher. This a well studied method, which has only one drawback: it absolutely needs some authentication to prevent bit flipping. Before GCM, CTR-then-MAC was the solution. One main advantage of stream ciphers is the ...

1

However, if your message is exactly 128 bits long, do you only perform the XOR with the IV and the encryption with the key once? Or is there a way to split up a 128 bit message so that you can perform the cipher block chaining method as intended. This is a non-starter, as there is nothing wrong with performing a single block encrypt in CBC mode. For 128 ...

0

Firstly, you need to apply a padding scheme like PKCS#5 or PKCS#7 so that your message will be always a multiple of 128. A 128-bit message than will be two-block. However, if you have one byte less than the block size, you will have 128-bit messages this means that you have one block. After the padding, you can encrypt with CBC mode. The first block will ...

0

A standard way to encrypt a message is to apply some sort of padding (PKCS #7 for instance), that converts messages of arbitrary length to a set of fixed-size plaintext blocks (16 bytes in case of AES-128). If your properly padded message is contained in one block only, you just encrypt that block. CBC and other modes of block cipher operation do not ...

2

Yes, it would be possible to identify Serpent or Twofish keys from round keys in memory, which are likely to exist in a software-only implementation optimized for speed (but not in hypothetical hardware implementations, and not necessarily in implementations optimized for RAM or code size). The Serpent round keys are 132 words of 32 bits, output by a ...

3

Yes, Serpent also does a deterministic well-known key expansion. So it should be possible to identify the sub keys in memory. You will want to know what implementation you are looking for since there is more than one sensible order for the key material to be in.

3

However all typical disk sector sizes are divisible by AES block size (128bit). So does that mean that disk encryption uses XEX mode and not doing cipher-text stealing at all? Given that XTS is indistinguishable from XEX if the block size divides the sector size, yes disk encryption in practice nearly always uses XEX / XTS. While in theory you could now go ...

2

The requirements differ per mode of operation. AES itself is a block cipher, and as block cipher, it doesn't take an IV at all. Tweakable block ciphers may take a tweak, which may have some overlap with an IV, but AES isn't tweakable by itself. CBC requires an unpredictable IV (to the adversary). One of the common ways is indeed to generate a 16 byte (one ...

2

It seems you're worried about two distinct attacks: replay attack (attacker reads a packet and re-sends it later), and a "delay attack" (attacker intercepts a packet, blocks it, and sends it later). The replay attack can be avoided with counters or timestamps; as you mentioned, timestamps can be easier. The hard part is keeping clocks synchronized. The ...

7

All listed modes are vulnerable to manipulation attacks in one way or another. And all modes require specific prerequisites to be secure. This could be a maximum message size or having an unpredictable IV in the case of CBC. Only authenticated modes can achieve message integrity / authenticity. Others are all vulnerable because changes to the ciphertext ...

0

GCM is an authenticated encryption scheme; it allows Alice and Bob to detect if messages have been tampered. If the DH exchange is authenticated, then you don't need to sign anything.

8

First, I would not call this AES-ECB, since adding randomness means that it is not ECB. Second, when limiting the message space to what fits into one block, asymptotically -- meaning for a pseudorandom permutation with block size $n$ -- this construction is actually even CCA-secure (and so non-malleable, since indistinguishability and non-malleability are ...

4

Is it still distinguishable under chosen plaintext? Yes; consider the encryption of $2^{32}$ occurrences of the same 8 byte block; it is likely that two of the blocks will have the same random padding (and hence the same 16 byte ciphertext block).

1

I just wanted to add a reverse engineering perspective on this sort of thing, since I've broken some such systems before. Attackers often don't care about unraveling the math to determine the original algorithm. You can just copy the obfuscated algorithm outright from the (for example) movie player. It doesn't matter whether the code is simplified. The ...

2

Do we consider all zeros (0000000) as empty block of data or is it still a data? Either it is a block of data or it isn't, there is no such thing as an "empty block". And yes, it is still data (data is always plural), as it has certain properties such as a size. For AES it needs to be 16 bytes of any value to be considered one block of data. Do we really ...

0

To better understand the below concrete answers, a short background on how disk encryption is usually performed with AES. The most tools will use one of the following two modes: CBC-ESSIV, which is just standard CBC encryption where each sector is one "message" and the IV is derived deterministically from the index of the sector to be encrypted as \$\text{IV}...

Top 50 recent answers are included