Tag Info

10

ECB leaks if blocks are identical. For uniformly random data identical blocks become likely when you encrypt about $2^{n/2}$ blocks with an $n$ bit block cipher. CBC and CTR mode develop similar weaknesses when they encrypt that much data. => As long as you encrypt reasonable amounts (up to a petabyte or so) of random data with a 128 bit block cipher, like ...

9

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

8

Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the ...

8

That statement is ambiguous, so I'll list a couple of limitation of block ciphers and cryptography in general: A raw blockcipher by itself only permutes a fixed size block (128 bits for AES). You need to add a mode of operation (together with IVs and possibly padding) to make it flexible enough for practical use. There are many modes to choose from, ...

7

In the first block, the IV provides the "randomness", and in subsequent blocks you just use the previous block of ciphertext instead. Based on the assumption, that the cipher is not weak and behaves like a pseudorandom permutation, this is basically the same: You XOR something unpredictable on the plaintext, and then encrypt. As long as the IV is chosen ...

7

I've checked out the source code (well, more or less, it's not that well designed, the main crypto class is 1600 lines) and as Richie guessed, the algorithm is stored together with the ciphertext. Pretty gruesome stuff, but it does do EAX mode for text strings to my surprise. It probably only uses it for text strings originating from the password vault code ...

7

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.

6

XTEA is a block cipher. It requires a block cipher mode of operation to work. Together with a block cipher mode of operation you can generate something that is secure. For this you require at least an IV, as you may otherwise encrypt identical passwords (for different users) to identical values. Or, if you encrypt each character separately, the same ...

6

A symmetric cipher design contest was started in Ukraine around 2006, and this cipher (in Ukrainian and Russian: Мухомор) was there. For specifications, look for "Applied Radioelectronics" journal "Прикладная радиоэлектроника", 2007, No 2. http://anpre.org.ua/?q=pre_2007_2 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/61794/06-Dolgov.pdf

5

Dedicated stream ciphers typically are, or at least can be, somewhat faster than constructions based on block ciphers. (If they weren't, there would be no point in using them, since a block cipher can do everything a dedicated stream cipher can.) What you gain in speed (and possibly code size), however, you lose in versatility: A block cipher (in CTR / ...

5

You might consider using TEA or its successor, XTEA. Here's the complete C source code for XTEA, taken from the Wikipedia article: #include <stdint.h> /* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { unsigned int i; uint32_t v0=v[0], ...

5

All modern block ciphers are supposed to be pseudorandom permutations, meaning that they cannot be efficiently distinguished from a truly random permutation without knowledge of the key. (If a practical distinguisher were to be found for a particular cipher, that cipher would be considered broken by modern standards.) This also implies that no two secure ...

5

Suppose you do CTR mode as: $E(k,nonce+1) \oplus m_1$, $E(k,nonce+2) \oplus m_2$, $E(k,nonce+3) \oplus m_3$, etc. The wikipedia page is talking about a non-random nonce, with a specific example of a packet counter. So suppose $nonce$ is a packet counter and in each packet you encrypt several blocks. You might end up with the following: In packet #$p$: ...

5

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, ...

5

The key size is simply the amount of bits in the key. With AES, like most modern ciphers, the key size directly relates to the strength of the key / algorithm. The higher the stronger. AES is a bit different with respect to the key size in the sense that both the key schedule and the number of rounds are different for each key size. Because of this there ...

5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...

4

I should begin by noting that this seems like an unusual assignment. I'm not sure why someone would explicitly have a goal of combining block ciphers and stream ciphers. First, let's summarize the difference between block and stream ciphers, since this may be useful for future readers. Block ciphers are so called because they operate over fixed lengths of ...

4

The size of the key depends on the security level you want, it is not possible to say "you need exactly $n$ key bits if you have a block size of $m$ bits". Let's assume that for an ideal cipher, a block size of 32 bits means $2^{32}$ possible input values which can be permuted in $(2^{32})!$ ways. That means you would have at most $\log_2(2^{32}!)$ key ...

4

Yes, EME is a wideblock cipher. Theorem 1 (in Section 4, top of page 5) states that EME is secure as a wideblock (tweakable) cipher under the assumption that AES (or whatever blockcipher you use) is secure. Specifically, to someone who doesn't know the key, EME will look like a set of random, independent permutations (one for each tweak). This is true even ...

4

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 ...

4

They're both broken under known plaintext attack, where attacker knows two (plaintext, ciphertext) pairs, $(m_1,c_1)$ and $(m_2,c_2)$: $E'_1(k_1,k_2) := k_1 \oplus E(k_2,m)$ $E'_1(k1,m_1) \oplus E'_1(k1,m_2)=E(k1,m_1) \oplus E(k1,m_2)$ The attacker simply computes $E(k1,m_1) \oplus E(k1,m_2)$ for every possible value of $k_1$ and compares it with $c_1 ... 4 Actually, Maarten isn't quite correct; in most cases, the counter doesn't have to be updated in constant time (because it's not secret); however in one case it does: GCM with an IV size that's not 12 bytes. The reason the counter needs to be secret in this case is not because how it is used, but how it is generated. It is initialized to ... 4 What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ... 4 One of the basic security requirements of a block cipher mode of operation is that it is indistinguishable under chosen plaintext attack (IND-CPA). Essentially, this means that, if an attacker chooses two messages$m_A$and$m_B$and the defender randomly returns either$\text{Encrypt}(K, m_A)$or$\text{Encrypt}(K, m_B)$(with$K$kept secret from the ... 4 Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely ... 4 The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done. That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, ... 3 As long as the IV is chosen correctly, every individual block of the encrypted output will be uniformly random over the set of all bit-patterns of the given size. Each block is independent from the clear text, but they are not independent from each other. The first block contains the IV itself, which by construction is uniformly random and independent from ... 3 To answer the question we first need to take a quick look at how XTS encrypts data: $$C=E_{k_1}(P\oplus(E_{k_2}(n)\otimes\alpha^i))\oplus(E_{k_2}(n)\otimes\alpha^i)$$ With$\oplus$denoting bitwise XOR,$n$denoting the sector index,$i$denoting the block index within the sector.$\alpha$is a polynomial in the$GF(2^{128})$and is exponentiated ... 3 As I understand, your question is about using an involutive function$F$as a block cipher. This function is constructed as$F(x) = D(P(E(x)))$, for some (let's assume secure) block cipher represented by$(E, D)$. I will assume the encryption and decryption keys are equal such that the same holds for$F\$. Below is a generic attack that only uses the ...

3

Yes there is a significant difference concerning brute-force. ECB suffers from multi target attacks whenever you encrypt the same message block. This is always possible in a chosen-plaintext attack and often possible in practice with a known-plaintext attack. With CBC the IV means that the plaintexts passed to the blockcipher are almost certainly unique ...

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