# Tag Info

10

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

9

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

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

A 6-byte nonce can expect to receive a collision 0.01% of the time after around 240,000 nonce generations (based on a birthday attack). After 100 such rotations (a little under 17 years, based on your 2-month rotation policy), that comes out to a likelihood of just under 1% of experiencing a collision. On the surface, to me that seems like a reasonable ...

4

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

If you assume AES is a pseudo-random permutation(which is pretty much necessary for it to be secure), then yes. However, it's way easier to just use a random IV/noce and keep the keys. Your new key must be distributed to both parties secretly, the IV/nonce can be public, so you can just send it (HMACed of course) in the clear. You obviously can't do this ...

2

There aren't any known attacks on the PRFness of HMAC-SHA256 better than brute force. (So you can truncate that MAC to length L where $\:\:\frac1{2^L}+\epsilon\:\:$ is an acceptable risk of forgery.) To reduce the impact of a forgery without making the ciphertext any longer, one should use a format-preserving encryption (FPE) scheme that is secure against ...

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

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

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

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

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

1

The "shortest possible amount of overhead for describing ciphertexts" is achieved by encrypt(key,nonce,plaintext) = prefixfree(length(nonce)) || FPE ( length(nonce)+length(plaintext) , PRF(key,length(nonce)+length(plaintext)) , nonce || plaintext) The basic idea is to use independently keyed block ciphers for each possible plaintext length, and ...

1

You asked the same question over on the IT Security site. Please don't cross-post. It is frowned upon, under the rules these sites operate. Here is what you should be doing: Truncate the MAC tag to an acceptable length. You will need to choose a length that provides a suitable tradeoff between packet size vs. security against forgery. I suggest you use ...

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