The IV in Block Cipher CBC Mode (original) (raw)

ACiphers By Ritter Page

Can a non-crippie with a simple question get a simple authoritative answer on sci.crypt? Apparently not.

The Question

The conversation starts out with aquestionabout the need for protecting theIVin ablock cipher CBCmode. Various wrong answers ensue, with mathematical handwaves.

The Answer

The right answer is that an exposed IV might allow aman-in-the-middle (MITM) to change the IV value in-transit. Changing the IV changes only the decipheredplaintextfor the firstblock,without garbling the second block. Any or allbitsof the first block plaintext can be changed systematically with complete control.

In marked contrast, whenciphertextis changed in CBC mode, it does change the next block plaintext bit-for-bit, but it also garbles the plaintext for the current block (seediagram), and so is easily detected.

The Obvious Solution

The most obvious way to prevent deliberate MITM changes to the first block plaintext with the IV is to encipher the IV; that prevents an opponent from changing plaintext bits systematically.

Anothersuggestionavoids most IV problems by using a message number value known at both ends. Enciphering that value produces the same IV at each end, without transmission or potential exposure. That would of course also require some way to reset the message number to some random value in the beginning, and occasionally thereafter. Careful techniques might be required to maintain message number synchronization in any environment where messages might be lost.

If these solutions seem awkward or tricky, the alternatives are generally worse.

Authentication

The knee-jerk alternative is toauthenticatethe IV, probably along with the plaintext. (But note that the solutions given above do not require authentication.) Typically, plaintext authentication consists of ahashof the IV and data, with the result included in the enciphered message so that any change will be detected. In CBC mode it isnot sufficient to simply authenticate the ciphertext, because the IV is not ciphertext but is part of the mix. Unfortunately, authentication adds various complex issues of its own, including more message expansion, processinglatencyand potential "attacks" on authentication (that would be in addition toattacksonsecrecy).

The ideal IV is the usual (in cryptography) unknowablerandomvalue, but when that is impossible or expensive, even predictable values can be generally acceptable for CBC IV's, provided they are selected from among all possible values and that an MITM cannot change the IV without detection.

Authentication Problems

Aspointed outin the conversation, with authentication comes the possibility of attacks on the authentication (such as an opponent creating a message which appears valid), even though these attacks do notexpose the encrypted data. The particular authentication attack described capitalizes on an ability to delete the end of a CBC message without garbling anything before that. I call that a small block / CBC failure since it could not occur if the entire message effectively was just one large block.

A keyed message authentication code (MAC) could prevent such attacks. Or an unkeyed hash (such as CRC) could be enciphered prior to being enciphered again as part of the message. In either case, the opponent would have to know the key to create valid authentication value.

But if we are not to use a message until after it has been completely authenticated, we must first traverse the entire message to compute the authentication check. Thus, the message must be held unused until fully received and the check scan is complete. This is basically the same latency disadvantage as a message-size block, but without corresponding benefits like massive plaintextentropy.

Contents

Subject: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 05:21:05 -0400 From: "RDionysus" Encryptotron@hushmail.cox Message-ID: <999337089.220850@zver> Newsgroups: sci.crypt Lines: 43

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?

