Tag Info

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

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

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

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

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

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

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

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

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

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

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

The number of different key streams depends on the keysize used and the number of bits in the nonce. Say you are using an $n$ bit key and $k$ bits for your nonce. Then the theoretical maximum number of keystreams is $2^n\cdot 2^k=2^{n+k}$ since each combination of nonce and key should result in a different keystream. If you limit the length of your ...

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

What you explain in the question resembles SHACAL-2 cipher's forward cipher function, see http://en.wikipedia.org/wiki/SHACAL#Security_of_SHACAL-2. SHACAL-2 is NESSIE accepted way of using SHA-256 as cipher, therefore it has appeared somewhat secure.

I am assuming that $n$ is small enough that the counter never rolls over and repeats, and that the IV is chosen randomly from the space of all possible IVs. The length of the plaintext is leaked, but that is leaked by the ciphertext anyways. The plaintext for a given ciphertext is leaked as the attacker can feed that in to the oracle. AFAIK, however, ...

As said by Thomas in the comment, modern encryption algorithms should work for all kinds of data, regardless of whether the plaintext is partially known or not. In both modes of operation (CTR and CBC), for stored data you should remember to get a new initialization vector and reencrypt your whole "message" (or database entry) when changing any part of the ...

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

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

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

For counter mode, the only condition for your IV (i.e. initial counter value) is, that it doesn't repeat over messages, and more, that it doesn't collide with any of the counter values in use for all the messages using the same key. One way to do this would be to simply count forward from the last message, e.g. first message uses 1, 2, 3, second message ...

There are problems with the approach you describe. The biggest is that if changing the key every block causes a significant slowdown. Many block ciphers get a significant speedup by precalculating the key schedule once and then reusing this for many encryptions; your proposal blocks that optimization and thus has a significant performance penalty. There ...

I think the attack on CBC that you're referring to is a known-plaintext attack where an attacker can manipulate a plaintext by adjusting the previous block of ciphertext. But this same sort of attack also applies to CTR. [edit] I misinterpreted the OP's referenced to a CBC attack. The one I describe here allows intelligently modifying plaintext by modifying ...