Hot answers tagged modes-of-operation
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} ...
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
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 ...
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
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
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 ...
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
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 ...
5
I found a little more info on Google, so let me provide a partial answer to my own question. In particular, I found a post by David Wagner to sci.crypt in 2004, titled "IND-CPA for CFB mode", which in turn led me to a paper titled "Practical symmetric on-line encryption", published in FSE 2003 by Fouque, Martinet and Poupard.
In this paper, the authors ...
5
This is what ciphertext block chaining is about - each plaintext block is XORed ("chained") with the previous ciphertext block before encrypting (and after decrypting).
The initialization vector then takes the place of the ciphertext block before the first block (since there is none).
So, mistaking the initialization vector as a ciphertext block does ...
4
The short answer for the mode: use EAX.
There are several reasons why EAX is Good, but, in particular:
It includes integrity check, which is a must have (yes, really; defense against active attackers is often overlooked, and this is equally often deadly).
It needs a unique IV (a nonce) but tolerates predictable nonces.
As for OFB and CFB, see the ...
4
The properties that an IV must meet are strongly dependent on the mode that the IV is be used in. Some modes require unpredictability; other modes don't care about unpredictability but require uniqueness.
As for OFB mode, it's in the 'don't care about unpredictability, but require uniqueness' camp. In particular, as long as you never reuse an IV, and you ...
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
Reflex answer: EAX. EAX does encryption and authentication, with minimal space overhead. EAX also has light requirements on the IV: it just needs a non-repeating value, so a simple counter can work. Possibly you already have a suitable counter or time stamp in your packets, that can be used as IV.
About replay attacks: you already expect that some packets ...
4
Yes, of course you need to know the mode of operation in order to decrypt.
On the other hand, the mode of operation isn't usually explicitly transmitted in the ciphertext. Using the same key with different modes of operation may cause unexpected weaknesses. For example, consider one message encrypted with CFB mode with IV=2 (which is perfectly secure) and ...
3
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, ...
3
CFB with a fixed IV? Yikes! That is completely insecure: for the first 16 bytes of plaintext, it is even worse than ECB mode, and that's saying something. Please go enlighten whoever thought it was a good idea to expose this as the only mode of encipherment available (or even one among multiple options).
Let me elaborate. It sounds like the baseline is ...
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
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 ...
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
In the correct use of CBC mode, you should see the following:
$c_1=E_k(IV\oplus p_1), c_2=E_k(c_1\oplus p_2)$, etc
and decryption is:
$p_1=D_k(c_1)\oplus IV, p_2=D_k(c_2)\oplus c_1$, etc
From what you are saying, it sounds like you have stored in the file (for case 1):
$IV||c_1||c_2||\cdots$ (where $||$ is concatenation).
So, what will decryption do? It ...
2
A replay attack works by blindly re-using an earlier message or ciphertext, or fragment thereof, typically one that was encrypted or signed. A simple example would be a bunker which receive the encrypted message "I'm General X, open the door". Now if this encrypted message was captured a week earlier and replayed by some opponent, well you get the idea.
...
2
ECB mode is a deterministic encryption, instead in OFB if the initial vector is random choosed (and of course published with the cryptogram) is a random encryption.
What's the matter with det.enc.? The problem is that if you encoded two time the same message you are going to get two time the same chipertext, so the adversary can understand that you said the ...
2
Counter mode allows predictable IVs.
You generally partition the counter in to two pieces. One portion guarantees the counter is unique, the other piece is what you increment.
So when using a 128-bit block cipher you might partition it so that 64-bits are your uniqueness portion and the remaining 64-bits of the counter.
The uniqueness piece can be done ...
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
As @fgrieu mentioned, what you're after is FPE. The papers he linked deal with FPE on a very small domain, but it looks like you're interested in encrypting longer strings.
For that, you need a wideblock cipher. Unlike traditional blockciphers, these typically allow different input lengths, which is a plus. They meet your criterion of not revealing shared ...
2
Sure, basically GCM is counter mode encryption with an authentication tag added. You can encrypt any part of the stream without issue if you know the key and the counter for that part. Obviously, you cannot check the integrity though, because the tag is the integrity of the entire file.
Basically, you only have to perform the top part of the scheme:
1
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
