# Tag Info

11

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

10

Suppose you use the sector number times the number of AES blocks per sector as the initial value for CTR. If you successively store the content $M$ then $M'$ in the same sector $n$ then $E^{CTR}_n(M) \oplus E^{CTR}_n(M') = M \oplus M'$ (where $E^{CTR}_{n}$ is the encryption function with CTR mode and IV started for sector number $n$). CTR mode fails ...

6

From the diagram on CTR mode you can notice that there are no dependencies between any of the phases of the pipeline. If you have more than one block-size worth of data, you can process each block-size chunk completely independently of the others by calculating $\mathrm{ciphertext}_i = E(\mathrm{key}, \mathrm{nonce} \, || \, \mathrm{counter}_i) \oplus ... 6 First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments. Now, some observations. I haven't read all your code, so I may misunderstand things. Is this a good way to whiten the data? Is ... 6 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 ... 5 Yes, there are secure alternatives to support random-access based encryption. I did not come up with a way to break the proposed combination. Still, instead of inventing a new mode, I would recommend to take consider existing modes for this kind of operation, such as XTS mode. The existing modes are more studied, and (in some ways) more efficient. XTS mode ... 5 The entire block consists of a$n$bit nonce and a$128-n$bit counter. Typically$n=64$. The nonce needs to be large enough so that every message under the key can have a unique one, and the counter needs to be large enough that every message block can have a unique counter value. Typically, the counter is initialized to 0 and then incremented by 1 for ... 4 As long as you never re-use a specific counter value with the same key, counter mode protects the privacy of the message. All counter values are equally secure. You just have to be sure never to re-use any counter value in two different messages. Zero is no different to any other counter value in this respect. However, if you ever re-use any counter ... 3 Generally, it depends on the architecture. If you have$n$processors available, the obvious way to parallelize CTR mode encryption is to distribute each chunk of$n$consecutive blocks among the processors, so that processor$0 \le i < n$computes: $$C_j = E_K(c_j) \oplus P_j, \quad j = i + kn, k = 0,1,2,\dotsc$$ where$c_j$is the$j$-th counter ... 3 Let$2^m$be the average message length in blocks. When using an independent random nonce for the whole 128-bit IV of each block, you would expect a collision after$2^{64}$blocks, i.e.$2^{64-m}$messages. (But you double the data size.) When using a 96-bit nonce and a 32-bit counter, you would expect a nonce collision after$2^{48}$messages. This is ... 3 AES-CTR mode can be used to generate stream of random numbers. For generating random numbers, the plaintext is indeed irrelevant. It can be even full of zero (the NIST recommended way to generate random numbers uses such plaintext.) NIST has recommendation on how to generate DRBG (deterministic random bit generator) based on CTR mode. NIST has defined how ... 3 You can get up to around$2^{64}$random bits from counter mode (before you hit the birthday bound due to the lack of a collision), simply by running it as is. If you've got a full implementation of counter mode, the plaintext can be anything you like, because the stream (ie the output of the$E_k(ctr)$calls), should appear uniformly sampled from$2^{128}$. ... 2 Relying solely on randomization for the block counter is actually more likely to cause a nonce collision in case of a system time reset. This only gets worse as the message length increases. This is further exacerbated if the PRNG takes the system time as input, or does not have enough seed entropy. There is also no reason for the static 0 byte in the nonce. ... 2 Key/IV pairs should not be reused for either AES-CTR and AES-CBC - or for any other symmetric cipher for that matter. As a cipher is a Pseudo Random Permutation (PRP) inserting the same input will result in identical output. If you perform that operation you will leak information to an attacker; the attacker can distinguish data with the same contents. CTR ... 2 Like said in the comments, a 256-bit message is two blocks of AES, no matter the keysize. The main issue with ECB mode (i.e. using AES directly on 128-bit blocks) is that you leak whether two blocks are equal. When encrypting perfectly random data, that means there's a$2^{-128}$chance the two parts of the key are equal, and the attacker knows that. The ... 2 I would advise a different solution. You either generate a master-key (or key set) or derive one from a user password (e.g. via PBKDF2 or SCrypt). For each file to encrypt you generate a random key (file key) and nonce ad-hoc, and encrypt the file with that key, using an AEAD scheme. The random file key is encrypted with you master key and put at the ... 2 We think that the player will not be able to get this key by extracting it from the memory or somehow else. Forgive me, but I'm skeptical. If you really have figured out a way to do this --- and plenty of well-funded, intelligent people have tried and failed --- I'd recommend slapping a patent on it and making millions off of licensing fees. How ... 2 It probably doesn't. Yes. For strings$x,m0,m1$such that$\text {length}(x) = \text{length}(nonce)$and$\text{length}(m0) = \text{length}(i) = \text{length}(m1)( nonce || i ) \oplus ( x || m0 ) = ( nonce || j ) \oplus ( x || m1 ) \iff m0 \oplus m1 = i \oplus j$. I'm not aware of any. 2 Your combined mode of operation is not as easy to attack as a two-times-pad (i.e. stream-cipher with fixed IV used twice), but it still has some weaknesses. For example, an attacker which did read your file before and after the change can easily find out which 128-bit-blocks of the file did change and which ones stayed the same. Depending on the file format ... 2 The CTR part of CCM is basically the last for loop in the _ctrMode function: for (i=0; i<l; i+=4) { ctr[3]++; enc = prf.encrypt(ctr); data[i] ^= enc[0]; data[i+1] ^= enc[1]; data[i+2] ^= enc[2]; data[i+3] ^= enc[3]; } i.e. CTR is simply: encrypt a counter block with a block cipher, xor the encrypted block into the data, ... 2 There is no real advantage, other than the fact that it allows you to convert a block cipher into a stream cipher securely. Since there has been a large amount of research put into block ciphers and ciphers such as AES are commonly implemented in hardware (such as AES-NI), it allows for reuse of the primitives. Side note: the nonce generally does not need ... 2 Any plaintext will do. If you choose 0x000..., then you can skip the XOR step entirely. One extra step you can take to improve security is to periodically use the stream to choose a new AES key. This provides forward security: if an attacker manages to compromise the system (say, using a heartbleed-type exploit) and learn the current key, he will not be ... 1 In effect, does this mean that a separate HMAC must be created for every single message, i.e. all 16 bytes? No, you can use HMAC over the whole message with all its blocks. Of course, that means you can't localize corruption/tampering, so if you were sending a huge message you might want HMAC smaller parts (but longer than 16 bytes or you are ... 1 Well, lets try to take a concrete example: Suppose that you have a 142 bit message that you need to encrypt with CTR mode. What do you do? Well, you generate the first 128 bit block with AES; you take the first 128 bits of the message, exclusive-or the two, and that's the first 128 bits of the ciphertext. Then what? Well, you have 142-128=14 bits of ... 1 With a 4 byte counter, it is a representation of a 32-bit unsigned integer. Since the counter increments from 0, there is no need to store it on a per message basis. This then becomes an implementation issue. A smart AES-CTR implementation would accept ANY initial counter/nonce value, and simply 0-pad it to the desired length. If we supply the cipher only ... 1 If by "encrypted" you mean generating a keystream, then what you propose is to use in the CTR mode $$C_i = P_i \oplus F_K(IV||i)$$ the following function$F\$: $$F_{K_1||K_2||K_3} = E_{K_1}\oplus E_{K_2} \oplus E_{K_3}.$$ This is secure as long as you ensure that for each key all the used IVs are different (i.e. are nonces). As mentioned in another ...

1

One answer would be nonce space: adding a tweak significantly increases the number of different nonce-tweak options you're allowed, thus increasing the maximum data that can be safely encrypted with a single key. Update: In his modes paper, Rogaway quotes an earlier source the CTR was dismissed due to trivial malleability. This makes a lot of sense, since ...

1

SipHash would fit well for the low amount of data and small tag.

1

An even more robust approach could be to use something like SIV mode (RFC 5297) with a nonce composed of a timestamp and a random value (and possibly, if practical, a message number). Basically, when encrypting a message, SIV mode first computes a MAC of the plaintext and the nonce (and any other associated data) using a modified form of CMAC, and then uses ...

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