Hot answers tagged cbc
9
Not at all secure; generating preimages would be trivial. Here's a demonstration with a three-block message:
Here is your suggested method (limited to three block messages):
$E_0 = Encrypt( IV \oplus P_0 )$
$E_1 = Encrypt( E_0 \oplus P_1 )$
$E_2 = Encrypt( E_1 \oplus P_2 )$
$E_3 = Encrypt( E_2 \oplus 0 )$
$Hash = E_0 \oplus E_1 \oplus E_2 \oplus E_3$
...
9
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 ...
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 ...
7
There's no need for an IV when unique keys are used.
When each key is used only to encipher a single message, it is safe (from a confidentiality standpoint) to use null IV for all messages. That's customary, for all common modes requiring an IV. It avoids the need to generate an IV, and transmit it, and (in the case of CBC) perform a XOR of the first block ...
6
The 16-byte IV and ciphertext (which together are part of the output of $e_m$) are assumed to be intercepted by an adversary. That reveals the number $b$ of 16-byte blocks in the ciphertext. With CBC and PKCS#7 padding, $b=\big\lceil{{n+1}\over16}\big\rceil$ where $n$ is the byte size of the plaintext (the file size). Putting $n$ itself in a header thus ...
6
The CBC IV attack does more than that.
If I guess the plaintext corresponding to any ciphertext block I've seen before, and can predict a future IV, I can verify my guess by submitting a suitable message to be encrypted with that IV. Obviously, that could be bad if, say, I knew the plaintext to be either "yes" or "no", and only needed to find out which one ...
5
First of all, you stated:
Because this message is encrypted using CBC mode, any modification of
the first block of cipher text would propagate throughout the message.
Actually, that's not true. Here's the CBC mode operation in the decryption direction:
(Public domain image from Wikimedia Commons.)
If you examine the process closely, you will see ...
5
While I'll try to answer your question at a theoretical level below, I'd like to first stress the following: It's a bad sign if, in the course of writing software, one is making such low-level decisions about encryption methods. Encryption security is extremely brittle, with seemingly insignificant details causing complete failure.
With that said, the ...
4
AES (as any block cipher) strifes to be indistinguishable from a random permutation, so any property like $C_1 \oplus C_2 = P_1 \oplus P_2$ would be quite bad.
This property (with $K$ as the "key stream bits") is valid for synchronous stream ciphers, including the one time pad and stream cipher modes of block ciphers (CTR, OFB, and for the first block also ...
4
1) The adversary queries the oracle (with some randomly chosen message $m$) and gets as a result a message $m=m_1|m_2|...$ and its tag $t=(t_0,F_{k_2}(t_r))$. She then draws $\rho$ uniformly at random in $\{0,1\}^n$ and outputs the message $m=\rho\oplus m_1|m_2|...$ and its (valid) tag $t=(\rho\oplus t_0,F_{k_2}(t_r))$.
2) The adversary queries the oracle ...
4
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 ...
4
XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data.
However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ...
4
Well, to figure out this sort of thing, it's easier if we work backwards.
So, we start at the back (the fact that we can store up to 512 characters in a database field), and consider how much binary data we can store. Well, base-4 takes 3 bytes of binary data, and encodes it in 4 bytes of base-64. Thus, we can store 3*(512/4) = 384 bytes of binary ...
4
Your problem is that if you encrypt two messages which start the same (and change at some point later on) the beginning of the ciphertext will be the same in CBC mode when using the same IV.
Normally you should change the IV every time you encrypt a new message. This is precisely what the IV is meant for - achieving IND-CPA (semantic) security which ...
4
Yes, this is fine, at the record level. (What you've built would be classified as a "Encrypt-then-Authenticate" scheme in the literature, and there are standard provable security results for such schemes.) Well done on constructing a solid, well-engineered cryptographic scheme.
An AEAD mode would spare you from having to invent such a scheme, but what ...
3
Designing an HSM or other secure device is relatively easy; making it reliable even in the absence of adversary requires careful engineering; making it safe against adversaries with some level of physical access is hard; demonstrating that it is safe (for some definition of that) is even harder.
One thing to worry about is integrity of stored data ...
3
16 bytes is 128 bits, which matches the block size of AES-256, but not "256 bit block" in the (original) title. Hence the question is ambiguous: was it meant 16, or 32 bytes?
For 16 bytes: ECB reduces to single-block encryption, and yes ECB is safe, for a definition of safe that let one test identity of plaintexts by testing identity of the ciphertexts.
...
3
If you know that the integer is fixed in size (always in the range 1-1000), then the second approach is fine. Effectively, you still have a random nonce (what you are calling the "junk"); you concatenate the nonce and the integer, then encrypt the result with AES-ECB. This works.
Do make sure that you choose a large enough random nonce. I recommend ...
3
The IV for a block cipher in CBC mode must not only be "uniquely used for each message encrypted with the same key". It is usually assumed to be indistinguishable from random by an adversary.
If the IV is predictable, some attacks apply. For example, if an attacker is able to choose plaintext messages with prior knowledge of what the IV will be for this ...
3
Assuming:
the objective is to protect the confidentiality of the user names from an attacker having read access to the encrypted data, the ability to add usernames of her choice, and nothing else (in particular, no access to the key, even by proxy of a computer or device holding the key, or side channel);
the IV is randomly chosen for each individual ...
3
Sure, that's fine, but you're really just using the first block of ciphertext as the IV.
If you choose the first plaintext block to be a running message counter (which you might as well do; it's easier than generating a random block) and your "discarded IV" to be all zeros (or vice versa) then your method is equivalent to standard CBC mode combined with the ...
3
Use the master key in ECB mode. I have heard/read that this is cryptographically weak (Why?).
The reason I include ECB mode here is that it could allow me to save half the storage space. Since the messages are only one block long, I suspect this may affect the 'traditional' arguments against ECB.
Because any identical plaintexts will encrypt to the ...
3
Do not use a fixed IV. It can have seriously negative consequences. You don't say what mode you were going to use. This would be a pretty important piece of information for us to know.
That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.
3
The $1/2^{32}$ is an arbitrary figure, based upon one particular value for what counts as an acceptable risk.
You need to decide what is an acceptable risk. If you think that a $1/2^{32}$ probability of failure is an acceptable risk, then this calculation is relevant to you. If you think it isn't, then decide what you think is an acceptable risk and re-do ...
2
Yes, in theory, but this doesn't usually work in practice. You are right in that the last-block ciphertext in this example is malleable to some extent, but not as much as you seem to suggest. It is true that here, if you were to change the last ciphertext block so that the first byte of its corresponding plaintext corresponds to some value you chose, it ...
2
CBC is a block cipher mode of operation, not a cipher. It can work basically with any block cipher - the choice of the block cipher itself is independent (to a large extent) from the choice of the mode of operation.
Examples of well known block ciphers include AES, DES, TripleDES, Serpent, Blowfish etc.
The title of your question, however, asks about ...
2
The proper precautions, this is an acceptable way to implement CBC (and yes, it interoperates with the more traditional implementation of CBC, at least, implementations of CBC that put the IV immediately in front of the ciphertext).
The proper precaution is to make sure, in the encrypt direction, that the value of the iv exclusive-or'ed with the block of ...
2
You are hoping to get integrity protection by applying CBC mode; the problem with this is that CBC mode isn't great at providing integrity protection.
One way an attacker can exploit this, if he guesses what the plaintext is, he could modify block N of the plaintext to anything we wants by changing block N-1 of the ciphertext. This will modify block N of ...
2
That would work and almost certainly wouldn't have any negative impact on security, but it would be cleaner just to have a string of 16 0x00 bytes at the start of a message, instead. Not only does this save you the trouble of hashing, but you stay within the standard threat model for CBC which assumes the IV is independent of the message blocks. (One can ...
2
Keeping the (initial) IV secret only adds security for the first block of your cipher text. The IV for the second block is by definition the first cipher text block, and so on. So if we would have the key but not the initial IV, we could decrypt the whole ciphertext except the first block. So it doesn't add much security, but it does add "management", as you ...
Only top voted, non community-wiki answers of a minimum length are eligible
