Hot answers tagged modes-of-operation
19
The really simple explanation for the difference between the two is this:
ECB (electronic code book) is basically raw cipher. For each block of input, you encrypt the block and get some output. The problem with this transform is that any resident properties of the plaintext might well show up in the ciphertext – possibly not as clearly – that's what blocks ...
13
With CBC (Cipher block chaining) mode, before encryption, each block is XOR-ed with the ciphertext of the previous block, to randomize the input to the block cipher (and avoid encrypting the same block twice with the same key, as this would give the same output, and tell the attacker something about the plaintext).
As the first block has no previous block, ...
13
The algorithm (now reasonably clear) is reminiscent of a block cipher in CFB mode, with $random$ as the IV (which can be public), $secret$ as the key, and MD5 used as keystream generator instead of the block cipher.
Decryption works as in CFB:
$$M_1 = C_1 \oplus \operatorname{MD5}( secret||random )$$
$$M_n = C_n \oplus \operatorname{MD5}( secret||C_{n-1} ...
10
The initialization vector is a property of the mode of operation (aka "chaining mode"), not of the block cipher itself. A block cipher does only one thing, which is mapping blocks (block size depends on the cipher, 64-bit for DES, 128-bit for AES) unto other blocks. The chaining mode is what says how input data should be transformed into block values, and ...
10
After reading the paper How to Break XML Encryption (thanks to Krzysztof for the link), here are my two cents.
This attack relies on the fact that a CBC-ciphertext C = (IV, C1, ... Cd) can be decomposed into pairs of (IV, C1), (C1, C2), (C2, C3), ... (C(d-1), Cd), each of which is also a valid CBC ciphertext for the same key, relating to the corresponding ...
9
Neither. It means that an attacker can decrypt all messages that have been encrypted using this standard.
The attack is a padding oracle attack. That means that, if the attacker has a ciphertext they want to decrypt, they can send several variations of the ciphertext to the server. By analyzing the server's responses (e.g., error messages returned), it ...
8
Each mode of operation has its own IV requirements. Some need uniform, unpredictable randomness. Other are equally happy with just uniqueness.
CBC is well-known for its need of an IV chosen randomly and uniformly among the possible IV values, and such that an attacker who can choose the text to encrypt may not predict the IV value before submitting the said ...
8
If you look closely at the definition of authenticated encryption modes, you will see they all are, actually, the combination of symmetric encryption and a MAC.
Using traditional encryption and an independent MAC has a few tricky points, none of them being unsolvable:
The encryption mode will use a key, and the MAC will also use a key; using the same key ...
8
Free space and used space look exactly the same to someone who only sees one version of the ciphertext.
First, the basic idea of a secure block cipher is that you learn nothing about the plaintext block simply by observing the ciphertext block. You may be able to learn something about the plaintext from the surrounding context, such as by collecting more ...
8
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 ...
8
If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable.
And in fact, if you do not use the ...
8
It's not clear from your decryption what the algorithm is used for.
But you should be aware that while at first glance it provides privacy : it's a weird mode CFB with md5 used as a block cipher ; it doesn't provide authenticity.
A simple bit flip of the ciphertext will result in the corresponding bit being flipped in the plaintext and such a bit flip ...
7
SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their excellent book "Practical Cryptography" (later updated by Ferguson, Schneier, and Kohno and renamed "Cryptography Engineering") as a way to make SHA-256 invulnerable to "length-extension" attack. They called it "SHA-256d". We started using SHA-256d for everything when we launched the ...
7
ECB and CBC are only about encryption. Most situations which call for encryption also need, at some point, integrity checks (ignoring the threat of active attackers is a common mistake). There are combined modes which do encryption and integrity simultaneously; see EAX and GCM (see also OCB, but this one has a few lingering patent issues).
7
The security of that approach is equivalent to that of normal CBC.
Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC.
A ciphertext produced with your ...
7
A block cipher is an invertible transformation that maps an $n$ bit block of bits to an $n$ bit block of bits, under the control of a key (and where $n=128$ in the case of AES)
Now, we most often need to do things other than mapping blocks of $n$ bits; how we do that is using the block cipher within a Mode of Operation. A mode of operation is just a way to ...
6
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 ...
6
You say that a random IV "would also be unique", but really that is the crux of the problem. The problem with counter mode is that it is secure unless the same counter is used twice; if it is, it is likely that an attacker will be able to recover both plaintext messages. This contrasts with CBC mode, which if you repeat an IV, it has the relatively benign ...
6
A reason to use CBC (or CFB) over CTR and OFB could be that they are a bit more misuse-resistant: If you use CBC with a repeated initialization vector, a (read-only) attacker only can get the fact that the plaintexts are equal up to some block, and not much more (and from the first different block the rest is different). With CTR and OFB, a repeated ...
6
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 ...
6
Thomas is correct; there's no attack on CFB mode if you can predict the IV; NIST is just being cautious.
With CBC, the value of the first encrypted block $C_0 = E_k( IV \oplus P_0)$, where $IV$ is the IV used for that packet, $P_0$ is the value of the first plaintext block, and $E_k$ is the evaluation of the block cipher.
If an attacker can predict the ...
6
I recommend that you prepend a random 16-byte prefix. Prepending a random 16-byte prefix, before encrypting with your CFB mode, will be just as good as using a random IV. The argument is pretty similar to Using CBC with fixed IV.
If we use CFB with an all-zeros IV and a random 16-byte value prefixed to the message before encryption, as you suggested, we ...
6
EDIT: The following block of text (between the lines) was written as an answer to the original question, which did not explicitly state that the secret was used for any blocks after the initial one.
Hmmm, I assume that the goal of this algorithm is to provide privacy; that is, to create an encrypted message, and someone that hears this encrypted message ...
5
Given only what you've said, and assuming the keys are created and stored in a strong manner, using a different key to encrypt database entries mitigates the problem of ECB mode. Namely that identical plaintext, when encrypted with the same key always outputs the same ciphertext. No security is gained by switching to CBC mode (assuming you can easily store ...
5
The trouble with ECB begins when you encrypt two blocks with the same key. If every slot in your system has its own key which is ever used to encrypt only one block (which means that when you modify one of your pieces of data, you also use a new key), then there is no problem with ECB. If you reuse a key, if only time-wise (you update an entry with a new ...
5
Well, the methods we use to take a block cipher (such as DES), and turn it into an actually useful function (say, to encrypt a large message) is called a mode of operation.
Such a mode of operation takes the message (generally of arbitrary length), and processes it (usually block by block), using the block cipher as a primitive.
There are a number of such ...
5
OFB and (to a lesser degree) CFB are malleable: an adversary knowing a selected portion of the plaintext and able to change the ciphertext can trivially change the alleged plaintext to something chosen, e.g. "no!" to "yes". CBC has a (small) degree of resistance to that.
OFB does not allow decryption of an isolated segment of ciphertext. CBC (and CFB) do.
...
5
For block ciphers, it depends on which mode of operation you're using — nobody uses just a plain block cipher for anything, at least not unless all their messages are shorter than a single cipher block (typically 8 or 16 bytes).
ECB mode, which just amounts to chopping the message up into blocks and feeding each block through the cipher, does not use ...
5
Just use the build in crypto PRNG of your operating system or framework.
C# / .net: RNGCryptoServiceProvider Class
Java: SecureRandom Class
Linux: /dev/urandom
Win32 API: CryptGenRandom function
date/time might be enough for modes which only require uniqueness, but if you generate two IVs in quick succession(within 16ms or so) or if the clock is changed. ...
Only top voted, non community-wiki answers of a minimum length are eligible