Now, if it does make good security sense to obfuscate the IV, how would I do this and still be able to convey it back to the program come file decryption time? Some initial ideas I had would be to maybe perform a simple XOR of the IV against the first 8 bytes of the actual encryption password and then append the result to the output as before. In a similar vein, I could perhaps run the IV string through RC4 (which will be in the program's library) using the Blowfish password. Either way would detract negligibly from program speed and accomplish the concealment of the IV. Any opinions? Am I just being overly paranoid? Any feedback would be greatly appreciated.

P.S.: A related side question: when implementing crypto routines that don't use an IV, is it a good idea to SALT passphrases? Like when using a block cipher in ECB mode or a stream cipher such as RC4? The random SALT value could then be stored in the cipher output in a fashion like the one described above? THANKS!

~~Rob

Subject: Re: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 07:31:04 -0700 From: "Scott Fluhrer" sfluhrer@ix.netcom.com Message-ID: 9mqsh6$a7m$1@slb2.atl.mindspring.net References: <999337089.220850@zver> Newsgroups: sci.crypt Lines: 98

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. Obvious question: why aren't you using an existing program, such as PGP or GPG?

I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

BTW: make sure that your PRNG generates a different IV each time.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....? I can't think of any academic results that suggest that obfuscating the IV actually gains you any security. As evidence that there should not be one, let us assume that there is, that is, given a totally unpredictable IV, the attacker has some advantage against the first plaintext block. Now, the CBC equation is:

C[0] = E( IV + P[0] )

(where + is exclusive-or, C[0] is the first ciphertext block, and P[0] is the first plaintext block). This is the only equation the IV appears in, and so the advantage must be against this equation. However, the second ciphertext block is computed as:

C[1] = E( C[0] + P[1] )

Now, C[0] is known to the attacker, and is totally unpredictable. Hence, any attack against the first equation can also be used against the second equation (and hence against the second plaintext block), and hence CBC would be vulnerable, even with a hidden IV.

Now, this isn't a formal proof -- I skipped by too many details -- but you can turn this argument into a proof. However, it does indicate that the IV should be unpredictable every time you encrypt a message -- keep that in mind when writing the code to generate it.

Now, if it does make good security sense to obfuscate the IV, how would I do this and still be able to convey it back to the program come file decryption time? Some initial ideas I had would be to maybe perform a simple XOR of the IV against the first 8 bytes of the actual encryption password and then append the result to the output as before. In a similar vein, I could perhaps run the IV string through RC4 (which will be in the program's library) using the Blowfish password. Either way would detract negligibly from program speed and accomplish the concealment of the IV. Any opinions? Am I just being overly paranoid? Any feedback would be greatly appreciated. You're being overly paranoid.

P.S.: A related side question: when implementing crypto routines that don't use an IV, is it a good idea to SALT passphrases? Like when using a block cipher in ECB mode or a stream cipher such as RC4? The random SALT value could then be stored in the cipher output in a fashion like the one described above? The most secure thing you can do with ECB is not use it. For stream ciphers in general, it is essential that you salt any passphrase you will use the encrypt two different plaintexts. As for the specific case of RC4, you need to be careful how you salt it -- the obvious approach of concatinating the salt with the key turns out to be weak. I personally recommend that you hash the two together, and turn discard the first 256 bytes of RC4 output before using it to encrypt the file.

-- poncho

Subject: Re: BIG question about using and storing IV's Date: Sat, 01 Sep 2001 18:58:19 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b912fbb.526473@netnews.att.net References: 9mqsh6$a7m$1@slb2.atl.mindspring.net Newsgroups: sci.crypt Lines: 78

On Sat, 1 Sep 2001 07:31:04 -0700, in 9mqsh6$a7m$1@slb2.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. Obvious question: why aren't you using an existing program, such as PGP or GPG?

I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

BTW: make sure that your PRNG generates a different IV each time.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....? I can't think of any academic results that suggest that obfuscating the IV actually gains you any security. As evidence that there should not be one, let us assume that there is, that is, given a totally unpredictable IV, the attacker has some advantage against the first plaintext block. Now, the CBC equation is:

C[0] = E( IV + P[0] )

(where + is exclusive-or, C[0] is the first ciphertext block, and P[0] is the first plaintext block). This is the only equation the IV appears in, and so the advantage must be against this equation. However, the second ciphertext block is computed as:

C[1] = E( C[0] + P[1] )

Now, C[0] is known to the attacker, and is totally unpredictable. Hence, any attack against the first equation can also be used against the second equation (and hence against the second plaintext block), and hence CBC would be vulnerable, even with a hidden IV.

Typically, math results may not mean what one thinks they mean.

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

One can imagine cases where a dollar value might occur in the first block, and thus be vulnerable to change. Any real cipher system probably should have a higher-level authentication scheme that would catch such a change. But even some forms of authentication may miss the change in the IV and first-block plaintext, because none of the ciphertext will have changed.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 12:22:37 -0700 From: "Scott Fluhrer" sfluhrer@ix.netcom.com Message-ID: 9mrdjl$aem$1@slb7.atl.mindspring.net References: 3b912fbb.526473@netnews.att.net Newsgroups: sci.crypt Lines: 107

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote in message news:3b912fbb.526473@netnews.att.net...

On Sat, 1 Sep 2001 07:31:04 -0700, in 9mqsh6$a7m$1@slb2.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. Obvious question: why aren't you using an existing program, such as PGP or GPG?

I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

BTW: make sure that your PRNG generates a different IV each time.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....? I can't think of any academic results that suggest that obfuscating the IV actually gains you any security. As evidence that there should not be one, let us assume that there is, that is, given a totally unpredictable IV, the attacker has some advantage against the first plaintext block. Now, the CBC equation is:

C[0] = E( IV + P[0] )

(where + is exclusive-or, C[0] is the first ciphertext block, and P[0] is the first plaintext block). This is the only equation the IV appears in, and so the advantage must be against this equation. However, the second ciphertext block is computed as:

C[1] = E( C[0] + P[1] )

Now, C[0] is known to the attacker, and is totally unpredictable. Hence, any attack against the first equation can also be used against the second equation (and hence against the second plaintext block), and hence CBC would be vulnerable, even with a hidden IV.

Typically, math results may not mean what one thinks they mean.

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

CBC is designed to provide privacy, not integrity. If you want integrity (and you usually do), use something that is designed to provide that guarrantee, such as a MAC.

One can imagine cases where a dollar value might occur in the first block, and thus be vulnerable to change. Any real cipher system probably should have a higher-level authentication scheme that would catch such a change. But even some forms of authentication may miss the change in the IV and first-block plaintext, because none of the ciphertext will have changed.

And use the MAC intellegently -- authenticate everything used to form the plaintext in the MAC. This is well known...

-- poncho

Subject: Re: BIG question about using and storing IV's Date: Sat, 01 Sep 2001 20:11:19 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b9140d9.4908473@netnews.att.net References: 9mrdjl$aem$1@slb7.atl.mindspring.net Newsgroups: sci.crypt Lines: 131

On Sat, 1 Sep 2001 12:22:37 -0700, in 9mrdjl$aem$1@slb7.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote in message news:3b912fbb.526473@netnews.att.net...

On Sat, 1 Sep 2001 07:31:04 -0700, in 9mqsh6$a7m$1@slb2.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. Obvious question: why aren't you using an existing program, such as PGP or GPG?

I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

BTW: make sure that your PRNG generates a different IV each time.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ whether ^^^^^^^^ or ^^^^^^ not a public IV can compromise the overall security of the code or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....? I can't think of any academic results that suggest that obfuscating the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IV ^^^ actually gains you any security. As evidence that there should not be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one, let us assume that there is, that is, given a totally unpredictable IV, the attacker has some advantage against the first plaintext block. Now, the CBC equation is:

C[0] = E( IV + P[0] )

(where + is exclusive-or, C[0] is the first ciphertext block, and P[0] is the first plaintext block). This is the only equation the IV appears in, and so the advantage must be against this equation. However, the second ciphertext block is computed as:

C[1] = E( C[0] + P[1] )

Now, C[0] is known to the attacker, and is totally unpredictable. Hence, any attack against the first equation can also be used against the second equation (and hence against the second plaintext block), and hence CBC would be vulnerable, even with a hidden IV.

Typically, math results may not mean what one thinks they mean.

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

CBC is designed to provide privacy, not integrity. If you want integrity (and you usually do), use something that is designed to provide that guarrantee, such as a MAC.

The problem, however, is the exposure of the CBC IV, just as the original question suggested.

One can imagine cases where a dollar value might occur in the first block, and thus be vulnerable to change. Any real cipher system probably should have a higher-level authentication scheme that would catch such a change. But even some forms of authentication may miss the change in the IV and first-block plaintext, because none of the ciphertext will have changed.

And use the MAC intellegently -- authenticate everything used to form the plaintext in the MAC. This is well known...

I'm sorry, but that is just not an acceptable excuse.

The question was: "Could there be a problem with exposing the IV?"

Your response was: "No, and here's why."

The correct answer was: "Possibly, and here's how."

Your math approach was insufficient, your conclusions were wrong, and your advice was also wrong.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 13:51:04 -0700 From: "Scott Fluhrer" sfluhrer@ix.netcom.com Message-ID: 9mriph$bda$1@slb0.atl.mindspring.net References: 3b9140d9.4908473@netnews.att.net Newsgroups: sci.crypt Lines: 177

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote in message news:3b9140d9.4908473@netnews.att.net...

On Sat, 1 Sep 2001 12:22:37 -0700, in 9mrdjl$aem$1@slb7.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote in message news:3b912fbb.526473@netnews.att.net...

On Sat, 1 Sep 2001 07:31:04 -0700, in 9mqsh6$a7m$1@slb2.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru (although I am a crypto "buff", whatever the hell that means). So maybe somebody could help me with a few relatively basic questions. I am writing an encryption/file security program that will utilize various algorithms and routines. Obvious question: why aren't you using an existing program, such as PGP or GPG?

I am currently implementing a routine that uses Blowfish in CBC mode to encrypt data. As it currently stands, my method is as follows: after the requisite key-initialization sequence, the Encrypt function recieves a plaintext .string and an 8-byte Initialization Vector string (IV) [which will be generated on the fly with a PRNG], performs the encryption, and appends the IV to the beginning of the ciphertext output string. The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

BTW: make sure that your PRNG generates a different IV each time.

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ whether ^^^^^^^^ or ^^^^^^ not a public IV can compromise the overall security of the code or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....? I can't think of any academic results that suggest that obfuscating the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IV ^^^

actually gains you any security. As evidence that there should not be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one, let us assume that there is, that is, given a totally unpredictable IV, the attacker has some advantage against the first plaintext block. Now, the CBC equation is:

C[0] = E( IV + P[0] )

(where + is exclusive-or, C[0] is the first ciphertext block, and P[0] is the first plaintext block). This is the only equation the IV appears in, and so the advantage must be against this equation. However, the second ciphertext block is computed as:

C[1] = E( C[0] + P[1] )

Now, C[0] is known to the attacker, and is totally unpredictable. Hence, any attack against the first equation can also be used against the second equation (and hence against the second plaintext block), and hence CBC would be vulnerable, even with a hidden IV.

Typically, math results may not mean what one thinks they mean.

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

CBC is designed to provide privacy, not integrity. If you want integrity (and you usually do), use something that is designed to provide that guarrantee, such as a MAC.

The problem, however, is the exposure of the CBC IV, just as the original question suggested.

One can imagine cases where a dollar value might occur in the first block, and thus be vulnerable to change. Any real cipher system probably should have a higher-level authentication scheme that would catch such a change. But even some forms of authentication may miss the change in the IV and first-block plaintext, because none of the ciphertext will have changed.

And use the MAC intellegently -- authenticate everything used to form the plaintext in the MAC. This is well known...

I'm sorry, but that is just not an acceptable excuse.

The question was: "Could there be a problem with exposing the IV?"

Your response was: "No, and here's why."

The correct answer was: "Possibly, and here's how."

Your math approach was insufficient, your conclusions were wrong, and your advice was also wrong.

You are right. My approach analyzed only privacy, not integrety. And, in this very specific scenario, hiding the IV helps:

In that particular scenario, you are right. My apologies...

[1] The only good reason I know not to use a MAC (message expansion is intolerable) does not seem to apply, as you're already adding an IV.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Sun, 02 Sep 2001 01:38:05 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b918c3f.3902831@news.powersurfr.com References: 3b912fbb.526473@netnews.att.net Newsgroups: sci.crypt Lines: 28

On Sat, 01 Sep 2001 18:58:19 GMT, ritter@ciphersbyNOSPAMritter.com (Terry Ritter) wrote, in part:

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

This is generally overlooked, because the IV being visible doesn't create a security problem in the specific sense people are looking for security problems: it doesn't help someone to read the plaintext.

You are correct that since the IV has no corresponding plaintext, an active attacker can alter it without detection - and will be able to change the first block of the message at random.

However, an active attacker can also alter a block in the middle of the message - and the only difference will be, now, that the attacker is only able to alter two consecutive blocks at random, never just one block.

It may be that garbling one block is a problem, while garbling two blocks is detectable, but that involves very specific assumptions about the kinds of messages being sent.

John Savard http://home.ecn.ab.ca/~jsavard/index.html http://plaza.powersurfr.com/jsavard/other/slrint.htm

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 04:46:09 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n1mah$ojs$2@agate.berkeley.edu References: 3b912fbb.526473@netnews.att.net Newsgroups: sci.crypt Lines: 11

Terry Ritter wrote:

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection. But such an expectation is completely unfounded. CBC mode is very good at providing secrecy, but one should never make the mistake of assuming it provides any integrity. If you need integrity guarantees, use a MAC.

Subject: Re: BIG question about using and storing IV's Date: Tue, 04 Sep 2001 05:50:06 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b946850.3849296@netnews.att.net References: 9n1mah$ojs$2@agate.berkeley.edu Newsgroups: sci.crypt Lines: 61

On Tue, 4 Sep 2001 04:46:09 +0000 (UTC), in 9n1mah$ojs$2@agate.berkeley.edu, in sci.crypt daw@mozart.cs.berkeley.edu (David Wagner) wrote:

Terry Ritter wrote:

There is a well-known (though apparently not all that well-known) first-block security problem in CBC when the IV is sent or stored along with the ciphertext: If an opponent can change the IV, he or she can also change the recovered plaintext for the first block.

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection. But such an expectation is completely unfounded. CBC mode is very good at providing secrecy, but one should never make the mistake of assuming it provides any integrity. If you need integrity guarantees, use a MAC.

OK, let's just go back to the original message:

"Hello folks. I am a computer programmer by trade, not a mathematician or a cryptography guru [...]. So maybe somebody could help me with a few relatively basic questions." [...] "My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?"

So the guy doesn't know from crypto, and your response is that he should know about "integrity guarantees" and the use of MAC's beyond ciphering itself. But if he knew crypto to that level, he wouldn't have asked for help, now would he?

The potential exposure of the first block to MITM alteration is a fundamental issue in understanding CBC. It represents an unexpected weakness specifically because at first glance the rest of the message is exposed in a similar way. That is of course false reasoning, something one might expect to get considerable attention, since other issues, reasoned in similar mathematical handwaves, may be similarly false. The issue is also a natural part of CBC mode itself, and not something for discussion elsewhere.

The potential exposure of the first block to alteration does not deserve to be swept under the rug of a particular problem classification, as in "that's not a CBC problem." It is a CBC problem if you want to use CBC; it is only not a CBC problem if all you want to do is talk about the chapter on block cipher modes before you get to the chapter on authentication. It is a real problem that must be understood and then actually addressed and possibly fixed in real systems.

It is true that, if one lucks out, there may be no exposure even without considering the issue. But luck is hardly the same as correct cryptosystem design, now is it?

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: 4 Sep 2001 10:28:15 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: slrn9p9b5u.2tr.mdw@daryl.nsict.org References: 3b946850.3849296@netnews.att.net Newsgroups: sci.crypt Lines: 83

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote:

daw@mozart.cs.berkeley.edu (David Wagner) wrote:

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection. But such an expectation is completely unfounded. CBC mode is very good at providing secrecy, but one should never make the mistake of assuming it provides any integrity. If you need integrity guarantees, use a MAC.

So the guy doesn't know from crypto, and your response is thats he should know about "integrity guarantees" and the use of MAC's beyond ciphering itself. But if he knew crypto to that level, he wouldn't have asked for help, now would he?

But /you/ ought to know better. And the response, as I read it, wasn't that /he/ should know about integrity guarantees, but that /you/ should.

The potential exposure of the first block to MITM alteration is a fundamental issue in understanding CBC. It represents an unexpected weakness specifically because at first glance the rest of the message is exposed in a similar way. That is of course false reasoning, something one might expect to get considerable attention, since other issues, reasoned in similar mathematical handwaves, may be similarly false. The issue is also a natural part of CBC mode itself, and not something for discussion elsewhere.

Completely false. I'm not aware of a single symmetric encryption scheme from before a couple of years ago (i.e., before Jutla's IACBC and IAPM) which provided security against chosen ciphertext attacks. Blaming CBC mode in particular for these shortcomings is thoroughly unjustified. It's a well-known, and obvious, property of, for example, XOR-mixed stream ciphers (e.g., RC4, block ciphers in counter mode), block cipher OFB and CFB modes, ...

The potential exposure of the first block to alteration does not deserve to be swept under the rug of a particular problem classification, as in "that's not a CBC problem."

It's certainly not a fearure specific to CBC, since it's applicable to many other symmetric ciphers. If you want protection from chosen ciphertext attacks, or (relatedly) integrity guarantees then you need to do something more clever (e.g., attach a MAC tag to the ciphertext, or use an integrity-aware encryption mode).

It is a CBC problem if you want to use CBC;

See above: you can make similar claims `It is a foo problem if you want to use foo' for so many other values of foo that it starts to look like a problem for a large class of symmetric encryption schemes.

I don't deny at all that it's a problem. In fact, I think I probably take it more seriously than you do. I consider that the entire of a CBC-encrypted ciphertext is vulnerable to chosen-ciphertext attack. I believe that the problem extends much further than simply block ciphers in CBC mode. I don't want to use an encryption scheme which isn't NM-CCA for communication over an insecure network.

I think Phil Rogaway's point, that integrity-aware encryption modes such as OCB or IAPM are a good thing because they help prevent novices from making these sorts of mistakes, is extremely well-made. And, as he points out, resistance to chosen-ciphertext attacks is something we've been demanding from /public-key/ systems for a long time now.

(It's a shame that the brave new world of IA modes is turning into a patent quagmire. But enough about that.)

it is only not a CBC problem if all you want to do is talk about the chapter on block cipher modes before you get to the chapter on authentication. It is a real problem that must be understood and then actually addressed and possibly fixed in real systems.

I cover authentication first. ;-) (It works out easier that way around. For a start, the definitions are simpler. You also don't need to come back to encryption when you want to show that applying a SUF-CMA MAC tag to an IND-CPA ciphertext renders the system as a whole NM-CCA.)

It is true that, if one lucks out, there may be no exposure even without considering the issue. But luck is hardly the same as correct cryptosystem design, now is it?

Agreed. Convergeance at last? ;-)

-- [mdw]

Subject: Re: BIG question about using and storing IV's Date: Wed, 05 Sep 2001 12:54:02 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b961e29.2755080@news.powersurfr.com References: 3b946850.3849296@netnews.att.net Newsgroups: sci.crypt Lines: 49

On Tue, 04 Sep 2001 05:50:06 GMT, ritter@ciphersbyNOSPAMritter.com (Terry Ritter) wrote, in part:

The potential exposure of the first block to alteration does not deserve to be swept under the rug of a particular problem classification, as in "that's not a CBC problem." It is a CBC problem if you want to use CBC; it is only not a CBC problem if all you want to do is talk about the chapter on block cipher modes before you get to the chapter on authentication. It is a real problem that must be understood and then actually addressed and possibly fixed in real systems.

I am sympathetic to this point of view in general.

For example, in a post where I was - as it turned out - explaining the concept of decorrelation, I was criticized because my example involved removing the vulnerability of the OTP to the "bit-flipping" attack.

In this specific case, in CBC mode, the vulnerability you have identified allows an adversary to garble the first block without detection. As is well known, CBC mode allows the adversary to garble any two consecutive blocks, or any group of more than two consecutive blocks, within the message without detection (that is, without garbling the rest of the message).

So I can't be too amazed that this particular vulnerability is sometimes dismissed as unworthy of notice. However, it should be noted if the error-propagation properties of CBC mode are described precisely. Usually, though, it will be done implicitly, by considering the IV as part of the message.

Incidentally, when I commented on my intuition that the Shamir three-pass protocol seems to require the same mathematics as public-key cryptography, you suggested I try to prove it. Well, I finally took up that challenge; I don't have a complete proof, but I have results that are about as good as much else of what we know about public-key cryptography (i.e., we don't know if RSA is as secure as factoring, and we don't know if factoring is secure). This has led to some postings: first in sci.crypt, in the thread "Conditions for the Three-Pass Protocol", and then taken even further, a post of mine in sci.crypt.research.

I couldn't easily find it, though, but I still strongly suspect "my" results were already in the literature. Just in case, though, I thought I had better present them.

John Savard http://home.ecn.ab.ca/~jsavard/index.html

Subject: Re: BIG question about using and storing IV's Date: Wed, 05 Sep 2001 19:25:13 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b967bd2.3546623@netnews.att.net References: 3b961e29.2755080@news.powersurfr.com Newsgroups: sci.crypt Lines: 108

On Wed, 05 Sep 2001 12:54:02 GMT, in 3b961e29.2755080@news.powersurfr.com, in sci.crypt jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) wrote:

On Tue, 04 Sep 2001 05:50:06 GMT, ritter@ciphersbyNOSPAMritter.com (Terry Ritter) wrote, in part:

The potential exposure of the first block to alteration does not deserve to be swept under the rug of a particular problem classification, as in "that's not a CBC problem." It is a CBC problem if you want to use CBC; it is only not a CBC problem if all you want to do is talk about the chapter on block cipher modes before you get to the chapter on authentication. It is a real problem that must be understood and then actually addressed and possibly fixed in real systems.

I am sympathetic to this point of view in general.

For example, in a post where I was - as it turned out - explaining the concept of decorrelation, I was criticized because my example involved removing the vulnerability of the OTP to the "bit-flipping" attack.

In this specific case, in CBC mode, the vulnerability you have identified allows an adversary to garble the first block without detection. As is well known, CBC mode allows the adversary to garble any two consecutive blocks, or any group of more than two consecutive blocks, within the message without detection (that is, without garbling the rest of the message).

It appears that you have yet to come to grips with the issue: In CBC there is a distinction between the first block and the rest:

The plaintext recovered for the first block can be precisely changed, bit-for-bit (by changing the transmitted IV) without also garbling another block. When properly done, the recovered plaintext will look fine. That is a Man-In-The-Middle (MITM) opportunity.

Any other block also can be changed bit-for-bit (by changing the ciphertext), but doing that will also hopelessly garble the earlier block. There is no way to do that properly, so it is no MITM opportunity at all.

| plaintext | P[0]e P[1]e | | | | IVe -> + --> + | | | | | | | E (encipher) | E | | | | | | v C[0]e --------> C[1]e ---> | ciphertext transport | | C[0]d --------> C[1]d ---> | | | | | | | D (decipher) | D | v | | | | IVd -> + --> + | | | | P[0]d P[1]d | recovered plaintext | | Here plaintext blocks P[n] are XORed with IV (or the | previous ciphertext block C[n-1]) and then Enciphered. | The possibly-changed ciphertext is Deciphered, Xored, | and returned as Plaintext.
| From the diagram, changing a bit in IVd changes a bit in | P[0]d AND NOTHING ELSE. In contrast, changing one bit in | C[0]d does change one bit in P[1]d, but ALSO changes half | the bits in P[0]d in an uncontrollable way.

There are three distinct cases: the usual case, plus two end conditions. At the front end, an MITM with access to the IV can change the first block at will, without garbling other plaintext, something which cannot be done in the usual case. So the first block is not just the first occurrence of the common situation. And anybody who sees just one case here also has not seen the problem.

So I can't be too amazed that this particular vulnerability is sometimes dismissed as unworthy of notice. However, it should be noted if the error-propagation properties of CBC mode are described precisely. Usually, though, it will be done implicitly, by considering the IV as part of the message.

What? The IV value probably will not exist at the plaintext level, only being selected for entry into the block cipher, which does not usually authenticate as it ciphers.

One solution is to hash the plaintext, which does of course further expand the message by the size of the digest (which was already expanded by the IV). That also means we cannot trust the plaintext until we get to the end and check the digest. So we have to buffer the whole received message before we can use it, unless we set up some plaintext packet structure with individual hashing for our own use.

Note that many of these irritating details are specifically due to the "mode of operation" necessary for conventional small-block cipher use (including AES). The main purpose of CBC is to "whiten" the data block distribution so the codebook is less vulnerable to plaintext repeats. In contrast, a truly large data block should contain sufficient entropy to not need whitening, and such a cipher can be operated safely as ECB without IV and without IV expansion.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Wed, 5 Sep 2001 20:01:00 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n609s$2nha$1@agate.berkeley.edu References: 3b967bd2.3546623@netnews.att.net Newsgroups: sci.crypt Lines: 11

Terry Ritter wrote:

Any other block also can be changed bit-for-bit (by changing the ciphertext), but doing that will also hopelessly garble the earlier block. There is no way to do that properly, so it is no MITM opportunity at all.

Your last statement does not follow. There are plenty of applications where ability to change a middle block is sufficient to break security, despite the garbling of the subsequent block. In fact, CBC should never be assumed to provide integrity protection. If you need integrity, you should always use a MAC.

Subject: Re: BIG question about using and storing IV's Date: Wed, 05 Sep 2001 23:13:24 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b96b140.17226392@netnews.att.net References: 9n609s$2nha$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 57

On Wed, 5 Sep 2001 20:01:00 +0000 (UTC), in 9n609s$2nha$1@agate.berkeley.edu, in sci.crypt daw@mozart.cs.berkeley.edu (David Wagner) wrote:

Terry Ritter wrote:

Any other block also can be changed bit-for-bit (by changing the ciphertext), but doing that will also hopelessly garble the earlier block. There is no way to do that properly, so it is no MITM opportunity at all.

Your last statement does not follow. There are plenty of applications where ability to change a middle block is sufficient to break security, despite the garbling of the subsequent block. In fact, CBC should never be assumed to provide integrity protection. If you need integrity, you should always use a MAC.

OK, how about: "There is no way to do that properly, so it is almost no MITM opportunity at all, and certainly nothing comparable to the almost effortless MITM investment of the first block security problem." But you already knew that, didn't you?

This thread was started by someone who did not know about crypto. The question was something like: "Can CBC have a security problem when the IV is exposed." The early answers, with appropriate math handwaves, were: "No." Those were wrong, the math was faulty, yet we heard nothing from you.

This thread also shows how math handwaves don't work. But math which attempts to be both precise and complete probably cannot be debugged by the rest of us. So, in general, only mathematicians can trust math results, and even they may be wrong. The obvious implication is that nobody can trust math results to cryptographic levels of assurance.

When you finally did get around to an answer, no doubt seeing an opportunity to prove me wrong (since you had no comment about the larger implications of bad math used to support an argument), your answer was "No:"

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection.

But the guy explicitly said he did not know crypto, so your assumption that he had any "expectations" at all about CBC mode was at least inattentive to the problem statement.

The right answer, with which you apparently now agree, is: "Yes." But that is no correction, since it is the answer I gave from the start.

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 01:29:51 +0200 From: "Dabiker" dabiker@singularity.no Message-ID: Dryl7.20665$rZ3.59282@news1.bredband.com References: 3b96b140.17226392@netnews.att.net Newsgroups: sci.crypt Lines: 77

Someone told me that you should have knowledge about transpositional ciphers.

So now my question to you would be if a string of text is first XOR with a key that is greater or equal to 256 bite, and then used to create a unique 256-bit transpositional outputpad for the already XOR bits, and before the next block was worked on the XOR was rotated to a value of the first byte of the key.

Would such a cipher really be possible to attack because to my mind the output would be no less no more then a random string of bits.

If you know how could you be so kind to explain how?

Wave "Terry Ritter" ritter@ciphersbyNOSPAMritter.com wrote in message news:3b96b140.17226392@netnews.att.net...

On Wed, 5 Sep 2001 20:01:00 +0000 (UTC), in 9n609s$2nha$1@agate.berkeley.edu, in sci.crypt daw@mozart.cs.berkeley.edu (David Wagner) wrote:

Terry Ritter wrote:

Any other block also can be changed bit-for-bit (by changing the ciphertext), but doing that will also hopelessly garble the earlier block. There is no way to do that properly, so it is no MITM opportunity at all.

Your last statement does not follow. There are plenty of applications where ability to change a middle block is sufficient to break security, despite the garbling of the subsequent block. In fact, CBC should never be assumed to provide integrity protection. If you need integrity, you should always use a MAC.

OK, how about: "There is no way to do that properly, so it is almost no MITM opportunity at all, and certainly nothing comparable to the almost effortless MITM investment of the first block security problem." But you already knew that, didn't you?

This thread was started by someone who did not know about crypto. The question was something like: "Can CBC have a security problem when the IV is exposed." The early answers, with appropriate math handwaves, were: "No." Those were wrong, the math was faulty, yet we heard nothing from you.

This thread also shows how math handwaves don't work. But math which attempts to be both precise and complete probably cannot be debugged by the rest of us. So, in general, only mathematicians can trust math results, and even they may be wrong. The obvious implication is that nobody can trust math results to cryptographic levels of assurance.

When you finally did get around to an answer, no doubt seeing an opportunity to prove me wrong (since you had no comment about the larger implications of bad math used to support an argument), your answer was "No:"

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection.

But the guy explicitly said he did not know crypto, so your assumption that he had any "expectations" at all about CBC mode was at least inattentive to the problem statement.

The right answer, with which you apparently now agree, is: "Yes." But that is no correction, since it is the answer I gave from the start.

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 03:48:46 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b96f202.5187835@netnews.att.net References: Dryl7.20665$rZ3.59282@news1.bredband.com Newsgroups: sci.crypt Lines: 88

On Thu, 6 Sep 2001 01:29:51 +0200, in Dryl7.20665$rZ3.59282@news1.bredband.com, in sci.crypt "Dabiker" dabiker@singularity.no wrote:

Someone told me that you should have knowledge about transpositional ciphers.

So now my question to you would be if a string of text is first XOR with a key that is greater or equal to 256 bite, and then used to create a unique 256-bit transpositional outputpad for the already XOR bits, and before the next block was worked on the XOR was rotated to a value of the first byte of the key.

Would such a cipher really be possible to attack because to my mind the output would be no less no more then a random string of bits.

If you know how could you be so kind to explain how?

Many constructions at first look much more complex than they turn out to be after detailed examination. On the other hand, bit-permutation can be a very strong technique.

We know a lot about correct algorithms for bit-permutation, and we know how much information they need to select one out of all possible permutations. For 256-bit blocks, we need to first select one of 256, then one of the remaining 255, then one of the remaining 254 and so on. So there are 256 factorial choices, and we need to select each with the same probability. A key of 256 random bytes should be large enough, but I usually throw bits away while getting the exact ranges needed, so I use somewhat more. It is possible to be more conservative, but that is not necessarily better.

The idea of XORing the data before permutation is basically right. Of course, for 256 bits of data we only need 32 bytes of key. But if the key array is random, then the data will be randomized or whitened, which should give a good distribution of 1's and 0's, which is best for bit-permutation.

Simply rotating the key to do the next block is not so good, because it means that a strong, simple and direct relationship will exist in the ciphering applied to adjacent blocks. Even though I don't know how to exploit that weakness, I know the weakness exists and presume that someone could exploit it. There will of course always be some form of relationship, but we don't have to make that easy.

I have been building and discussing bit-permutation ciphers (among many others) for more than a decade. First we have the most recent sci.crypt article:

http://www.ciphersbyritter.com/ARTS/DYNTRAGN.HTM

Then the earlier rather disturbing sci.crypt discussion:

http://www.ciphersbyritter.com/NEWS5/REDYNTRN.HTM

And the 1991 ink-on-paper original:

http://www.ciphersbyritter.com/ARTS/DYNTRAN2.HTM

The combination of bit-balancing, bit-shuffling, and different permutations for each block may have been new to open cryptography a decade ago. But the more interesting part of this is the general lack of academic enthusiasm for techniques based on Shannon-style Perfect Secrecy:

With exact bit-balance and a random key, every possible plaintext block is a guaranteed equally-probable possibility for any ciphertext block. In practice, we have to use a machine-produced key, with a lighter guarantee (if any), but numerous techniques for making and using serious stream cipher keystreams are available in the open literature.

When a plethora of different keys take the exact same plaintext to the exact same ciphertext, even known-plaintext does not reveal the ciphering transformation, which is a tremendous advantage. For if the opponent cannot distinguish the ciphering transformation, there would seem to be very little to work with in an attack.

Without substitution tables, there are no weak tables. There is no mixing and so no weak mixing. There are no differential or linear ciphering relationships. And there are no rounds to be peeled off. These are rather interesting characteristics.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 06:32:11 +0200 From: "Dabiker" dabiker@singularity.no Message-ID: 4TCl7.20812$rZ3.59480@news1.bredband.com References: 3b96f202.5187835@netnews.att.net Newsgroups: sci.crypt Lines: 124

Thank you for your most educating and even for me understandable answer.

Peoples said top post was no good idea so i ask you soom questions further down "Terry Ritter" ritter@ciphersbyNOSPAMritter.com wrote in message news:3b96f202.5187835@netnews.att.net...

On Thu, 6 Sep 2001 01:29:51 +0200, in Dryl7.20665$rZ3.59282@news1.bredband.com, in sci.crypt "Dabiker" dabiker@singularity.no wrote:

Someone told me that you should have knowledge about transpositional ciphers.

So now my question to you would be if a string of text is first XOR with a key that is greater or equal to 256 bite, and then used to create a unique 256-bit transpositional outputpad for the already XOR bits, and before the next block was worked on the XOR was rotated to a value of the first byte of the key.

Would such a cipher really be possible to attack because to my mind the output would be no less no more then a random string of bits.

If you know how could you be so kind to explain how?

Many constructions at first look much more complex than they turn out to be after detailed examination. On the other hand, bit-permutation can be a very strong technique.

We know a lot about correct algorithms for bit-permutation, and we know how much information they need to select one out of all possible permutations. For 256-bit blocks, we need to first select one of 256, then one of the remaining 255, then one of the remaining 254 and so on. So there are 256 factorial choices, and we need to select each with the same probability. A key of 256 random bytes should be large enough, but I usually throw bits away while getting the exact ranges needed, so I use somewhat more. It is possible to be more conservative, but that is not necessarily better.

The idea of XORing the data before permutation is basically right. Of course, for 256 bits of data we only need 32 bytes of key. My idea of permutations i would guess is not mainstream, that's why i want your oppinion abut it If we suppose i have a keystream 3 byte 24bits Examle: 11,6,23 My swapad would look like this 11, 6 , 21 , 11+1 , 6+1 , 21+1 , 11+2 , 6+2 , 21+2 and so on if x>24 x=0 and if swappad occupied i just add one until a free position. This will indeed give a unique swappad for each password but i guess it's not ideal, is it a better way to do this?

And just another little question i really can't see why rotation of the key to XOR with would be bad, because if not rotaded the distribution of the swap would be linear but if rotated it seem to me like you hide the fact that the distribution of swaps is linear between the blocks, is this just plain wrong. I was thinking of using each byte in key to rotate it at bitlevel.

Another thought that i decided not to do was to add positions to the pads by reading the key 4 bite at a time. But since javascript not the fastest language on earth, that would be heavy and take time. What do you think?

But if

the key array is random, then the data will be randomized or whitened, which should give a good distribution of 1's and 0's, which is best for bit-permutation.

Simply rotating the key to do the next block is not so good, because it means that a strong, simple and direct relationship will exist in the ciphering applied to adjacent blocks. Even though I don't know how to exploit that weakness, I know the weakness exists and presume that someone could exploit it. There will of course always be some form of relationship, but we don't have to make that easy.

I have been building and discussing bit-permutation ciphers (among many others) for more than a decade. First we have the most recent sci.crypt article:

http://www.ciphersbyritter.com/ARTS/DYNTRAGN.HTM

Then the earlier rather disturbing sci.crypt discussion:

http://www.ciphersbyritter.com/NEWS5/REDYNTRN.HTM

And the 1991 ink-on-paper original:

http://www.ciphersbyritter.com/ARTS/DYNTRAN2.HTM

The combination of bit-balancing, bit-shuffling, and different permutations for each block may have been new to open cryptography a decade ago. But the more interesting part of this is the general lack of academic enthusiasm for techniques based on Shannon-style Perfect Secrecy:

With exact bit-balance and a random key, every possible plaintext block is a guaranteed equally-probable possibility for any ciphertext block. In practice, we have to use a machine-produced key, with a lighter guarantee (if any), but numerous techniques for making and using serious stream cipher keystreams are available in the open literature.

When a plethora of different keys take the exact same plaintext to the exact same ciphertext, even known-plaintext does not reveal the ciphering transformation, which is a tremendous advantage. For if the opponent cannot distinguish the ciphering transformation, there would seem to be very little to work with in an attack.

Without substitution tables, there are no weak tables. There is no mixing and so no weak mixing. There are no differential or linear ciphering relationships. And there are no rounds to be peeled off. These are rather interesting characteristics.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 06:52:28 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b971cd8.16155346@netnews.att.net References: 4TCl7.20812$rZ3.59480@news1.bredband.com Newsgroups: sci.crypt Lines: 85

On Thu, 6 Sep 2001 06:32:11 +0200, in 4TCl7.20812$rZ3.59480@news1.bredband.com, in sci.crypt "Dabiker" dabiker@singularity.no wrote:

[...] My idea of permutations i would guess is not mainstream, that's why i want your oppinion abut it If we suppose i have a keystream 3 byte 24bits Examle: 11,6,23 My swapad would look like this 11, 6 , 21 , 11+1 , 6+1 , 21+1 , 11+2 , 6+2 , 21+2 and so on if x>24 x=0 and if swappad occupied i just add one until a free position. This will indeed give a unique swappad for each password but i guess it's not ideal, is it a better way to do this?

I don't understand what you are doing, but I'm not sure it matters. Algorithmic permutation is well understood. It is relatively easy to do permutations right; that is, to select one from among all possible permutations, each having an exactly equal probability of being selected.

Because of the size of the permutation universe, one might argue that exactly equal probability is not required, but, again, it is easy enough to do this right instead of arguing that some other method is not so bad.

And just another little question i really can't see why rotation of the key to XOR with would be bad, because if not rotaded the distribution of the swap would be linear but if rotated it seem to me like you hide the fact that the distribution of swaps is linear between the blocks, is this just plain wrong. I was thinking of using each byte in key to rotate it at bitlevel.

Yes, permutation can be considered "linear," but it is certainly not linear in the same sense as other ciphers. When a cipher does not try to emulate huge Simple Substitution, no substitution relationship exists to be approximated in a linear way. That is not to say that there can be no attack on Dynamic Substitution, just that conventional attacks apply to conventional ciphers, and simply may not be useful on fundamentally different structures.

The problem with rotating the key between blocks is not distribution, since we already assumed the key is random-like. The problem is that we want the cipher transformation for each block to be as independent as possible, and we can do much better than to use the same key values over again in a simple rotation.

In my recent articles I suggest using a large-state RNG, which is also well-understood technology. Yes, there will be some relationship between block permutations as defined in a 100,000-bit (or so) state space, but that will be much harder to find than a simple rotation.

One could argue that it is impossible to externally know what permutation is used in each block. Certainly, known-plaintext does not expose the permutation, and the common "bit-flip" attack on a permutation is prevented with message keys. (We should use a different random key every time the system is started, even if the same message is encrypted under the same user key.)

If absolutely no information at all is leaked by bit-permutation ciphering, one could safely use a weak (i.e., "linear") sequence generator to construct permutations. It would still need 80 or more bits of state, of course.

And, since bit permutation is scalable to tiny blocks, one might construct tiny versions with weak linear generators. Perhaps in this way some sort of attack could be developed that would help to define the strength of these designs.

Another thought that i decided not to do was to add positions to the pads by reading the key 4 bite at a time. But since javascript not the fastest language on earth, that would be heavy and take time. What do you think?

Again, I don't understand, and, again, I don't think it matters. If you are worried about speed, I think you should just try it and see. No opinions are necessary.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 09:37:21 +0200 From: "Dabiker" dabiker@singularity.no Message-ID: FAFl7.20892$rZ3.59196@news1.bredband.com References: 3b971cd8.16155346@netnews.att.net Newsgroups: sci.crypt Lines: 109

What i actually do is to use the key values as the startpoint for the actual swap process so i use all (in my case 256 bits, that would be 32 bytes

1,2,3,4,5,6,7,8,9,10 211,9,3,79,98,34,56,13,16

The key values in the lower row will be swapped with them in the one above so byte

33,34 will be swaped with 211+1,9+1.......and so on and if swap already occupied i just add 1 It's a strange generator but the fact is it generate a unique swappad for each generatedkey

"Terry Ritter" ritter@ciphersbyNOSPAMritter.com wrote in message news:3b971cd8.16155346@netnews.att.net...

On Thu, 6 Sep 2001 06:32:11 +0200, in 4TCl7.20812$rZ3.59480@news1.bredband.com, in sci.crypt "Dabiker" dabiker@singularity.no wrote:

[...] My idea of permutations i would guess is not mainstream, that's why i want your oppinion abut it If we suppose i have a keystream 3 byte 24bits Examle: 11,6,23 My swapad would look like this 11, 6 , 21 , 11+1 , 6+1 , 21+1 , 11+2 , 6+2 , 21+2 and so on if x>24 x=0 and if swappad occupied i just add one until a free position. This will indeed give a unique swappad for each password but i guess it's not ideal, is it a better way to do this?

I don't understand what you are doing, but I'm not sure it matters. Algorithmic permutation is well understood. It is relatively easy to do permutations right; that is, to select one from among all possible permutations, each having an exactly equal probability of being selected.

Because of the size of the permutation universe, one might argue that exactly equal probability is not required, but, again, it is easy enough to do this right instead of arguing that some other method is not so bad.

And just another little question i really can't see why rotation of the key to XOR with would be bad, because if not rotaded the distribution of the swap would be linear but if rotated it seem to me like you hide the fact that the distribution of swaps is linear between the blocks, is this just plain wrong. I was thinking of using each byte in key to rotate it at bitlevel.

Yes, permutation can be considered "linear," but it is certainly not linear in the same sense as other ciphers. When a cipher does not try to emulate huge Simple Substitution, no substitution relationship exists to be approximated in a linear way. That is not to say that there can be no attack on Dynamic Substitution, just that conventional attacks apply to conventional ciphers, and simply may not be useful on fundamentally different structures.

The problem with rotating the key between blocks is not distribution, since we already assumed the key is random-like. The problem is that we want the cipher transformation for each block to be as independent as possible, and we can do much better than to use the same key values over again in a simple rotation.

In my recent articles I suggest using a large-state RNG, which is also well-understood technology. Yes, there will be some relationship between block permutations as defined in a 100,000-bit (or so) state space, but that will be much harder to find than a simple rotation.

One could argue that it is impossible to externally know what permutation is used in each block. Certainly, known-plaintext does not expose the permutation, and the common "bit-flip" attack on a permutation is prevented with message keys. (We should use a different random key every time the system is started, even if the same message is encrypted under the same user key.)

If absolutely no information at all is leaked by bit-permutation ciphering, one could safely use a weak (i.e., "linear") sequence generator to construct permutations. It would still need 80 or more bits of state, of course.

And, since bit permutation is scalable to tiny blocks, one might construct tiny versions with weak linear generators. Perhaps in this way some sort of attack could be developed that would help to define the strength of these designs.

Another thought that i decided not to do was to add positions to the pads by reading the key 4 bite at a time. But since javascript not the fastest language on earth, that would be heavy and take time. What do you think?

Again, I don't understand, and, again, I don't think it matters. If you are worried about speed, I think you should just try it and see. No opinions are necessary.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 10:03:22 +0200 From: "Dabiker" dabiker@singularity.no Message-ID: 2ZFl7.20907$rZ3.59291@news1.bredband.com References: FAFl7.20892$rZ3.59196@news1.bredband.com Newsgroups: sci.crypt Lines: 122

Oooops a bit tired, the numbers represent the array slots. And what is swapped are bits not bytes. "Dabiker" dabiker@singularity.no wrote in message news:FAFl7.20892$rZ3.59196@news1.bredband.com...

What i actually do is to use the key values as the startpoint for the actual swap process so i use all (in my case 256 bits, that would be 32 bytes

1,2,3,4,5,6,7,8,9,10 211,9,3,79,98,34,56,13,16

The key values in the lower row will be swapped with them in the one above so byte

33,34 will be swaped with 211+1,9+1.......and so on and if swap already occupied i just add 1 It's a strange generator but the fact is it generate a unique swappad for each generatedkey

"Terry Ritter" ritter@ciphersbyNOSPAMritter.com wrote in message news:3b971cd8.16155346@netnews.att.net...

On Thu, 6 Sep 2001 06:32:11 +0200, in 4TCl7.20812$rZ3.59480@news1.bredband.com, in sci.crypt "Dabiker" dabiker@singularity.no wrote:

[...] My idea of permutations i would guess is not mainstream, that's why i want your oppinion abut it If we suppose i have a keystream 3 byte 24bits Examle: 11,6,23 My swapad would look like this 11, 6 , 21 , 11+1 , 6+1 , 21+1 , 11+2 , 6+2 , 21+2 and so on if x>24 x=0 and if swappad occupied i just add one until a free position. This will indeed give a unique swappad for each password but i guess it's not ideal, is it a better way to do this?

I don't understand what you are doing, but I'm not sure it matters. Algorithmic permutation is well understood. It is relatively easy to do permutations right; that is, to select one from among all possible permutations, each having an exactly equal probability of being selected.

Because of the size of the permutation universe, one might argue that exactly equal probability is not required, but, again, it is easy enough to do this right instead of arguing that some other method is not so bad.

And just another little question i really can't see why rotation of the key to XOR with would be bad, because if not rotaded the distribution of the swap would be linear but if rotated it seem to me like you hide the fact that the distribution of swaps is linear between the blocks, is this just plain wrong. I was thinking of using each byte in key to rotate it at bitlevel.

Yes, permutation can be considered "linear," but it is certainly not linear in the same sense as other ciphers. When a cipher does not try to emulate huge Simple Substitution, no substitution relationship exists to be approximated in a linear way. That is not to say that there can be no attack on Dynamic Substitution, just that conventional attacks apply to conventional ciphers, and simply may not be useful on fundamentally different structures.

The problem with rotating the key between blocks is not distribution, since we already assumed the key is random-like. The problem is that we want the cipher transformation for each block to be as independent as possible, and we can do much better than to use the same key values over again in a simple rotation.

In my recent articles I suggest using a large-state RNG, which is also well-understood technology. Yes, there will be some relationship between block permutations as defined in a 100,000-bit (or so) state space, but that will be much harder to find than a simple rotation.

One could argue that it is impossible to externally know what permutation is used in each block. Certainly, known-plaintext does not expose the permutation, and the common "bit-flip" attack on a permutation is prevented with message keys. (We should use a different random key every time the system is started, even if the same message is encrypted under the same user key.)

If absolutely no information at all is leaked by bit-permutation ciphering, one could safely use a weak (i.e., "linear") sequence generator to construct permutations. It would still need 80 or more bits of state, of course.

And, since bit permutation is scalable to tiny blocks, one might construct tiny versions with weak linear generators. Perhaps in this way some sort of attack could be developed that would help to define the strength of these designs.

Another thought that i decided not to do was to add positions to the pads by reading the key 4 bite at a time. But since javascript not the fastest language on earth, that would be heavy and take time. What do you think?

Again, I don't understand, and, again, I don't think it matters. If you are worried about speed, I think you should just try it and see. No opinions are necessary.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 10:34:17 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B973509.4A902EEA@t-online.de References: 2ZFl7.20907$rZ3.59291@news1.bredband.com Newsgroups: sci.crypt Lines: 30

Dabiker wrote:

Oooops a bit tired, the numbers represent the array slots. And what is swapped are bits not bytes. "Dabiker" dabiker@singularity.no wrote in message news:FAFl7.20892$rZ3.59196@news1.bredband.com...

What i actually do is to use the key values as the startpoint for the actual swap process so i use all (in my case 256 bits, that would be 32 bytes

1,2,3,4,5,6,7,8,9,10 211,9,3,79,98,34,56,13,16

The key values in the lower row will be swapped with them in the one above so byte

33,34 will be swaped with 211+1,9+1.......and so on and if swap already occupied i just add 1 It's a strange generator but the fact is it generate a unique swappad for each generatedkey

Have you considered using a secret seed for a PRNG to get a pseudo-random number sequence to permute the bits of the plaintext message with the algorithm of Durstenfeld (see Knuth vol.2)?

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 10:57:39 +0200 From: "Dabiker" dabiker@singularity.no Message-ID: XLGl7.21068$rZ3.59496@news1.bredband.com References: 3B973509.4A902EEA@t-online.de Newsgroups: sci.crypt Lines: 44

"Mok-Kong Shen" mok-kong.shen@t-online.de wrote in message news:3B973509.4A902EEA@t-online.de...

Dabiker wrote:

Oooops a bit tired, the numbers represent the array slots. And what is swapped are bits not bytes. "Dabiker" dabiker@singularity.no wrote in message news:FAFl7.20892$rZ3.59196@news1.bredband.com...

What i actually do is to use the key values as the startpoint for the actual swap process so i use all (in my case 256 bits, that would be 32 bytes

1,2,3,4,5,6,7,8,9,10 211,9,3,79,98,34,56,13,16

The key values in the lower row will be swapped with them in the one above so byte

33,34 will be swaped with 211+1,9+1.......and so on and if swap already occupied i just add 1 It's a strange generator but the fact is it generate a unique swappad for each generatedkey

Have you considered using a secret seed for a PRNG to get a pseudo-random number sequence to permute the bits of the plaintext message with the algorithm of Durstenfeld (see Knuth vol.2)? Sorry you talk above my skill i really don't know what a prng is i only generate my swapserie once from the password what kind of advantage in speed or randomness would Durstenfeld give compared to my i only knows that any 256 bit key in my algoritm generate a unique output of 256 values is that the case with Durstenfeld and is it faster?

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 10:55:51 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B973A17.46DA9024@t-online.de References: XLGl7.21068$rZ3.59496@news1.bredband.com Newsgroups: sci.crypt Lines: 46

Dabiker wrote:

"Mok-Kong Shen" mok-kong.shen@t-online.de wrote:

Dabiker wrote:

Oooops a bit tired, the numbers represent the array slots. And what is swapped are bits not bytes. "Dabiker" dabiker@singularity.no wrote in message news:FAFl7.20892$rZ3.59196@news1.bredband.com...

What i actually do is to use the key values as the startpoint for the actual swap process so i use all (in my case 256 bits, that would be 32 bytes

1,2,3,4,5,6,7,8,9,10 211,9,3,79,98,34,56,13,16

The key values in the lower row will be swapped with them in the one above so byte

33,34 will be swaped with 211+1,9+1.......and so on and if swap already occupied i just add 1 It's a strange generator but the fact is it generate a unique swappad for each generatedkey

Have you considered using a secret seed for a PRNG to get a pseudo-random number sequence to permute the bits of the plaintext message with the algorithm of Durstenfeld (see Knuth vol.2)? Sorry you talk above my skill i really don't know what a prng is i only generate my swapserie once from the password what kind of advantage in speed or randomness would Durstenfeld give compared to my i only knows that any 256 bit key in my algoritm generate a unique output of 256 values is that the case with Durstenfeld and is it faster?

If you want to know about PRNG (recommended), see Knuth or Schneier's book. A common PRNG runs very fast on computers to generate numbers. Durstenfeld does swaps. Why should it be slower than your swapping?

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 09:59:53 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B972CF9.A3F8F1AF@t-online.de References: 3b96f202.5187835@netnews.att.net Newsgroups: sci.crypt Lines: 23

Terry Ritter wrote:

Without substitution tables, there are no weak tables. There is no mixing and so no weak mixing. There are no differential or linear ciphering relationships. And there are no rounds to be peeled off. These are rather interesting characteristics.

Following your dynamic transposition article some time ago, I suggested a similar scheme without balancing the plaintext bits, thus avoiding the disadvantage of expanding the length, but simply permuting the plaintext bits and then xor-ing the result with a permuted balanced (on afterthought 'approximate' balancing would do sufficiently well) bit string of the same length as the plaintext. On the other hand, there is nothing against combining such a processing with a proper substitution run with e.g. a normal substitution table or by equivalent means, I suppose. (It may be noted that xor is a 'degenerate' mono-alphabitic substitution.)

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Wed, 5 Sep 2001 23:51:12 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n6dpg$2vdf$1@agate.berkeley.edu References: 3b96b140.17226392@netnews.att.net Newsgroups: sci.crypt Lines: 17

Terry Ritter wrote:

daw@mozart.cs.berkeley.edu (David Wagner) wrote:

There are plenty of applications where ability to change a middle block is sufficient to break security, despite the garbling of the subsequent block. In fact, CBC should never be assumed to provide integrity protection. If you need integrity, you should always use a MAC.

OK, how about: "There is no way to do that properly, so it is almost no MITM opportunity at all, and certainly nothing comparable to the almost effortless MITM investment of the first block security problem." But you already knew that, didn't you?

What does your first "that" refer to?

There is certainly a way to support integrity properly: namely, use a secure MAC.

Subject: Re: BIG question about using and storing IV's Date: Wed, 5 Sep 2001 20:38:38 -0400 From: "RDionysus" Encryptotron@hushmail.cox Message-ID: <999737794.613565@zver> References: 3b96b140.17226392@netnews.att.net Newsgroups: sci.crypt Lines: 67

"Terry Ritter" ritter@ciphersbyNOSPAMritter.com wrote in message news:3b96b140.17226392@netnews.att.net...

On Wed, 5 Sep 2001 20:01:00 +0000 (UTC), in 9n609s$2nha$1@agate.berkeley.edu, in sci.crypt daw@mozart.cs.berkeley.edu (David Wagner) wrote:

Terry Ritter wrote:

Any other block also can be changed bit-for-bit (by changing the ciphertext), but doing that will also hopelessly garble the earlier block. There is no way to do that properly, so it is no MITM opportunity at all.

Your last statement does not follow. There are plenty of applications where ability to change a middle block is sufficient to break security, despite the garbling of the subsequent block. In fact, CBC should never be assumed to provide integrity protection. If you need integrity, you should always use a MAC.

OK, how about: "There is no way to do that properly, so it is almost no MITM opportunity at all, and certainly nothing comparable to the almost effortless MITM investment of the first block security problem." But you already knew that, didn't you?

This thread was started by someone who did not know about crypto. The question was something like: "Can CBC have a security problem when the IV is exposed." The early answers, with appropriate math handwaves, were: "No." Those were wrong, the math was faulty, yet we heard nothing from you.

This thread also shows how math handwaves don't work. But math which attempts to be both precise and complete probably cannot be debugged by the rest of us. So, in general, only mathematicians can trust math results, and even they may be wrong. The obvious implication is that nobody can trust math results to cryptographic levels of assurance.

When you finally did get around to an answer, no doubt seeing an opportunity to prove me wrong (since you had no comment about the larger implications of bad math used to support an argument), your answer was "No:"

This only sounds like a "security problem" if you expect CBC mode to provide integrity protection.

For the record, I was not concerned with integrity in this context, just security.

But the guy explicitly said he did not know crypto, so your assumption that he had any "expectations" at all about CBC mode was at least inattentive to the problem statement.

The right answer, with which you apparently now agree, is: "Yes." But that is no correction, since it is the answer I gave from the start.

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Now that's a nice, concise, clear answer.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 10:11:13 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B972FA1.88CB3E3C@t-online.de References: 3b96b140.17226392@netnews.att.net Newsgroups: sci.crypt Lines: 19

Terry Ritter wrote:

[snip]

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Is it because that additional secret materials are expensive or difficult to get that one uses a plain IV? Further, if one decides not to hide the IV, couldn't one somehow make the manupulation of the IV hard though e.g. using the date and message sequence number to derive an IV? (Or does an IV needs to have full 'entropy'?) In such a case, the IV needs not be transmitted at all. Thanks.

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 17:11:09 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b97adce.3076433@netnews.att.net References: 3B972FA1.88CB3E3C@t-online.de Newsgroups: sci.crypt Lines: 48

On Thu, 06 Sep 2001 10:11:13 +0200, in 3B972FA1.88CB3E3C@t-online.de, in sci.crypt Mok-Kong Shen mok-kong.shen@t-online.de wrote:

Terry Ritter wrote:

[snip]

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Is it because that additional secret materials are expensive or difficult to get that one uses a plain IV?

The motive I have seen for not using a good random value is that the system does not have a source of good random values.

Further, if one decides not to hide the IV, couldn't one somehow make the manupulation of the IV hard though e.g. using the date and message sequence number to derive an IV? (Or does an IV needs to have full 'entropy'?)

The issue is the ability to change the IV in transit. In general, we can't prevent somebody from changing data. But we can add systems to detect such change. Then if we find a tampered message we can discard it and try again, perhaps in other ways.

In such a case, the IV needs not be transmitted at all.

The IV does not really add secrecy, so using a predictable value -- or just an exposed but somehow non-modifiable value -- is not an issue. We do of course want the IV value to not repeat often.

At first glance, using a message sequence value seems OK from the IV security standpoint (although I would like it to start at a random value). But if we do that, the opponent might destroy a message in transit, thus making the sequence value different on each end, and preventing further communication when we need it most. So this little low-level IV requirement has security implications for the entire system design.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 22:03:56 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B97D6AB.2E89A61F@t-online.de References: 3b97adce.3076433@netnews.att.net Newsgroups: sci.crypt Lines: 25

Terry Ritter wrote:

The IV does not really add secrecy, so using a predictable value -- or just an exposed but somehow non-modifiable value -- is not an issue. We do of course want the IV value to not repeat often.

At first glance, using a message sequence value seems OK from the IV security standpoint (although I would like it to start at a random value). But if we do that, the opponent might destroy a message in transit, thus making the sequence value different on each end, and preventing further communication when we need it most. So this little low-level IV requirement has security implications for the entire system design.

But, if each message carries a plain sequence number and the IV is some function of that number, loss of a message wouldn't cause problems to future 'intact' messages. Probably one satisfactory way is to use the block cipher and a dedicated key to encrpyt the sequence number to produce the IV, I suppose.

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 20:05:23 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n8ku3$u6j$1@agate.berkeley.edu References: 3b97adce.3076433@netnews.att.net Newsgroups: sci.crypt Lines: 9

Terry Ritter wrote:

The IV does not really add secrecy, so using a predictable value -- or just an exposed but somehow non-modifiable value -- is not an issue. We do of course want the IV value to not repeat often.

This is wrong. In CBC mode, the IV should be unpredictable, else the secrecy goals can be compromised. For Phil Rogaway's explanation, see http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt (particularly the end of Section 9).

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 20:31:52 GMT From: ritter@ciphersbyNOSPAMritter.com (Terry Ritter) Message-ID: 3b97dd30.1174225@netnews.att.net References: 9n8ku3$u6j$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 28

On Thu, 6 Sep 2001 20:05:23 +0000 (UTC), in 9n8ku3$u6j$1@agate.berkeley.edu, in sci.crypt daw@mozart.cs.berkeley.edu (David Wagner) wrote:

Terry Ritter wrote:

The IV does not really add secrecy, so using a predictable value -- or just an exposed but somehow non-modifiable value -- is not an issue. We do of course want the IV value to not repeat often.

This is wrong. In CBC mode, the IV should be unpredictable, else the secrecy goals can be compromised. For Phil Rogaway's explanation, see http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt (particularly the end of Section 9).

Unfortunately, I am not as impressed with that insight as he obviously was. Using a sequential CBC IV does not reveal data; at most it only reveals hints about the data. Compromises almost always exist in real systems. An IV is itself a compromise, and keeping the IV changing is vastly more important than sequentiality. That said, I would of course prefer that the CBC IV be a good random value. That said, I would really prefer not to have to use CBC at all; to me the obvious alternative is ciphers with very large blocks.

Terry Ritter www.ciphersbyritter.com/ Crypto Glossary www.ciphersbyritter.com/GLOSSARY.HTM

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 23:07:43 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B97E59F.E61A8CB9@t-online.de References: 3b97dd30.1174225@netnews.att.net Newsgroups: sci.crypt Lines: 20

Terry Ritter wrote:

[snip]

That said, I would really prefer not to have to use CBC at all; to me the obvious alternative is ciphers with very large blocks.

I think that it is advantageous to even have processing that treats the entire message as a whole. In case where such is not used/available, doing block encryption with appropriate chaining twice (double encryption), once going normally from the beginning of message to the end and once backwards from the end to the beginning, seems to fairly effectively 'bind' the content to a monolithic whole, thus resulting in quite some benefits as in case of whole message processing in my humble view.

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 21:32:00 -0000 From: david_a_scott@emailv.com (SCOTT19U.ZIP_GUY) Message-ID: 911495461H110W296LC45WIN3030R@207.126.101.92 References: 3B97E59F.E61A8CB9@t-online.de Newsgroups: sci.crypt Lines: 50

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote in <3B97E59F.E61A8CB9@t- online.de>:

Terry Ritter wrote:

[snip]

That said, I would really prefer not to have to use CBC at all; to me the obvious alternative is ciphers with very large blocks.

I think that it is advantageous to even have processing that treats the entire message as a whole. In case where such is not used/available, doing block encryption with appropriate chaining twice (double encryption), once going normally from the beginning of message to the end and once backwards from the end to the beginning, seems to fairly effectively 'bind' the content to a monolithic whole, thus resulting in quite some benefits as in case of whole message processing in my humble view.

That said is why I like "wrapped PCBC" Scott16u and scott19u treat the whole file as a single block. Why use a smaller block size unless one has to. Also double encryption where you go front to back then back to front does not add as much stregth as you wish. A simple proof of this is to take a large file encrypt in forward direction then backward direction. Then change the values in center of file. Know decrypt this in both direction. WHen done only the center portion of files has changed not the whole file so the information is not fully spreas aroutn. Take a scott16u file encrypt it. Change any part of file then decrypt. THe whole decrpted file is changed.

David A. Scott

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM" http://www.jim.com/jamesd/Kong/scott19u.zip My website http://members.nbci.com/ecil/index.htm My crypto code http://radiusnet.net/crypto/archive/scott/ MY Compression Page http://members.nbci.com/ecil/compress.htm **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 23:54:11 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B97F083.894426BC@t-online.de References: 911495461H110W296LC45WIN3030R@207.126.101.92 Newsgroups: sci.crypt Lines: 44

"SCOTT19U.ZIP_GUY" wrote:

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote:

I think that it is advantageous to even have processing that treats the entire message as a whole. In case where such is not used/available, doing block encryption with appropriate chaining twice (double encryption), once going normally from the beginning of message to the end and once backwards from the end to the beginning, seems to fairly effectively 'bind' the content to a monolithic whole, thus resulting in quite some benefits as in case of whole message processing in my humble view.

That said is why I like "wrapped PCBC" Scott16u and scott19u treat the whole file as a single block. Why use a smaller block size unless one has to. Also double encryption where you go front to back then back to front does not add as much stregth as you wish. A simple proof of this is to take a large file encrypt in forward direction then backward direction. Then change the values in center of file. Know decrypt this in both direction. WHen done only the center portion of files has changed not the whole file so the information is not fully spreas aroutn. Take a scott16u file encrypt it. Change any part of file then decrypt. THe whole decrpted file is changed.

The problem is that people prefer, or have more faith in, some well-known block ciphers than in other algorithms that are not sufficiently reviewed/examined. The choice of algorithms is up to the user, not up to you. So, assuming that a block cipher is to be used, I mentioned a way to achieve some benefits of large blocks or whole message processing. What you said of the influence is not true. Due to chaining in the forward direction, the last block is influenced by all preceding blocks. In the backward chaining, the influence is propagated to all blocks. If you change any ciphertext block, you wouldn't be able to decrypt the rest, since that block has to be gone through twice in the decryption process.

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 00:13:18 -0000 From: david_a_scott@emailv.com (SCOTT19U.ZIP_GUY) Message-ID: 9114B9DA8H110W296LC45WIN3030R@207.126.101.92 References: 3B97F083.894426BC@t-online.de Newsgroups: sci.crypt Lines: 57

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote in <3B97F083.894426BC@t- online.de>:

The problem is that people prefer, or have more faith in, some well-known block ciphers than in other algorithms that are not sufficiently reviewed/examined. The choice

Well at this not as well exaimed in the open literature.

So that is true.

of algorithms is up to the user, not up to you. So, assuming that a block cipher is to be used, I mentioned a way to achieve some benefits of large blocks or whole message processing. What you said of the influence is not true. Due to chaining in the forward direction, the last block is influenced by all preceding blocks. In the backward

 That is a false illusion that people who know little

about crypto belive. Wagner could set you straight on this subject but I doubt he would.

chaining, the influence is propagated to all blocks. If you change any ciphertext block, you wouldn't be able to decrypt the rest, since that block has to be gone through twice in the decryption process.

Obvious you either to stupid or lazy to test this, I have tested it and what I said is correct. I will state it again so others can try. Obviously you have such blind faith in your views you won't test it.

Go head use AES or what with CBC encrypt in forward direstion then in reverse direction like you stated. This time however don't just change the center of final encrypted file drop a few blocks from begining and end of file. When you try to decrypt this file it will match the input except at the start and at a few blocks where you edited and at the end. It starange we had this argument years ago I guess you can't learn.

David A. Scott

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM" http://www.jim.com/jamesd/Kong/scott19u.zip My website http://members.nbci.com/ecil/index.htm My crypto code http://radiusnet.net/crypto/archive/scott/ MY Compression Page http://members.nbci.com/ecil/compress.htm **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 09:57:45 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B987DF9.13A9E787@t-online.de References: 9114B9DA8H110W296LC45WIN3030R@207.126.101.92 Newsgroups: sci.crypt Lines: 83

"SCOTT19U.ZIP_GUY" wrote:

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote:

The problem is that people prefer, or have more faith in, some well-known block ciphers than in other algorithms that are not sufficiently reviewed/examined. The choice

Well at this not as well exaimed in the open literature.

So that is true.

That you can't change much. One thing you could probably do is to put forward a kind of 'proof' of strength of your algorithms in an 'appropriate' 'format', which is commonly hard to do, if indeed your stuffs are strong. (The fact that there is no rigorous 'measure' of crypto strength is at the foundation of difficulty anyway.)

of algorithms is up to the user, not up to you. So, assuming that a block cipher is to be used, I mentioned a way to achieve some benefits of large blocks or whole message processing. What you said of the influence is not true. Due to chaining in the forward direction, the last block is influenced by all preceding blocks. In the backward

 That is a false illusion that people who know little

about crypto belive. Wagner could set you straight on this subject but I doubt he would.

The error propagation property means the mutual 'influence' among the blocks. See also below concerning the chaining mode.

chaining, the influence is propagated to all blocks. If you change any ciphertext block, you wouldn't be able to decrypt the rest, since that block has to be gone through twice in the decryption process.

Obvious you either to stupid or lazy to test this, I have tested it and what I said is correct. I will state it again so others can try. Obviously you have such blind faith in your views you won't test it.

Go head use AES or what with CBC encrypt in forward direstion then in reverse direction like you stated. This time however don't just change the center of final encrypted file drop a few blocks from begining and end of file. When you try to decrypt this file it will match the input except at the start and at a few blocks where you edited and at the end. It starange we had this argument years ago I guess you can't learn.

Thanks. You are quick to point out the error before I could get up to make the correction myself. I was unconsciously considering instead of CBC my own chaining mode PCSBC (for 'plaintext and ciphertext sum block chaining'). (The phrase ''appropriate' chaining mode' in my first post was actually an implicit mention of that.) This employs both plaintext and ciphertext like PCBC, but the sum of all previously processed plaintext and ciphertext blocks is used, with initialization by IV. I employed it in my humble algorithm WEAK3-EX. (See my webpage. I used there sum mod 2^n instead of the xor to get some effect from the carry-overs.) A variant version was later proposed to the group, using the square of the sum to chain, see 'Nonlinear block chaining and whitening' of 25 Jul 00. (I used there additionally two pseudo-random streams to pre-process the plaintext and post-process the ciphertext, but that's not essential here.) With the use of a sum, any change of a block changes its value and the error propagates all the way in the direction of chaining. The use of forward and backward chaining then leads to erroneous decryption of all blocks.

M. K. Shen

http://home.t-online.de/home/mok-kong.shen

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 13:14:00 -0000 From: david_a_scott@emailv.com (SCOTT19U.ZIP_GUY) Message-ID: 911548401H110W296LC45WIN3030R@207.126.101.92 References: 3B987DF9.13A9E787@t-online.de Newsgroups: sci.crypt Lines: 63

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote in <3B987DF9.13A9E787@t- online.de>:

Thanks. You are quick to point out the error before I could get up to make the correction myself. I was unconsciously considering instead of CBC my own chaining mode PCSBC (for 'plaintext and ciphertext sum block

I suggust in the future when talking about ways to resist attack and you mention chainning. At least mention the mode if not a common mode. From your describtion it sounds better than the common FIPS standards the major crypto boys use or push. I to look to chain in a way that causes and all or nothing type of transform but large error propagation seems to not be what the herd wants. If one uses an infinite erro progating mode for chaining then eiter a wrapp aroung or reverse pass is a very good strong idea.

chaining'). (The phrase ''appropriate' chaining mode' in my first post was actually an implicit mention of that.) This employs both plaintext and ciphertext like PCBC, but the sum of all previously processed plaintext and ciphertext blocks is used, with initialization by IV. I employed it in my humble algorithm WEAK3-EX. (See my webpage. I used there sum

What is a humble algorithm? Does that mean you think its no good or is at just some sort of posturing on your part.

mod 2^n instead of the xor to get some effect from the carry-overs.) A variant version was later proposed to the group, using the square of the sum to chain, see 'Nonlinear block chaining and whitening' of 25 Jul 00. (I used there additionally two pseudo-random streams to pre-process the plaintext and post-process the ciphertext, but that's not essential here.) With the use of a sum, any change of a block changes its value and the error propagates all the way in the direction of chaining. The use of forward and backward chaining then leads to erroneous decryption of all blocks.

Again true but the user would falsely be assuming something like CBC unless told otherwise.

David A. Scott

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM" http://www.jim.com/jamesd/Kong/scott19u.zip My website http://members.nbci.com/ecil/index.htm My crypto code http://radiusnet.net/crypto/archive/scott/ MY Compression Page http://members.nbci.com/ecil/compress.htm **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 18:57:53 +0200 From: Mok-Kong Shen mok-kong.shen@t-online.de Message-ID: 3B98FC91.38791A12@t-online.de References: 911548401H110W296LC45WIN3030R@207.126.101.92 Newsgroups: sci.crypt Lines: 32

"SCOTT19U.ZIP_GUY" wrote:

[snip]

What is a humble algorithm? Does that mean you think its no good or is at just some sort of posturing on your part. [snip]

Since you pointedly and explicitly questioned that, I have to answer. Perhaps you have also noticed that my algorithms are acronymed 'WEAK.....' (the expanded full name is contrived), while in comparison e.g. recently one person claimed his (not yet implemented) algorithm to be 'unbreakable'. Firstly, I wanted to save from the very beginning the bandwidth of senselessly discussing with people in case I had expressed a favourable personal valuation of my algorithms. Secondly, no one is able to sufficiently objectively evaluate his own works, whether intellectual or material. Thirdly, even if one has done extremely careful and extensive examinations, one could still never be sure whether a new attack wouldn't later be discovered which surprisingly very effectively functions on a particular given encryption algorithm. Thus an acronym like WEAK gives in my view an appropriate warning to the user, much like you find with most packages of medicaments a statement concerning all kinds of potential side-effects and contra-indications.

M. K. Shen

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 17:47:44 -0000 From: david_a_scott@emailv.com (SCOTT19U.ZIP_GUY) Message-ID: 911579579H110W296LC45WIN3030R@207.126.101.92 References: 3B98FC91.38791A12@t-online.de Newsgroups: sci.crypt Lines: 57

mok-kong.shen@t-online.de (Mok-Kong Shen) wrote in <3B98FC91.38791A12@t- online.de>:

"SCOTT19U.ZIP_GUY" wrote:

[snip]

What is a humble algorithm? Does that mean you think its no good or is at just some sort of posturing on your part. [snip]

Since you pointedly and explicitly questioned that, I have to answer. Perhaps you have also noticed that my algorithms are acronymed 'WEAK.....' (the expanded full name is contrived), while in comparison e.g. recently one person claimed his (not yet implemented) algorithm to be 'unbreakable'. Firstly, I wanted to save from the very beginning the bandwidth of senselessly discussing with people in case I had expressed a favourable personal valuation of my algorithms. Secondly, no one is able to sufficiently objectively evaluate his own works, whether intellectual or material. Thirdly, even if one has done extremely careful and extensive examinations, one could still never be sure whether a new attack wouldn't later be discovered which surprisingly very effectively functions on a particular given encryption algorithm. Thus an acronym like WEAK gives in my view an appropriate warning to the user, much like you find with most packages of medicaments a statement concerning all kinds of potential side-effects and contra-indications.

M. K. Shen

I guess you anwsered my question. I guess its simalar to why I want to call my next cipher snakeoil. But its not for as humble a reason as yours its more to mock the whole false pseudo pretend open field of crypto. Well then again maybe it is for the same reson you named yours as you did.

David A. Scott

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM" http://www.jim.com/jamesd/Kong/scott19u.zip My website http://members.nbci.com/ecil/index.htm My crypto code http://radiusnet.net/crypto/archive/scott/ MY Compression Page http://members.nbci.com/ecil/compress.htm **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"

Subject: Re: BIG question about using and storing IV's Date: Fri, 7 Sep 2001 00:21:06 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n93ti$16m7$2@agate.berkeley.edu References: 3b97dd30.1174225@netnews.att.net Newsgroups: sci.crypt Lines: 16

Terry Ritter wrote:

Using a sequential CBC IV does not reveal data; at most it only reveals hints about the data.

Sure. I'd like to avoid revealing hints about data. Wouldn't you?

There's essentially no cost to using unpredictable IV's. If you can do cryptography, and if you can afford an IV, you can generate unpredictable IV's. You can stretch a short random seed to a very long unpredictable stream using any stream cipher or block cipher, and use this as the source for your unpredictable IV's. You can even, if you like, transmit a counter and then use as your IV the encryption of that IV under some secret key.

I see no good reason to use predictable IV's, and good reasons to avoid them.

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 00:35:43 -0000 From: david_a_scott@emailv.com (SCOTT19U.ZIP_GUY) Message-ID: 9114B1040H110W296LC45WIN3030R@207.126.101.92 References: 9n93ti$16m7$2@agate.berkeley.edu Newsgroups: sci.crypt Lines: 36

daw@mozart.cs.berkeley.edu (David Wagner) wrote in 9n93ti$16m7$2@agate.berkeley.edu:

Terry Ritter wrote:

Using a sequential CBC IV does not reveal data; at most it only reveals hints about the data.

Sure. I'd like to avoid revealing hints about data. Wouldn't you?

There's essentially no cost to using unpredictable IV's. If you can do cryptography, and if you can afford an IV, you can generate unpredictable IV's. You can stretch a short random seed to a very long unpredictable stream using any stream cipher or block cipher, and use this as the source for your unpredictable IV's. You can even, if you like, transmit a counter and then use as your IV the encryption of that IV under some secret key.

I see no good reason to use predictable IV's, and good reasons to avoid them.

Seems look good reasoning to apply to CTR mode doesn't it?

David A. Scott

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM" http://www.jim.com/jamesd/Kong/scott19u.zip My website http://members.nbci.com/ecil/index.htm My crypto code http://radiusnet.net/crypto/archive/scott/ MY Compression Page http://members.nbci.com/ecil/compress.htm **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"

Subject: Re: BIG question about using and storing IV's Date: Fri, 07 Sep 2001 00:50:22 GMT From: Tom St Denis tomstdenis@yahoo.com Message-ID: 3B981A1D.6020006@yahoo.com References: 9114B1040H110W296LC45WIN3030R@207.126.101.92 Newsgroups: sci.crypt Lines: 50

SCOTT19U.ZIP_GUY wrote:

daw@mozart.cs.berkeley.edu (David Wagner) wrote in 9n93ti$16m7$2@agate.berkeley.edu:

Terry Ritter wrote:

Using a sequential CBC IV does not reveal data; at most it only reveals hints about the data.

Sure. I'd like to avoid revealing hints about data. Wouldn't you?

There's essentially no cost to using unpredictable IV's. If you can do cryptography, and if you can afford an IV, you can generate unpredictable IV's. You can stretch a short random seed to a very long unpredictable stream using any stream cipher or block cipher, and use this as the source for your unpredictable IV's. You can even, if you like, transmit a counter and then use as your IV the encryption of that IV under some secret key.

I see no good reason to use predictable IV's, and good reasons to avoid them.

Seems look good reasoning to apply to CTR mode doesn't it?'

What the heck does this mean?

Anyways CTR is provably information theoretically secure. Sure you can swap blocks and mess up the stream. That's what MACs are for.

As to extracting the plaintext given that CTR is used properly it is impossible unless you break the cipher first. Which is easy to prove.

Proof. Suppose given L CTR outputs you can predict the L+1,L+2,...,L+Q, CTR output [say we are encoding known plaintext] with a probability better than 1/(2^N-(L+Q)). That means you can encrypt known plaintext without knowledge of the key. Anecdotal evidence suggests that is equivalent to breaking the cipher.

Remark. For example, In DES suppose that L amounts to 2^43 texts. We could apply a linear attack and find the key. We could then predict the L+1, ..., L+Q outputs faster than a uniform probability of the remaining unused ciphertexts.

Et Voila. Not an elegant proof but works none-the-less.

Tom

Subject: Re: BIG question about using and storing IV's Date: 15 Sep 2001 18:12:22 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: slrn9q76g6.q6b.mdw@tux.nsict.org References: 3b96b140.17226392@netnews.att.net Newsgroups: sci.crypt Lines: 50

Terry Ritter ritter@ciphersbyNOSPAMritter.com wrote:

daw@mozart.cs.berkeley.edu (David Wagner) wrote:

If you need integrity, you should always use a MAC.

OK, how about: "There is no way to do that properly,

Err... Carter-Wegman MACs work. Real live XOR-universal hash functions exist. Choose your acceptable forgery probability 2^{-k} and number of message n and share a key for the hash and n k random bits and you're done.

This thread was started by someone who did not know about crypto. The question was something like: "Can CBC have a security problem when the IV is exposed." The early answers, with appropriate math handwaves, were: "No." Those were wrong, the math was faulty, yet we heard nothing from you.

No. As usual, you don't understand what the maths says. It's not just the first block that's weak: CBC encryption, like many other encryption modes, just isn't strong against chosen-ciphertext attacks (equivalently: they're malleable).

This thread also shows how math handwaves don't work. But math which attempts to be both precise and complete probably cannot be debugged by the rest of us. So, in general, only mathematicians can trust math results, and even they may be wrong. The obvious implication is that nobody can trust math results to cryptographic levels of assurance.

In my experience, the sorts of provable security results surrounding symmetric cryptography tend to be relatively simple and the proofs can be read by anyone with a sufficiently logical frame of mind and a half- decent understanding of probability. I find that Mihir Bellare and Phillip Rogaway, who have produced much of the (excellent) research in this area, produce extremely readable papers, with good explanations of what's going on and why.

I agree that the provable security community have made errors in the past: the `proof' for OAEP springs to mind. But here, the error was one of definition: the proofs, as actually presented, were all valid.

Yes, CBC does have a first block security problem caused by exposing the IV to MITM modification. No, that is not the same as the obvious MITM ability to change ciphertext.

Yes, of course it is.

Roll on unencumbered integrity-aware modes...

-- [mdw]

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 13:59:02 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b977e63.8077071@news.powersurfr.com References: 9n609s$2nha$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 44

On Wed, 5 Sep 2001 20:01:00 +0000 (UTC), daw@mozart.cs.berkeley.edu (David Wagner) wrote, in part:

If you need integrity, you should always use a MAC.

Why is this statement sometimes disputed?

In the classical cipher world, something like a MAC was difficult to implement. Also, the ciphers were not considered strong enough to bear extra redundancy. As well, messages were in text form, so garbles would be visible without an explicit checksum that could be verified mechanically.

Secrecy was the overriding consideration - but if a message was kept secret, people using the cipher might tend to assume a degree of integrity existed.

Indeed, ECB mode does not allow you to change chosen bits of a block, although it allows block replay.

My view of this issue is this:

When integrity is an explicit requirement of the system, a MAC will be used.

When integrity is not seen as an explicit requirement, then it is likely that a MAC will not be used. But it is also quite possible that users will assume, due to the fact that encryption is in use, that a degree of integrity exists. Hence, if there are cipher modes that at least ensure any attempt to tamper with the ciphertext will always result in at least one garbled block - and, hopefully, not more than one or two such blocks, since error recovery is also a desired property - they should be used.

Hence, it's not surprising that proposals such as the NSA's failed DCTR mode, and another proposal for a mode with "almost-free message integrity" are considered attractive. Too late for a formal submission, after recieving inspiration by the controversy over the DCTR mode withdrawal, I've come up with a "fixed" DCTR mode I call TCCFB mode.

John Savard http://home.ecn.ab.ca/~jsavard/index.html

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 16:49:59 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n89fn$nb5$1@agate.berkeley.edu References: 3b977e63.8077071@news.powersurfr.com Newsgroups: sci.crypt Lines: 8

John Savard wrote:

When integrity is an explicit requirement of the system, a MAC will be used.

Yup. However, you should go much further. It's a little-known rule of thumb that, when secrecy is a requirement of the system, a MAC is also called for. This ought to be broader recognized than it is.

Subject: Re: BIG question about using and storing IV's Date: Sat, 08 Sep 2001 05:35:08 GMT From: Paul Crowley paul@JUNKCATCHER.cluefactory.org.uk Message-ID: 87y9nrxuuf.fsf@saltationism.subnet.hedonism.cluefactory.org.uk References: 9n89fn$nb5$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 17

daw@mozart.cs.berkeley.edu (David Wagner) writes:

John Savard wrote:

When integrity is an explicit requirement of the system, a MAC will be used.

Yup. However, you should go much further. It's a little-known rule of thumb that, when secrecy is a requirement of the system, a MAC is also called for. This ought to be broader recognized than it is.

You mean in practice with real protocols and systems, I take it, rather than in theory? In theory, a One-Time-Pad provides perfect secrecy with very bad integrity.

__ Paul Crowley / o\ sig@paul.cluefactory.org.uk /__/ http://www.cluefactory.org.uk/paul/ "Conservation of angular momentum makes the world go around" - John Clark

Subject: Re: BIG question about using and storing IV's Date: Sat, 8 Sep 2001 06:37:20 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9nceb0$2uii$1@agate.berkeley.edu References: 87y9nrxuuf.fsf@saltationism.subnet.hedonism.cluefactory.org.uk Newsgroups: sci.crypt Lines: 59

Paul Crowley wrote:

You mean in practice with real protocols and systems, I take it, rather than in theory? In theory, a One-Time-Pad provides perfect secrecy with very bad integrity.

Yeah, I mean, when you have re-transmissions, application-specific post-processing of the decrypted plaintext, and so on.

Since you mentioned a OTP, let's take Hugo Krawczyk's example just for fun. Let's imagine we have an application that does some sort of redundant encoding transform: each 0 bit gets encoded to 00, and a 1 bit gets encoded to either 01 or 10 (we choose randomly). After encoding, we encrypt with a OTP.

The decoder at the recipient does the obvious thing: after decrypting, we send 00 -> 0, 01 -> 1, 10 -> 1, and if we see 11 we signal an error.

Hey, I know it sounds like a crazy example, but it's just a proof-of-concept.

Next consider an attacker who wants to read the first bit of the encrypted traffic, but doesn't know the key. Obviously the attacker has no hope of breaking the OTP, so he can't decrypt the ciphertext himself. His only hope is to go to someone who does know the key, and try to trick them into decrypting the ciphertext for him and telling him the result (an oracle attack, in other words).

This sounds totally far-fetched. How on earth is an attacker going to trick any sane endpoint into doing this?

Here's how. The attacker takes the ciphertext, and flips the first two bits of it. (This corresponds to the first bit position of the plaintext, since we have a 2x expansion factor from the redundancy encoding transform.) Let's look at what the receiver is going to do with this mangled ciphertext. If the pre-encoding bit was a 1, we encrypted 01 or 10 with a OTP, so the receiver will receive 10 or 01 after the OTP decryption, and the receiver will receive a 1 bit, as intended. On the other hand, if the pre-encoding bit was a 0, we encrypted 00, so the receiver receives 11 (thanks to the attacker's bit-flipping), and the receiver signals an error back to the sender.

Guess what! This reveals the first bit of the encrypted traffic, since the attacker can just check to see whether there was an error signaled or not.

This theoretical example is from Hugo's CRYPTO 2001 paper. It turns out that some vaguely similar scenarios have been found in real life earlier. For a nice example, see our reaction attack (in our MOBICOM paper) on 802.11: the existence of the TCP checksum replaces the redundancy encoding transform, the presence or absence of a TCP ACK packet reveals whether there was a decryption error, and the properties of TCP let us mount this attack without detection and let us repeat the attack to learn all bits of each packet easily. For a more complicated and earlier example, see Bellovin's paper on IPSEC. In fact, Bellovin's cut-and-paste attacks on IPSEC are the first published example I know of that illustrates the need for packet-level MACs if one wants to achieve application-level secrecy.

URLs for these papers can be found in my earlier post.

Subject: Re: BIG question about using and storing IV's Date: Wed, 5 Sep 2001 20:02:13 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n60c5$2nha$2@agate.berkeley.edu References: 3b967bd2.3546623@netnews.att.net Newsgroups: sci.crypt Lines: 8

Terry Ritter wrote:

One solution is to hash the plaintext, [...]

Actually, merely hashing the message (with, say, SHA, or some other unkeyed hash) and then CBC-encrypting is not sufficient to ensure security. There is a chosen-message attack against this scheme. You should use a proper message authentication code (MAC) for this purpose.

Subject: Re: BIG question about using and storing IV's Date: 6 Sep 2001 16:19:07 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: slrn9pf8fr.2tr.mdw@daryl.nsict.org References: 9n60c5$2nha$2@agate.berkeley.edu Newsgroups: sci.crypt Lines: 17

David Wagner daw@mozart.cs.berkeley.edu wrote:

Actually, merely hashing the message (with, say, SHA, or some other unkeyed hash) and then CBC-encrypting is not sufficient to ensure security. There is a chosen-message attack against this scheme. You should use a proper message authentication code (MAC) for this purpose.

A quick back-of-the-envelope computation shows that a CBC-encrypted hash isn't /too/ bad, actually, even if want you want is INT-CTXT (and hence NM-CCA). I'm playing with a sketch proof (random oracle model), but it's not done yet. The main point is that splicing stuff into a CBC ciphertext isn't actually very easy when all you've got is an oracle insisting on choosing random IVs all the time. I don't think that the security of the scheme is much lower than the existing birthday bound.

-- [mdw]

Subject: Re: BIG question about using and storing IV's Date: Thu, 6 Sep 2001 16:52:29 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n89kd$nb5$2@agate.berkeley.edu References: slrn9pf8fr.2tr.mdw@daryl.nsict.org Newsgroups: sci.crypt Lines: 18

Mark Wooding wrote:

David Wagner daw@mozart.cs.berkeley.edu wrote:

Actually, merely hashing the message (with, say, SHA, or some other unkeyed hash) and then CBC-encrypting is not sufficient to ensure security.

A quick back-of-the-envelope computation shows that a CBC-encrypted hash isn't /too/ bad, [...]

I'm not sure I understand what you mean, but there's an attack. Suppose you want to make the receiver think message M was sent, even thought the sender would never authorize this. Then you should construct M' = M || H(M) || X, where X is arbitrary and where || denotes concatenation (it better be at block boundaries). Ask the sender to transmit M'; he will form M' || H(M'), encrypt it with CBC mode, and transmit the result. Now you can truncate the ciphertext, snipping it just before the "X" part, and the receiver will think M was sent, which is an integrity failure.

Subject: Re: BIG question about using and storing IV's Date: 7 Sep 2001 09:24:16 GMT From: mdw@nsict.org (Mark Wooding) Message-ID: slrn9ph4i0.p67.mdw@daryl.nsict.org References: 9n89kd$nb5$2@agate.berkeley.edu Newsgroups: sci.crypt Lines: 7

David Wagner daw@mozart.cs.berkeley.edu wrote:

I'm not sure I understand what you mean, but there's an attack.

Please excuse me. I was talking absolute rubbish.

-- [mdw]

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 13:46:21 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b977dcc.7925887@news.powersurfr.com References: 3b967bd2.3546623@netnews.att.net Newsgroups: sci.crypt Lines: 12

On Wed, 05 Sep 2001 19:25:13 GMT, ritter@ciphersbyNOSPAMritter.com (Terry Ritter) wrote, in part:

The plaintext recovered for the first block can be precisely changed, bit-for-bit (by changing the transmitted IV) without also garbling another block.

My mistake was that I thought it could only be garbled. Yes, this is a significant distinction.

John Savard http://home.ecn.ab.ca/~jsavard/index.html

Subject: Re: BIG question about using and storing IV's Date: Thu, 06 Sep 2001 14:21:44 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b97860c.10038113@news.powersurfr.com References: 3b977dcc.7925887@news.powersurfr.com Newsgroups: sci.crypt Lines: 23

On Thu, 06 Sep 2001 13:46:21 GMT, jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) wrote, in part:

