104
The difference between the PKCS#5 and PKCS#7 padding mechanisms is the block size; PKCS#5 padding is defined for 8-byte block sizes, PKCS#7 padding would work for any block size from 1 to 255 bytes.
This is the definition of PKCS#5 padding (6.2) as defined in the RFC:
The padding string PS shall consist of 8 - (||M|| mod 8) octets all
having value 8 - (...
46
Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.
AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.
In ...
37
XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data.
However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ...
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 ...
31
The crucial difference between plain encryption and authenticated encryption (AE) is that AE additionally provides authenticity, while plain encryption provides only confidentiality. Let's investigate in detail these two notions.
In the further text, we assume $K$ to be a secret key, which is known to authorized parties, but unknown to attackers.
Goals
...
23
Contrary to what Stephen says, you absolutely can compute the tag in parallel.
Here's how it works; the tag computation is essentially "assemble the AAD, data, the length field and $Encr(Nonce)$ into a series of values $x_n, x_{n-1}, x_{n-2}, ..., x_0$", and then "compute the polynomial $x_nh^n + x_{n-1}h^{n-1} + x_{n-2}h^{n-2} + ... + x_0h^0$
This ...
21
CBC does not perform authentication
This property makes it less suitable for places where authentication is required, basically any transport protocol. TLS uses CBC, but by default performs authentication over the plain text instead of the ciphertext, which opened up a host of attacks. CBC can be used here, but it is error prone and may require an ...
18
There are some serious problems with this design that would preclude it from being standardized, so it probably does not have a name.
The 2 visibly main flaws are as follows:
If the plaintext follows a pattern similar to the block counter, the
block cipher inputs may repeat, exposing information about the
plaintext (exact same issue as reuse of nonce, but ...
17
The security of that approach is equivalent to that of normal CBC.
Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC.
A ciphertext produced with your ...
17
A block cipher is an invertible transformation that maps an $n$ bit block of bits to an $n$ bit block of bits, under the control of a key (and where $n=128$ in the case of AES)
Now, we most often need to do things other than mapping blocks of $n$ bits; how we do that is using the block cipher within a Mode of Operation. A mode of operation is just a way to ...
17
TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility.
Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS ...
15
Do not use a fixed IV. It can have seriously negative consequences. This is especially true for CBC mode.
That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.
14
Thomas is correct; there's no attack on CFB mode if you can predict the IV; NIST is just being cautious.
With CBC, the value of the first encrypted block $C_0 = E_k( IV \oplus P_0)$, where $IV$ is the IV used for that packet, $P_0$ is the value of the first plaintext block, and $E_k$ is the evaluation of the block cipher.
If an attacker can predict the ...
14
The algorithm (now reasonably clear) is reminiscent of a block cipher in CFB mode, with $random$ as the IV (which can be public), $secret$ as the key, and MD5 used as keystream generator instead of the block cipher.
Decryption works as in CFB:
\begin{align*}
M_1 &= C_1 \oplus \operatorname{MD5}( secret\mathbin\|random )\\
M_n &= C_n \oplus \...
14
Short answer:
There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group.
Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political (...
13
While you do operate block-by-block when generating the pseudorandom stream, the actual encryption step (i.e., the XOR) is bitwise, and therefore does not require the message to be padded.
For example, the message "Hello" will be processed as follows (pseudocode):
byte stream[16] = AES(Key, Nonce);
byte plaintext[5] = "Hello";
byte ciphertext[5];
for i ...
12
The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.
11
If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable.
And in fact, if you do not use the decrypted ...
11
An OCB like mode seems impossible with stream-ciphers. It's coupled tightly to the concept of a keyed permutation i.e. a (tweakable) block-cipher.
Many authenticated encryption actually combine two distinct primitives. It's just that the specification and API only expose the combination.
Essentially these xor a key-stream into the message to encrypt it (i....
11
With CBC mode the initialization vector is referred to as IV, because it is not nonce. There are ways to construct nonce so that it does not meet the needs of CBC mode. Random IV is one generation choice which is usually fine.
Nonce can also be a counter, which is not ok here.
Definitions
Nonce means number used once.
IV means initialization vector.
CBC ...
11
The reference for this is NIST SP800-38A, especially its appendix B.
Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ...
11
The infinite garble extension makes sure that if a ciphertext block is changed that this block and each block after it doesn't decrypt correctly. The way that additional plaintext is affected when the ciphertext is changed is called error propagation. Error propagation over large parts of the plaintext is mainly interesting if you want to combine it with ...
10
An initialization vector never needs to be secret. If it needed to be secret then it would be called a "key" instead of a "vector".
Generally, the initialization vector requirements are only dependent on the mode of operation, not the choice of the block cipher. The parameters of the mode of operation, such as the IV size, may however depend on the block ...
10
A mode of operation is an explicit method by which we use a block cipher (eg AES) to do more than just encrypt one block of data. For example, it may allow us to encrypt multiple blocks of data (eg ECB,CBC etc), provide us with some authenticated encryption (eg GCM) or a method for encrypting disc storage (eg XTS).
Rijndael,DES etc are block ciphers. That ...
10
I do not remember if we checked this explicitly, but my guess is that in the chosen-plaintext setting the biclique attack would still be faster than the exhaustive search, maybe by the factor of 2 compared with 4 in the chosen-ciphertext setting.
However, both results are pretty far from declaring AES broken in any sense. Such small gain over exhaustive ...
10
AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster.
CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-then-encrypt or MAC-and-encrypt, using single key).
Cipher-text length is the same for same ...
10
In CBC mode the decryption equation is $P_i = D_k(C_i) \oplus C_{i-1}$. If you received a corrupted $C_i$, $P_i$ and $P_{i+1}$ will be decrypted wrong, but $P_{i+2}$ no longer depends on $C_i$ and will be correct.
10
You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset.
Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ...
10
It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks.
For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m \...
10
I would pick e) none of the above. None of those modes offers integrity protection, so unless integrity is handled elsewhere, your application is wildly insecure. An attacker could modify bits in transit and do nefarious things.
Of the three, CFB and CTR are the worst for the application and should be very easy for an attacker to mount successful attacks, ...
Only top voted, non community-wiki answers of a minimum length are eligible
