Tag Info

Hot answers tagged

11

While you do operate block-by-block when generating the pseudorandom stream, the actual encryption step (i.e., the XOR) is bitwise, and therefore does not require the message to be padded. For example, the message "Hello" will be processed as follows (pseudocode): byte stream[16] = AES(Key, Nonce); byte plaintext[5] = "Hello"; byte ciphertext[5]; for i ...


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


10

Well, as far as we know, the mode you suggest should be secure. Now, to be honest, AES256 versus your mode isn't quite a fair comparison; your mode gives somewhat less theoretical security; if you encrypt a known $2^n$ block message, the key can be recovered with $2^{256-n}$ effort; however, this observation doesn't really affect the practical security. ...


9

Yes, the attacker would have a realistic chance of recovering plaintext, and preventing him from knowing the IV values does not reduce this risk. The problem is that CTR mode encryption is effectively: $C = P \oplus F(Key, IV)$ where $P$ is the plaintext, $C$ is the ciphertext, and $F$ is a complex function of its two inputs. The problem with this is if ...


9

I wrote a rather lengthy answer on another site a few days ago. Bottom-line is that CTR appears to be the "safest" choice, but that does not mean safe. The block cipher mode is only part of the overall protocol. Every mode has its quirks and requires some extra systems in order to use it properly; but in the case of CTR, the design of these extra systems is ...


8

To expand on Thomas's answer, you have to transfer a CTR nonce somehow for the simple reason that you should need it to decrypt your data. Specifically, for a given block of data you calculate: $$p = N \oplus c(i)$$ Where $i$ is the count of the blocks you have used, $c$ is the count function which might be very straightforward, $N$ is your nonce and ...


8

It is an IV and it is safe to transmit with the ciphertext (if it wasn't, we would call it a key).


8

Assuming that you can indeed guarantee that the keys will never be reused, both schemes should be secure. The only requirement for the nonce in CTR mode is that it must be unique (and, if used directly as the initial counter value, not equal to any intermediate counter value used in the past or in the future). If you're only encrypting one message with a ...


7

In general, CTR mode is not secure against chosen-ciphertext attacks. (The same goes for the other classic block cipher modes of operation too; to get security against chosen-ciphertext attacks, you need authenticated encryption.) In your stated attack scenario, the attacker can obviously use the decryption oracle to decrypt any ciphertexts they intercept, ...


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

There is no "best" mode of operation, just modes more or less useful in different situations. CBC-mode requires an initialization vector which is unpredictable by the adversary (preferably random), especially if this adversary can mount a chosen plaintext attack. Up to TLS 1.0 (i.e. also in SSL 2.0 and 3.0), CBC was used with a "use last block of previous ...


6

Personally I like the modes that support integrity checking and authentication, e.g. GCM, as they only require one key, and are not vulnerable to changes in the cipher text. One particular important problem area is padding oracle attacks, which are much more common than people seem to admit. Note that GCM/AES is - just like CTR - a block cipher in stream ...


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


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


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


5

A tweakable blockcipher where the tweak is set to a counter, and the plaintext gets encrypted directly has the same properties as your idea. When these properties are desired, you can use either a specialized tweakable blockcipher such as threefish, or you turn a normal blockcipher into a tweakable blockcipher. When using AES, a typical choice is XTS, ...


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

Yes, that's correct assuming you have, say: 0x347ABCD98....000000001 | | | --- Counter (64-bit width) | ----------------- 64-bit nonce prefix What you're trying to do is ensure that each 128-bit AES block is xor'd with a different value. The reason for this is that, if you take typical AES, you have a ...


5

The CTR mode of encryption is defined in general for any cryptographically strong pseudo-random function (PRF). You can build such a PRF from a hash function. For CTR, you produce a key stream by concatenating: $$F(k,0) || F(k,1) || ... || F(k,m)$$ where $F$ is your secure PRF, $k$ is your key, and $m$ is the the length of your plaintext divided by the ...


5

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


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

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

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

Check out "Analysis of SHA-1 in Encryption Mode", Handschuh, Knudsen, and Robshaw (2001), and some of the papers that cite it. They give some evidence that the answer to your question might be "yes".


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

Yes, authenticate the IV. If an attacker changes the IV while keeping the rest of the ciphertext intact, they'll change the message. Just because they can't change the message to an arbitrary value doesn't mean they can't cause harm (if nothing else, they can send random junk until they hit a valid command or a bug in your parser, or feed you invalid data). ...



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