On Wed, 05 Sep 2001 19:25:13 GMT, ritter@ciphersbyNOSPAMritter.com (Terry Ritter) wrote, in part:

The plaintext recovered for the first block can be precisely changed, bit-for-bit (by changing the transmitted IV) without also garbling another block.

My mistake was that I thought it could only be garbled. Yes, this is a significant distinction.

I checked my page on block cipher modes, and I see that I did note the underlying cause of this problem when discussing error propagation. I've now made it explicit that bit-flipping is possible against the first block in CBC - and the last block in CFB. The latter is more obvious, but the two modes are in some ways mirror images, despite the fact that plaintext goes 'through' the block cipher in CBC and not CFB.

John Savard http://home.ecn.ab.ca/~jsavard/index.html

Subject: Re: BIG question about using and storing IV's Date: Sat, 01 Sep 2001 16:26:02 GMT From: jsavard@ecn.ab.SBLOK.ca.nowhere (John Savard) Message-ID: 3b910bb2.9225565@news.powersurfr.com References: <999337089.220850@zver> Newsgroups: sci.crypt Lines: 20

On Sat, 1 Sep 2001 05:21:05 -0400, "RDionysus" Encryptotron@hushmail.cox wrote, in part:

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?

For counter mode, it is indeed possible that a secret IV will provide a benefit in some cases. For CFB and CBC modes, however, the IV affects only the encipherment of the first block, and it stands in relation to that block in exactly the same way that the Nth block of ciphertext stands in relation to the encipherment of the (N+1)th block, so it is indeed very clear that the IV can be public.

