CFB mode with same initialization vector
Daniel Vogelheim
why is encryption in CFB mode insecure, if you use the same
initialization vector multiple times?
Applied Cryptography, 2nd ed., says so (chapter 9.6, p.201 middle),
but doesn't explain. I have been unable to figure it out on my own,
and a search turned up nothing. Where can I find a paper eplaining
details?
Any help is greatly appreciated.
Sincerely,
Daniel Vogelheim
SCOTT19U.ZIP_GUY
I don't like to adverstise or quote to many people but all
the in vogue chaining mods are weak. But I did a quick
alta vista search on your question the link it came up
with somthing that may anwser some of your question. However you
can also like at ritters page or the FAQ.
http://www.rsa.com/rsalabs/faq/html/2-1-4.html
Most commerical applications use methods simalar to above.
One way you can test for a weakness in my mind any way. Is
to find an encryption method that hides little of the method from the user and
does not change the length of the message being encrypted.
Fist encrypt with one key then reverse the byte order of file and
encrypt with second key. Change one bit in the file then try to recover
the plain text. If the whole file is trashed( use a binary file compare)
then the encryption chaining method might be ok. If only a few blocks
are wrong the chaining method sucks. And you need something
like methods used in scott16u or scott19u which have been proven secure
against such modern attacks as the "Slide attack" which Mr BS and DW
think is hot stuff though most likely decades behind what the NSA uses.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
Peter Pearson
>
> why is encryption in CFB mode insecure, if you use the same
> initialization vector multiple times?
The danger is that you might encrypt plaintexts whose
beginnings are identical, thereby producing ciphertexts
whose beginnings are identical. It is not respectable
for an encryption system to reveal the fact that messages
X and Y have the same beginning, even if the system doesn't
reveal what that beginning is.
If some convention in your plaintext guarantees that
the first block of plaintext will be different every
time, the system is as strong as the underlying block
cipher, even with fixed IV. (Corrections, you other guys?)
- Peter
p...@my-deja.com
Not quite. If the first two plaintext (resp. ciphertext) blocks
of two different messages are P1 and P1' (resp. C1 and C1') then
with the same IV used you'll get C1 XOR C1' = P1 XOR P1' thus
leaking lots of info about the first plaintext blocks.
i.e. if you already know P1 then you can trivially compute P1'.
If you have an implementation that uses CFB mode with a fixed IV
(and I seem to recall that there is a widespread little crypto
program that does just this) then you should really consider the
first blocks of everything you encrypt with it as being in the clear!
(Unless of course you use a different key each time you invoke it).
Paul(o)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Daniel Vogelheim
thanks for your quick responses. Just for background info: I ran
across a crypto system that uses a hardcoded IV with CFB, that's why I
am asking.
Peter wrote:
>The danger is that you might encrypt plaintexts whose
>beginnings are identical, thereby producing ciphertexts
>whose beginnings are identical.
I can see that, but it's no problem as the precondition (identical
plaintexts) isn't met in the aforementioned system.
However, in the book (AC2) Schneier very clearly states:
"If the IV in CFB is not unique, a cryptanalyst can
recover the corresponding plaintext."
This is a much, much stronger claim than yours. Unfortunately, I still
don't understand why this would be so.
David wrote:
>[...] but all the in vogue chaining mods are weak.
>[...] However you can also like at ritters page or the FAQ.
>http://www.rsa.com/rsalabs/faq/html/2-1-4.html
I checked both, and neither mentions the particular problem of reusing
(or even hardcoding) IVs, so I still don't know why this should be
weak.
Thank you,
Daniel Vogelheim
P.S.: This is a repost, as the first post didn't show up on my news
server. Sorry if you read this twice.
Peter Pearson
>
> In article <37A5CAAC...@slip.net>,
> Peter Pearson <peter_...@slip.net> wrote:
> > Daniel Vogelheim wrote:
> > >
> > > why is encryption in CFB mode insecure, if you use the same
> > > initialization vector multiple times?
> >
> > beginnings are identical, thereby producing ciphertexts
> > for an encryption system to reveal the fact that messages
> > X and Y have the same beginning, even if the system doesn't
> > reveal what that beginning is.
> >
> > If some convention in your plaintext guarantees that
> > the first block of plaintext will be different every
> > time, the system is as strong as the underlying block
> > cipher, even with fixed IV. (Corrections, you other guys?)
>
> Not quite. If the first two plaintext (resp. ciphertext) blocks
> of two different messages are P1 and P1' (resp. C1 and C1') then
> with the same IV used you'll get C1 XOR C1' = P1 XOR P1' thus
> leaking lots of info about the first plaintext blocks.
Eeek! Dead right! All this time I was reading "CBC" for "CFB".
- Peter
Daniel Vogelheim
Peter wrote:
>> > The danger is that you might encrypt plaintexts whose
>> > beginnings are identical, thereby producing ciphertexts
>> > whose beginnings are identical.
Paul wrote:
>> Not quite. If the first two plaintext (resp. ciphertext) blocks
>> of two different messages are P1 and P1' (resp. C1 and C1') then
>> with the same IV used you'll get C1 XOR C1' = P1 XOR P1' thus
>> leaking lots of info about the first plaintext blocks.
Peter wrote:
>Eeek! Dead right! All this time I was reading "CBC" for "CFB".
I don't see a contradiction here. If all inputs (password, IV and
plaintext) are identical, so will be the output; after all, the
algorithms are deterministic. (So this applies to CBC as well as CFB.)
Being deterministic as such is not considered a weakness AFAIK :-) ,
but I see the problem. It's nice that streaming modes provide a way
around this by chosing different IVs.
So we can say:
"CFB (same key, same IV) yields identical output for identical
input, and the plaintext XOR of the first non-identical block
can be recovered."
With no common prefix this yields Paul's answer, and ignoring the
second part yields Peter's.
[ Of course, one could also argue that chaining modes should be such
that subsequent data affects previous data, making the above
impossible. This is what David was probably getting at. However, in my
case it wouldn't work, as I'm looking at a dialogue-style
communications system, where answers need to be sent before the
communication ends. In other words, partial results need to be
encrypted and decrypted, before the subsequent data is even known.
Btw., in this setting, error recovery is also highly desirable, which
David's test-for-weakness in his recent posting in this thread would
not allow. ]
And now for something different: Also, one could relate the XOR one
one ciphertext-block to the XOR one the next. The first is the
input-differential of the block cipher, and the second the
output-differential XOR the two data values. This could probably be
used to mount a differential cryptanalysis using ciphertexts only
(rather than known plaintexts). (I suppose this would only work if
enough statistical properties about the plaintext XORs were known.)
Ahh, this is all interesting, but it still doesn't explain:
"If the IV in CFB is not unique, a cryptanalyst can
recover the corresponding plaintext." (AC2, p.201)
I understand this as:
"There is an attack that recovers the full plaintext from
known ciphertext in a reasonable amount of time."
(If more needed to be known, or the time was prohibitive, or it only
worked with some low probability, Bruce would probably have restricted
the claim accordingly.) So... How does it work? Where can I read more
about it?
Thanks,
Daniel
John Savard
part:
>why is encryption in CFB mode insecure, if you use the same
>initialization vector multiple times?
Well, CFB mode takes the IV, encrypts it, and XORs it with the first
block of your message.
So, if you use the same initialization vector multiple times, you are
sending multiple messages - which may have different beginnings - with
the same thing XORed to their first blocks. This is like using a
one-time pad twice, and can be solved by the same method, without
having to break the DES (or other block cipher) encryption at all.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
Paul Koning
>
> Daniel Vogelheim wrote:
> >
> > why is encryption in CFB mode insecure, if you use the same
> > initialization vector multiple times?
>
> beginnings are identical, thereby producing ciphertexts
> for an encryption system to reveal the fact that messages
> X and Y have the same beginning, even if the system doesn't
> reveal what that beginning is.
>
> If some convention in your plaintext guarantees that
> the first block of plaintext will be different every
> time, the system is as strong as the underlying block
> cipher, even with fixed IV. (Corrections, you other guys?)
No... And the reasoning is simpler than that.
CFB is a stream cypher, i.e., it generates a pseudorandom
bitstream which is XORed into the data. The bitstream
is fixed for a particular choice of key and IV.
So if you use the same IV twice, you use the same bitstream
twice. If the attacker has both cyphertexts, he can XOR them,
which cancels out the bitstream and gives him simply the XOR
of the two plaintexts. English language plaintext only has
a few bits of entropy per byte, so the XOR of two independent
English strings can be broken.
paul
SCOTT19U.ZIP_GUY
>Hello Peter and David,
>
>thanks for your quick responses. Just for background info: I ran
>across a crypto system that uses a hardcoded IV with CFB, that's why I
>am asking.
>
>
>Peter wrote:
>>beginnings are identical, thereby producing ciphertexts
>>whose beginnings are identical.
>
>plaintexts) isn't met in the aforementioned system.
>
>However, in the book (AC2) Schneier very clearly states:
>
> recover the corresponding plaintext."
>
>don't understand why this would be so.
>
>
>David wrote:
>>[...] but all the in vogue chaining mods are weak.
>>[...] However you can also like at ritters page or the FAQ.
>>http://www.rsa.com/rsalabs/faq/html/2-1-4.html
>
>I checked both, and neither mentions the particular problem of reusing
>(or even hardcoding) IVs, so I still don't know why this should be
>weak.
>
to a very high standard. As I stated before all the blessed chaining
modes are weak. It may have been that he meant OFB. Since that
is about the weakest mode there is. Since the output in OFB mode
is the same as if you used an OTP many times if you used the same
IV and this is a well known flaw. I could be wrong but I thought the old
PGP used OFB mode. Maybe this was done so that it would be weak.
However Mr B.S. reads the stuff here and since you paid for his book
he should anwser you.
Daniel Vogelheim
>CFB is a stream cypher, i.e., it generates a pseudorandom
>bitstream which is XORed into the data. The bitstream
>is fixed for a particular choice of key and IV.
No... You seem to be thinking of OFB. OFB mode uses the last
pseudorandom block as the new IV, CFB mode uses the last ciphertext
block as the new IV. So the CFB pseudorandom stream is dependent on
key, IV and message text.
>So if you use the same IV twice, you use the same bitstream
>twice. If the attacker has both cyphertexts, he can XOR them,
>which cancels out the bitstream and gives him simply the XOR
>of the two plaintexts. English language plaintext only has
>a few bits of entropy per byte, so the XOR of two independent
>English strings can be broken.
All correct for OFB, but it only works for the first (non-equal) block
of data in CFB. Cf the other posts in this thread.
As I mentioned before, Schneier says:
"If the IV in CFB is not unique, a cryptanalyst can
recover the corresponding plaintext." (AC2, p.201)
This indicates to me that a similar attack exists for CFB with same IV
as well, but the OFB-method above just doesn't work here.
Thanks for the response,
Daniel
AFN2...@afn.org
TINYSAFR and (soon) TINYSERP I have addressed this
problem by moving the filename from the DTA and putting
in (in caps) into the IV. So unless the file names are
the same, the IVs will be different.
--
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533