RE: ECB, CBC, CFB, OFB

>Somebody asked:
>>Can somebody more experienced than I am explain the strengths and weaknesses
>>of these encryption modes as applied to CAST, IDEA, DES, and Blowfish?
>
>>              ecb    Electronic codebook mode
>>                     c[i] = f1(K, p[i])
>>                     p[i] = f2(K, c[i])

This is the weakest mode. Patterns in the plain text tend to cause
repeated blocks in the output, causing some information leakage. This
mode is really only suitable if you have exactly one block or less to
encrypt or if random access at the block level is critical. An error in
the ciphertext or plaintext only affects one block, as long as bit count
integrity is maintained.

>>              cbc    Ciphertext block chaining mode
>>                     c[i] = f1(K, p[i]) ^ c[i-1]
>>                     p[i] = f2(K, c[i]) ^ c[i-1]

This is good at preventing information leakage. A one bit error in the
ciphertext causes a one block error in the plain text => reasonable
balance between tamper detection and error resistance. This mode is
commonly used.

>>              cfb    Ciphertext feeback mode
>>                     c[i] = f1(K, c[i-1]) ^ p[i]
>>                     p[i] = f1(K, c[i-1]) ^ c[i]

This is good at preventing information leakage. A one bit error in the
ciphertext causes a one bit error in the plain text => good for use in
high noise environments where error detection and correction is
(inexplicably) not used and tamper detection is not as critical. Doesn't
require a decryption mode, so a hash function like SHA1 could be used in
this mode instead of a general block cipher.

>>              ofb    Output feeback mode
>>                     h[i] = f1(K, h[i-1])
>>                     c[i] = p[i] ^ h[i]
>>                     p[i] = c[i] ^ h[i]

This mode essentially turns a block cipher into a stream cipher without
feedback. It must be used with the same caution as such a cipher. In
other words, the same stream should not be reused, but a new starting
point (initialization vector = h[-1]) and/or key should be chosen for
each message. No padding or data size expansion is necessary.

Several other modes are possible...

For really slow performance, you can try some kind of key feedback. :-)
   K[i] = K[i-1] ^ p[i-1]   or maybe   K[i] = e(K[i-1], K[i-2])
   c[i] = e(K[i], p[i])
   p[i] = d(K[i], c[i])
Caution: bizarre modes may not be well analyzed... although I think some
key feedback modes have merit when you are trying to slow an attacker
down. They might really mess up specialized cracking hardware. :-)

At 5:46 PM -0800 12/20/97, Johnson, Michael P (Mike) wrote:
>>Somebody asked:
>>>Can somebody more experienced than I am explain the strengths and weaknesses
>>>of these encryption modes as applied to CAST, IDEA, DES, and Blowfish?
>>
>>>              ecb    Electronic codebook mode
>>>                     c[i] = f1(K, p[i])
>>>                     p[i] = f2(K, c[i])
>
>This is the weakest mode. Patterns in the plain text tend to cause
>repeated blocks in the output, causing some information leakage. This
>mode is really only suitable if you have exactly one block or less to
>encrypt or if random access at the block level is critical. An error in
>the ciphertext or plaintext only affects one block, as long as bit count
>integrity is maintained.

It should be point out that ECB is also subject to some spoofing attacks.
Blocks from one message encoded with a particular key can be substituted
for blocks in a different message encoded with the same key.  In a banking
system, this attack might allow the attacker to change the transaction
amounts.

With any mode, encypherment is not a substitute for a message
authentication code.


-------------------------------------------------------------------------
Bill Frantz       | One party wants to control | Periwinkle -- Consulting
(408)356-8506     | what you do in the bedroom,| 16345 Englewood Ave.
frantz@netcom.com | the other in the boardroom.| Los Gatos, CA 95032, USA

At 06:46 PM 12/20/97 -0700, Johnson, Michael P (Mike) wrote:
>
>
>>>              cfb    Ciphertext feeback mode
>>>                     c[i] = f1(K, c[i-1]) ^ p[i]
>>>                     p[i] = f1(K, c[i-1]) ^ c[i]
>


Suppose instead of c[i-1] you use c[i-N] where N is say 10. 
How would you prove that this has no security implications?
That 10-way interleaved cfb streams are security-equivalent to
a single cfb stream interleaved with the immediately previous block?



------------------------------------------------------------
      David Honig                   Orbit Technology
     honig@otc.net                  Intaanetto Jigyoubu

"Windows 95 is a technologically complex product that is best left alone by
the government..."
 ---MSFT Atty B. Smith

>>>>>              cfb    Ciphertext feeback mode
>>>>>                     c[i] = f1(K, c[i-1]) ^ p[i]
>>>>>                     p[i] = f1(K, c[i-1]) ^ c[i]

>>Suppose instead of c[i-1] you use c[i-N] where N is say 10.

> Wouldn't the size of your IV have to grow as N grows?

Depends on your threat model; you could use the same IV for all c[i<1].
The main reason to do that sort of interleave is to simplify
parallelizing the hardware for speed while retaining
approximately the same security as regular CFB.

You might have some minor security gain because there's less
correlation between p[i] and p[i-N] than p[i-1],
so it's harder to guess things that might help,
but you might have a minor security loss because you're
only mushing together 1/N as much stuff, and you're
more likely to implement something incorrectly :-)


				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

At 11:10 AM -0600 12/22/97, David Honig wrote:
>At 06:46 PM 12/20/97 -0700, Johnson, Michael P (Mike) wrote:
>>
>>
>>>>              cfb    Ciphertext feeback mode
>>>>                     c[i] = f1(K, c[i-1]) ^ p[i]
>>>>                     p[i] = f1(K, c[i-1]) ^ c[i]
>>
>
>
>Suppose instead of c[i-1] you use c[i-N] where N is say 10.
>How would you prove that this has no security implications?
>That 10-way interleaved cfb streams are security-equivalent to
>a single cfb stream interleaved with the immediately previous block?
>
It's kind of obvious.  The encryption of a single plaintext stream
interleaved ten times is the same as the encryption of ten multiplexed
plaintexts.  If one is insecure, the other is insecure.

Bruce

**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis,MN  55419       Fax: 612-823-1590
                                            http://www.counterpane.com