John Savard http://home.ecn.ab.ca/~jsavard/index.html http://plaza.powersurfr.com/jsavard/other/slrint.htm

Subject: Re: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 10:38:45 -0700 From: Fritz Schneider fritz@cs.ucsd.edu Message-ID: Pine.GSO.4.33.0109011015050.26111-100000@beowulf.ucsd.edu References: <999337089.220850@zver> Newsgroups: sci.crypt Lines: 19

On Sat, 1 Sep 2001, RDionysus wrote:

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?

I'll take the bait... which experts suggest keeping the IV secret?

And also which experts suggest that using CBC with a public IV can "compromise overall security" and in what sense? AFAIK the IV is always public -- you use CBC so that identical plaintexts do not encrypt to identical ciphertexts. Either your underlying block cipher is secure or it isn't. Using CBC should not affect it.

-- fritz

Subject: Re: BIG question about using and storing IV's Date: Sat, 01 Sep 2001 17:43:15 GMT From: Tom St Denis tomstdenis@yahoo.com Message-ID: 3B911E7A.3090302@yahoo.com References: Pine.GSO.4.33.0109011015050.26111-100000@beowulf.ucsd.edu Newsgroups: sci.crypt Lines: 25

Fritz Schneider wrote:

On Sat, 1 Sep 2001, RDionysus wrote:

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?

