112
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 ...
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 ...
32
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 ...
19
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
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
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 \...
15
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 (...
12
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 ...
12
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 ...
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.
12
The Bit Flipping attack
Decryption process in CBC mode is performed as
\begin{align}
P_1 =& Dec_k(C_1) \oplus IV\\
P_i =& Dec_k(C_i) \oplus C_{i-1},\;\; 1 < i \leq nb,
\end{align}
where $nb$ is the number of blocks.
If you know the position of the target byte, then you can modify the corresponding ciphertext position in the previous ciphertext ...
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
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.
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
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 the padding oracle attack you have an oracle that only tells you whether a particular chosen ciphertext decrypts to a correctly padded plaintext. That oracle is used to build a last word oracle, which used iteratively can reveal a whole message.
The reason it works in CBC mode is that we can make predictable, arbitrary changes to the plaintext of the ...
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, ...
10
You would not just need a mode of operation for what you're asking. What you need is a secure transport protocol. Probably the best well known one for TCP connections is TLS of course. For UDP connections you could use DTLS. If you have a shared key you could use one of the pre-shared key (PSK) variants.
If you want to create your own transport protocol you ...
10
from what I know CBC is the most secure Mode of operation for the AES block cipher
I'm not exactly sure why you say this; however, there has been a couple of practical problems with CBC mode in the past:
Padding Oracle attacks; as originally designed in SSL (and carried into TLS 1.2), the way TLS implements CBC mode (with the padding and the HMAC) is prone ...
10
Let's take AES-CBC for example—a typical cryptosystem that requires a randomized IV. Suppose I can predict the IV in advance. Then I can start by asking for the encryption of $\mathit{iv}_0$, which is $\operatorname{AES}_k(\mathit{iv}_0 \oplus \mathit{iv}_0) = \operatorname{AES}_k(0)$, and proceed by asking to be challenged on the messages $m_0 = \mathit{...
10
However if you added a counter to ECB mode and XORed each block of plaintext with the counter, you could avoid that problem.
This is trivially insecure. Counter-Example: Consider the nonce $0^n$ and the plaintext $0^{2n-1}\|1$. This mode will encrypt the first block to be $E(0^n)$ and the second block to be $E((0^{n-1}\|1)\oplus(0^{n-1}\|1))=E(0^n)$ and so ...
Only top voted, non community-wiki answers of a minimum length are eligible
