6

ChaCha20 has Ind-CPA security and beyond this ( Ind-CCAx.. [1]), you need integrity and authentication. And note that Authenticated Encryption > Ind-CCA. ChaCha20 is already teamed with Poly1305 authenticator to provide confidentiality, integrity and authentication. It exists in TLS standards and one of the five cipher suites in TLS 1.3 as ...


4

In some applications, a serious limiting factor for the security of 4DES is its 64-bit block size. In common modes of operation, that limits the security to data sizes that are insufficient for many application nowadays. It makes 4DES much less secure than AES-128 is. For example, assume a VPN in CBC mode using a fixed key. Assume an adversary injects known ...


4

Yes, with some more ciphertext. The CFB mode encryption equations; \begin{align} I_0 &= \text{IV}\\ I_i &= \big((I_{i-1} \ll s) + C_i\big) \bmod 2^b,\\ C_i &= \operatorname{MSB}_s\big(E_K(I_{i-1})\big) \oplus P_i\\ \end{align} and decryption equations; \begin{align} I_0 &= \text{IV}\\ I_i &= \big((I_{i-1} \ll s) + C_i\big) \bmod 2^b,\\ ...


3

simplified CFB supports random read access. but what about the real CFB where we have a shift register? Sure it does; actually, it's not that difficult. In CFB, the "plaintext" submitted to the underlying block cipher is the previous $b$ bits of the ciphertext (where $b$ is the block size). The shift register is there just to allow us to track ...


3

There the $b$ bits mean the block size of the Encryption and that is 64 for DES and 128 for AES. Therefore you may need more than one block for the encryption of your plaintext (message). If your message size is $\ell$ than you need $$\lfloor \frac{\ell}{b} \rfloor + 1$$ blocks to encrypt. The block nature of the CBC mode like any other, not like CTR, ...


2

For transporting messages you need a transport protocol, not just a block cipher mode of operation. The handshake of a transport protocol is used to authenticate the entities and to establish session keys (and more). Those are essential activities to protect the messages send using the protocol. TLS is most common, where DTLS is explicitly specified for UDP -...


2

Why is the comment needed that encrypted MAC part is constant? With the scheme in the question, in a cryptogram with the correct MAC, the last block of the encrypted message is a constant. Importantly, that goes both ways: if the last block of the encrypted message is that constant, then the MAC is correct and whatever plaintext is deciphered will pass the ...


2

In cryptographic operation modes that require the initialization vector to be non-repeated rather than random, the initialization vector is called "nonce" (number used once). Do not design the implementation of a mode if you cannot fulfill the requirements of the mode. For example, if a mode depends on a uniqueness of the initialization vector, you ...


2

I went through this decision process about 2 years ago and ended up going with something very conservative: encrypt-then-MAC with AES-256-CBC and HMAC-SHA-512 truncated to 256 bits. Why SHA-512 over SHA-256? SHA-512 is faster on 64-bit machines. (Though recent AMD processors' SHA-256 instructions yield a 4x speed-up: link). Why AES-256 over AES-128? ...


2

It really depends on the block mode that you are going to use. If you want to use something like CBC, have a look into PKCS#7. If you were to use CTR mode, then you do not require any padding, as the input will always be in chunks of 16 bytes, and you use as much of it as you require.


1

JoJoTheCodeDude's answer is correct. I just want to add some detail which may clear up some possible misunderstandings and followup questions. AES is a block cipher. Contrary to the name Advanced Encryption Standard, it's not actually useful for practical encryption of anything. That's because, like any block cipher, it can safely encrypt exactly one block ...


1

That's not a mode, that's the same mode used four times. And yes it's as secure as doing all the blocks sequentially.


1

My understanding is that the cipher's encryption: Performs a fixed public reversible transformation of the first 128 bytes of plaintext. Enciphers the first 8 bytes $[B_0…B_7]$ with $K_1$, $K_2$, then $K_3$ Enciphers bytes $[B_{4+8i}…B_{11+8i}]$ with $K_1$ Enciphers bytes $[B_{2+8i}…B_{9+8i}]$ with $K_2$ Enciphers bytes $[B_{1+8i}…B_{8+8i}]$ with $K_3$ The ...


1

I guess you are referring to this whitepaper, so I will refer to it in my answer. First, I think you misunderstood part of the protocol (illustrated in Figure 1): the KDF is not AES-CFB8. A KDF is a Key Derivation Function: in this particular case, it basically acts as a hash function, transforming the inputs into a random-like stream of bytes We assume the ...


1

I've read several texts which say that if the entire plaintext is a multiple of the block-size padding is not required (and not using padding would not mean a loss of security). I generally disagree on this. In modes where padding is used (e.g., CBC), padding is mandatory. This is per spec. Not including the padding is simply not an option. In some ...


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