I'll take the bait... which experts suggest keeping the IV secret?

And also which experts suggest that using CBC with a public IV can "compromise overall security" and in what sense? AFAIK the IV is always public -- you use CBC so that identical plaintexts do not encrypt to identical ciphertexts. Either your underlying block cipher is secure or it isn't. Using CBC should not affect it.

Just to be picky. It is possible for a cipher to be secure and insecure in CBC mode. The old variant of Squafer was weakened in CBC mode but in ECB/CTR mode it was ok.

Tom

Subject: Re: BIG question about using and storing IV's Date: Sat, 1 Sep 2001 19:04:57 -0400 From: "RDionysus" Encryptotron@hushmail.cox Message-ID: <999386527.279090@zver> References: 3B911E7A.3090302@yahoo.com Newsgroups: sci.crypt Lines: 78

"Fritz Schneider" fritz@cs.ucsd.edu wrote in message news:Pine.GSO.4.33.0109011015050.26111-100000@beowulf.ucsd.edu...

On Sat, 1 Sep 2001, RDionysus wrote:

My question is this: by most expert accounts making the IV explicit or known is fine, and has no more meaning than the actual ciphertext being public. But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext. I'm wondering what some of the experts here think....?

I'll take the bait... which experts suggest keeping the IV secret? And also which experts suggest that using CBC with a public IV can "compromise overall security" and in what sense? AFAIK the IV is always public -- you use CBC so that identical plaintexts do not encrypt to identical ciphertexts. Either your underlying block cipher is secure or it isn't. Using CBC should not affect it.

