17

The input length of OAEP is directly specified in the standard: M message to be encrypted, an octet string of length mLen, where mLen <= k - 2hLen - 2 or simply mLen = k - 2 * hLen - 2 if we want to calculate the maximum message size. Where: k - length in octets of the RSA modulus n hLen - output length in octets of hash function Hash ...


15

No, this isn't an oversight. AES is a block cipher, which is a keyed permutation. Now if you have a permutation of, say, three elements there are e few permutations possible: a -> a b -> b c -> c but also: a -> b b -> c c -> a and a -> c b -> a c -> b and a -> c b -> b c -> a (there should be $6$ for $3!$, the ...


14

AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128.


13

It is usually assumed that the length of the message is not secret. Even with padding the approximate length is leaked, and necessarily any encryption reveals a maximum length – or at least information content if compression is used – because the ciphertext cannot in general be shorter than the message. NaCl's secretbox does not use a block cipher, but a ...


13

I believe that he was referring to the misconception that the birthday problem that arises in encryption is only when you use the same counter twice. If a random IV is used, then such a counter repeats at $2^{32}$ blocks with high probability (and if you want a $2^{-32}$ safety margin then you can only encrypt $2^{16}$ blocks). However, if distinct counters ...


11

CBC mode encryption is defined as: $C_i = E_k(P_i\oplus C_{i-1})$ (with $P_i$ being the $i$th plaintext block, and $C_{i-1}, C_i$ being the ciphertext blocks. What might happen if we have a lot of ciphertext encrypted with the same key is if two ciphertexts happen to be the same, that is: $C_i = C_j$ If we see that, we can then immediately deduce that: ...


11

Such a block cipher would be completely unusable in any of the standard modes of operation, presuming you want at least IND-CPA security. Say, for instance, that you are using it in CTR mode. A chosen plain text adversary looking at a cipher text consisting of only two blocks (i.e. 2 times 32 bits), would have a non-negligible probability (higher than $2^{-...


10

We can still safely use 64-bit-block ciphers when used in an otherwise sound protocol, and all of the following three conditions are met: The effective key size is made big enough; that disqualifies DES (55-bit), but not Blowfish (up to 448 bits), TEA (128 bits), 3DES (167 bits), and to some degree 2-keys-3DES (111 bits). Note: I computed the effective key ...


9

If you use a key for close to $2^{n/2}$ blocks in CBC mode, then the chance of getting a collision in the ciphertext is getting rather high because of the birthday paradox. As the ciphertext is used as a vector for the next calculation, and since that vector should be unpredictable, you would likely lose confidentiality. Note that the author seems to have ...


8

There is no NIST oversight here. The key size and the block size are two completely different parameters and issues. The only reason that you need a large block size is because bad things start to happen when you encrypt too many blocks. Specifically, for an $n$-bit block size, the birthday paradox kicks in at $\sqrt{2^n}$. So, for a 128-bit block, you need ...


7

First of all, there's no such thing as a secure 8-bit block cipher, at least not as such things are conventionally used. That's because there are only 256 possible values for an 8-bit byte, and a block cipher will map each of these values to a different fixed value. Thus, an attacker who can even occasionally guess the unencrypted value of some bytes (or, ...


7

Block ciphers are usually used in modes of operation. The security of a mode of operation depends on two things: the security of the underlying block cipher, and the security of the mode itself when you replace the block cipher with an "ideal" permutation. Say you're using a block cipher with block size $n$ bits, so with AES-256, $n = 128$ (the 256 refers ...


7

First of all, in the case of SHA-3 we don't call it block size but bitrate. SHA-3 has been formally defined in FIPS 202 and in its reference manual. We define the sponge function denoted by $\operatorname{KECCAK}[r,c]$ by applying the sponge construction as specified in Algorithm 1 with $\operatorname{KECCAK-}\!f[r+c]$, multi-rate padding and the bitrate ...


7

I don't think the term "wide block cipher" has a hard definition beyond has a larger block size than the current standard algorithm(s) which right now in most cases would equal to has a block size larger than 128 bit because AES is our current reference standard. Now the thing with block ciphers is that they are are pseudo-random permutations and ...


7

This answer summarizes what's achieved against CTR mode in the paper pointed by Yehuda Lindell's answer: Gaëtan Leurent and Ferdinand Sibleyras's The Missing Difference Problem, and its Applications to Counter Mode Encryption (in proceedings of Eurocrypt 2018). The setting is CTR mode with an $n$-bit block cipher applied to a plaintext consisting of $2m$ ...


6

Well, $\operatorname{GHASH}$ might be better understood as the polynomial: $$\operatorname{GHASH}_H(X_1, X_2, ... , X_{m-1}, X_m) = X_1 H^{m} + X_2 H^{m-1} + ... + X_{m-1} H^2 + X_m H^1$$ where addition, multiplication and exponentiation are in the field $GF(2^{128})$. These addition, multiplication and exponentiation operations act algebraically quite a ...


6

There are two well-known Encryption modes, that can construct a $mn$-bit tweakable blockciphers from a $n$-bit blockcipher ($n=64$ for DES) with $1\le m\le n$. The older one is CMC, being not parallelizable. It was superseeded by Encrypt-Mix-Encrypt (EME), which is parallelizable. The basic idea of the two algorithms is to encrypt each block of input data ...


6

The "block size" matters for Merkle-Damgård functions because the HMAC security proof relies on that block size. For other functions, and in particular sponge functions, the block size for HMAC is mostly a matter of convention. In fact, HMAC uses two nested calls to the function because such a construction is more or less needed to ensure security with MD ...


6

Does the block size of a symmetric cipher impact the security of the cipher itself? Yes, absolutely. A small block size limits the amount of data that can be encrypted with a given key, and some block modes are more badly affected by this than others. Additionally, some cryptographic attacks against weak ciphers can be made more practical against a block ...


6

Firstly, is this a correct threshold for considering a cipher secure? Not exactly. Security is a spectrum, so what is secure for some applications may not be secure for others. Is a $2^{-64}$ probability of attack success too much? For some it is far too high. For others, even $2^{-32}$ is fine. In the case of known plaintext attacks, an attacker is usually ...


5

There's no blockcipher providing this. However if you want this kind of mapping there are two usage scenarios. Strengthen the symmetric encryption. You could double the keysize by this construction. In "Applied Cryptography" Schneier suggested to combine two encryption algorithms so the ciphertext would be double the size of the plaintext. Generate a pad $...


5

Encrypting big amounts of data is no problem for block cipher - if you remember a few important things. You can't encrypt plaintext which is bigger than the block size. You need to do some addition work. Most cipher operation modes first divide the plaintext into blocks of the size of the cipher. Now you can do different things: How about just encrypting ...


5

Block size does not directly affect the security of the cipher. However, if block size is too small, it can prevent you from using the cipher securely. The main effect of block size is due to the fact that a block cipher is meant to be a pseudorandom permutation (PRP). That means that any two inputs will have outputs that differ iff the inputs differ. So ...


5

If the sender and recipient can agree on the nonce of every message from existing context, so that the nonce either doesn't need to be transmitted or can be derived from metadata that must be transmitted anyway, then a stream cipher can be used to encrypt with no length expansion. But the problem here is that you likely don't want just plain encryption, but ...


5

A "block" is the amount of bits your block cipher operates on (There are other kinds of ciphers, see below.) Think of a Caesar cipher, it replaces letters in words. For example with key 13 it replaces as follows: A -> N and HELLO ALICE -> URYYB NYVPR Note that the same letter will always be replaced by the same letter. So it operates on one ...


4

Yes, it is possible to implement the primitive asked, with a 32-bit block cipher that is secure (indistinguishable from a random permutation) no matter how many input-output pairs are known, keyed with a fixed secret randomly-chosen key. That's a standard building block in Format Preserving Encryption. One such block cipher is: Louis Granboulan and Thomas ...


4

It depends on the application. If you are using the block cipher as a hash function or for a MAC (say in CBC-MAC fashion), then it very well could create problems. Preimage attacks would be much easier than they should. For normal encryption, however, there wouldn't be a problem since the key is not known to the attacker. As evidence of this, consider ...


4

An 8-bit block cipher would be practically unusable. A $b$-bit PRP can be used fewer than $2^{b/2}$ times before it's distinguishable from PRF and this limit carries over approximately as is to block ciphers. So you could use it (less than) 16 times per key, i.e. for 128 bits of data. If you had a 128-bit key you might as well use it as a one-time pad. If ...


4

In addition to the tweakable enciphering schemes in the comments, I'll leave this reference here: https://eprint.iacr.org/2009/356.pdf It essentially shows (in the ideal cipher model) that using an n-bit block cipher in a three-round Feistel construction gives you a 2n-bit block cipher.


4

GOST symmetric cipher uses 256-bit keys to encrypt 64-bit blocks. That means there are many keys which give the same result This is actually incorrect. A block cipher, when given a key, maps $n$-bit plaintext blocks to $n$-bit ciphertext blocks (and vice versa for decryption). Here's a toy example for $n=2$: $E_k(00) = 01 \\ E_k(01) = 10 \\ E_k(10) = 00 \...


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