Tag Info

Hot answers tagged

11

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


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


7

I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ...


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 reference for this is NIST SP800-38A, especially its appendix B. Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ...


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


5

If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset ...


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


4

No, this is safe. In fact, if you show a way of distinguish the stream $AES_{k_1}(C) \oplus AES_{k_2}(C)$ from a random stream with fewer than $2^{64}$ outputs, you have just demonstrated a way of distinguishing AES from a random permutation. Here is how this works: suppose we are given Oracle assess to a permutation $P$, which might be $AES_{k_1}$ for ...


4

The sum of PRPs is a secure PRF. That paper gives as a security bound for a sum of two independent PRPs $q^3/2^{2n-1}$, where $q$ is the number of queries and $n$ the block size (i.e. 128 for AES). That means that your construction, correctly used, is more secure than a single PRP, for which the bound is $q^2/2^n$. If you wanted to give an adversary an ...


4

Like the other answers say, it does not always have to be the case. One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value.


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


3

In CTR, you can use any operation which has a full cycle through the space of the IV with the counter. You could use the plus operator like the example: $69dda8455c7dd4254bf353b773304eec + 1 = 69dda8455c7dd4254bf353b773304eed$ To calculate the next value, just again add 1. You could also use a increasing counter and xor it with the original IV: ...


3

Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is. The Salsa20 quarterround, and thus rowround, columnround and doubleround are invertible. However, the whole Salsa20 core is not because the initial state is added to the state after iterating the rounds (cf. page 6 in the spec). If I use salsa20 ...


2

This will not be secure in general, and is not recommended. The reason is that a PRG is guaranteed to produce a pseudorandom output only if its input is uniformly random (or pseudorandom). Moreover, several PRG outputs are jointly pseudorandom only if the PRG is run on independent seeds. But here you are invoking the PRG on "structured" inputs, i.e., the ...


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


2

The once part inside of the nonce in CTR mode means effectively "once for this particular key". If you use a fresh key for each message (e.g. by encrypting it using public-key crypto or similar), you can use the same nonce for all the messages (or a size-zero nonce). The important part is that the combination of nonce and ctr-value (i.e. what is input into ...



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