-- fritz

--William Stallings, in his book "Cryptography and Network Security: Principles and Practice", "...recommends security for the IV to prevent an adversary from modifying selected bits in the plaintext by complementing corresponding bits in the IV..." Also, if you do a search on the Web using the obvious keywords, you WILL get hits demonstrating quite a bit of debate on the topic, which is what led me ultimately to ask this question HERE.

On Sat, 1 Sep 2001 07:31:04 -0700, in 9mqsh6$a7m$1@slb2.atl.mindspring.net, in sci.crypt "Scott Fluhrer" sfluhrer@ix.netcom.com wrote:

RDionysus Encryptotron@hushmail.cox wrote in message news:999337089.220850@zver...

The Decrypt function will obviously later strip out the IV and use it for the reverse process. Since the program will ultimately be open-source, the location and contents of the IV will be public knowledge. Actually, even if the program wasn't formally open-source, that assumption should be made anyways.

--Well...what if I had a custom routine that embedded parts of the IV at various arbitrary byte locations throughout the ciphertext. Barring the reverse-engineering of my binary, who would know where or what the IV was?

BTW: make sure that your PRNG generates a different IV each time.

--Of course.

P.S.: A related side question: when implementing crypto routines that don't use an IV, is it a good idea to SALT passphrases? Like when using a block cipher in ECB mode or a stream cipher such as RC4? The random SALT value could then be stored in the cipher output in a fashion like the one described above?

The most secure thing you can do with ECB is not use it. For stream ciphers in general, it is essential that you salt any passphrase you will use the encrypt two different plaintexts. As for the specific case of RC4, you need to be careful how you salt it -- the obvious approach of concatinating the salt with the key turns out to be weak. I personally recommend that you hash the two together, and turn discard the first 256 bytes of RC4 output before using it to encrypt the file.

--Yes, I would only use the hashing method. In RC4, as far as discarding the first 256 bytes of the output.... Would performing multiple iterations of the S-box array shuffling, lets say, based on the length of the keyword in bytes, accomplish this?

Thanks for all the responses!

~~Rob

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 04:50:03 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n1mhr$ojs$3@agate.berkeley.edu References: <999386527.279090@zver> Newsgroups: sci.crypt Lines: 14

RDionysus wrote:

--William Stallings, in his book "Cryptography and Network Security: Principles and Practice", "...recommends security for the IV to prevent an adversary from modifying selected bits in the plaintext by complementing corresponding bits in the IV..."

Stallings is probably talking about integrity protection for the IV, not secrecy. And he's wrong here, anyway, if I understand correctly his argument. If you care about integrity, use a MAC. Whether or not you prevent modifications to the IV, CBC mode is completely inadequate at providing integrity guarantees. In general, Stallings' book is really a security book, not a crypto book; on crypto matters, you might find that you get better advice by looking elsewhere (e.g., The Handbook of Applied Cryptography).

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 04:44:56 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n1m88$ojs$1@agate.berkeley.edu References: <999337089.220850@zver> Newsgroups: sci.crypt Lines: 16

RDionysus wrote:

But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext.

Where are you getting this from? I can't remember any dispute over this: public IV's are widely used and I haven't heard any concerns about this. In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public, so I don't see how there can be any dispute on this. Am I missing something?

P.S.: A related side question: when implementing crypto routines that don't use an IV, is it a good idea to SALT passphrases?

Best of all is not to use passphrases; use machine-generated truly random keys.

Subject: Re: BIG question about using and storing IV's Date: Mon, 3 Sep 2001 23:30:50 -0700 From: Fritz Schneider fritz@cs.ucsd.edu Message-ID: Pine.GSO.4.33.0109032315430.19401-100000@beowulf.ucsd.edu References: 9n1m88$ojs$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 19

On Tue, 4 Sep 2001, David Wagner wrote:

[snip] In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public... [snip]

The original poster seems to have disappeared. If he's still

lurking, though, I think this might be the paper to which David is referring:

http://www-cse.ucsd.edu/~mihir/papers/sym-enc.html

The conclusion as I understand it is that with a public IV the scheme is secure, although CTR might be "better" from several standpoints.

-- fritz

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 03:06:23 -0400 From: "RDionysus" Encryptotron@hushmail.cox Message-ID: <999588243.313089@zver> References: Pine.GSO.4.33.0109032315430.19401-100000@beowulf.ucsd.edu Newsgroups: sci.crypt Lines: 24

"Fritz Schneider" fritz@cs.ucsd.edu wrote in message news:Pine.GSO.4.33.0109032315430.19401-100000@beowulf.ucsd.edu...

On Tue, 4 Sep 2001, David Wagner wrote:

[snip] In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public... [snip]

The original poster seems to have disappeared. If he's still lurking, though, I think this might be the paper to which David is referring:

http://www-cse.ucsd.edu/~mihir/papers/sym-enc.html

The conclusion as I understand it is that with a public IV the scheme is secure, although CTR might be "better" from several standpoints.

-- fritz

Thank you for the reference.

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 02:57:36 -0400 From: "RDionysus" Encryptotron@hushmail.cox Message-ID: <999587716.847444@zver> References: 9n1m88$ojs$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 28

"David Wagner" daw@mozart.cs.berkeley.edu wrote in message news:9n1m88$ojs$1@agate.berkeley.edu...

RDionysus wrote:

But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext.

Where are you getting this from? I can't remember any dispute over this: public IV's are widely used and I haven't heard any concerns about this. In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public, so I don't see how there can be any dispute on this. Am I missing something?

P.S.: A related side question: when implementing crypto routines that don't use an IV, is it a good idea to SALT passphrases?

Best of all is not to use passphrases; use machine-generated truly random keys.

If I take a user-entered passphrase, add some PRG salt, and hash using a cryptographically suitable algo, is that not using a machine generated "random" key?

Subject: Re: BIG question about using and storing IV's Date: Tue, 4 Sep 2001 07:15:18 +0000 (UTC) From: daw@mozart.cs.berkeley.edu (David Wagner) Message-ID: 9n1v26$srb$1@agate.berkeley.edu References: <999587716.847444@zver> Newsgroups: sci.crypt Lines: 12

RDionysus wrote:

If I take a user-entered passphrase, add some PRG salt, and hash using a cryptographically suitable algo, is that not using a machine generated "random" key?

Well, it is still susceptible to "dictionary attacks", if the user chooses a guessable passphrase.

Sometimes passphrases are unavoidable; but sometimes there are things one can do to move to stronger solutions. Could you tell us a bit more about what context you're going to use the crypto in? Maybe we can give you some suggestions.

Subject: Re: BIG question about using and storing IV's Date: 4 Sep 2001 09:51:06 GMT From: moeller@cdc.informatik.tu-darmstadt.de (Bodo Moeller) Message-ID: slrn9p990k.525.moeller@cdc-ws1.cdc.informatik.tu-darmstadt.de References: 9n1m88$ojs$1@agate.berkeley.edu Newsgroups: sci.crypt Lines: 24

David Wagner daw@mozart.cs.berkeley.edu:

RDionysus wrote:

But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext.

Where are you getting this from? I can't remember any dispute over this: public IV's are widely used and I haven't heard any concerns about this. In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public, so I don't see how there can be any dispute on this. Am I missing something?

And considering that for CBC and CFB each ciphertext block effectively is the IV for the remainder of the message, it is hard to imagine how these modes could be secure even with secret IVs if public IVs were essential.

-- Bodo M�ller moeller@cdc.informatik.tu-darmstadt.de PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html

Subject: Re: BIG question about using and storing IV's Date: 4 Sep 2001 12:26:38 GMT From: moeller@cdc.informatik.tu-darmstadt.de (Bodo Moeller) Message-ID: slrn9p9i48.525.moeller@cdc-ws1.cdc.informatik.tu-darmstadt.de References: slrn9p990k.525.moeller@cdc-ws1.cdc.informatik.tu-darmstadt.de Newsgroups: sci.crypt Lines: 29

Bodo Moeller moeller@cdc.informatik.tu-darmstadt.de:

David Wagner daw@mozart.cs.berkeley.edu:

RDionysus wrote:

But there does seem to be some degree of academic disagreement on whether or not a public IV can compromise the overall security of the code or somehow bolster a cryptanalytic attack on the ciphertext.

Where are you getting this from? I can't remember any dispute over this: public IV's are widely used and I haven't heard any concerns about this. In fact, I believe Bellare et. al have proven CBC mode secure when the IV is public, so I don't see how there can be any dispute on this. Am I missing something?

And considering that for CBC and CFB each ciphertext block effectively is the IV for the remainder of the message, it is hard to imagine how these modes could be secure even with secret IVs if public IVs were essential.

Oops ... that should have been "[...] it is hard to imagine how these modes could be secure even with secret IVs if public IVs were a problem".

-- Bodo M�ller moeller@cdc.informatik.tu-darmstadt.de PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html

Terry Ritter, hiscurrent address, and histop page.

Last updated: 2001-09-18