The IV in Block Cipher CBC Mode

A Ciphers 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 a question about the need for protecting the IV in a block cipher CBC mode. Various wrong answers ensue, with mathematical handwaves.

The Answer

The right answer is that an exposed IV might allow a man-in-the-middle (MITM) to change the IV value in-transit. Changing the IV changes only the deciphered plaintext for the first block, without garbling the second block. Any or all bits of the first block plaintext can be changed systematically with complete control.

In marked contrast, when ciphertext is changed in CBC mode, it does change the next block plaintext bit-for-bit, but it also garbles the plaintext for the current block (see diagram), 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.

Another suggestion avoids 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 to authenticate the IV, probably along with the plaintext. (But note that the solutions given above do not require authentication.) Typically, plaintext authentication consists of a hash of the IV and data, with the result included in the enciphered message so that any change will be detected. In CBC mode it is not 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, processing latency and potential "attacks" on authentication (that would be in addition to attacks on secrecy).

The ideal IV is the usual (in cryptography) unknowable random value, 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

As pointed out in 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 not expose 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 plaintext entropy.

Contents

• 2001-09- 1 RDionysus: "I am a computer programmer by trade, not a mathematician or a cryptography guru . . . ." "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....?"
• 2001-09- 1 Scott Fluhrer: "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:"
• 2001-09- 1 Terry Ritter: "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."
• 2001-09- 1 Scott Fluhrer: "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."
• 2001-09- 1 Terry Ritter: "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."
• 2001-09- 1 Scott Fluhrer: "You are right. My approach analyzed only privacy, not integrety. And, in this very specific scenario, hiding the IV helps:"
• 2001-09- 2 John Savard: "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."
• 2001-09- 4 David Wagner: "This only sounds like a "security problem" if you expect CBC mode to provide integrity protection. But such an expectation is completely unfounded."
• 2001-09- 4 Terry Ritter: "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? "
• 2001-09- 4 Mark Wooding: "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."
• 2001-09- 5 John Savard: "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."
• 2001-09- 5 Terry Ritter: "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. "
• 2001-09- 5 David Wagner: "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."
• 2001-09- 5 Terry Ritter: "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."
• 2001-09- 6 Dabiker: "Someone told me that you should have knowledge about transpositional ciphers."
• 2001-09- 6 Terry Ritter: "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."
• 2001-09- 6 Dabiker: "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."
• 2001-09- 6 Terry Ritter: "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."
• 2001-09- 6 Dabiker: "What i actually do is to use the key values as the startpoint for the actual swap process . . . ."
• 2001-09- 6 Dabiker: "Oooops a bit tired, the numbers represent the array slots. And what is swapped are bits not bytes."
• 2001-09- 6 Mok-Kong Shen: "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)?"
• 2001-09- 6 Dabiker: " Sorry you talk above my skill i really don't know what a prng is . . . ."
• 2001-09- 6 Mok-Kong Shen: "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?"
• 2001-09- 6 Mok-Kong Shen: "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 . . . ."
• 2001-09- 5 David Wagner: "What does your first "*that*" refer to?"
• 2001-09- 5 RDionysus: "For the record, I was not concerned with integrity in this context, just security."
• 2001-09- 6 Mok-Kong Shen: "Is it because that additional secret materials are expensive or difficult to get that one uses a plain IV?"
• 2001-09- 6 Terry Ritter: "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."
• 2001-09- 6 Mok-Kong Shen: "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."
• 2001-09- 6 David Wagner: "This is wrong. In CBC mode, the IV should be unpredictable, else the secrecy goals can be compromised. For Phil Rogaway's explanation, see . . . ."
• 2001-09- 6 Terry Ritter: "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." "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."
• 2001-09- 6 Mok-Kong Shen: "I think that it is advantageous to even have processing that treats the entire message as a whole."
• 2001-09- 6 SCOTT19U.ZIP_GUY: "That said is why I like "wrapped PCBC" Scott16u and scott19u treat the whole file as a single block."
• 2001-09- 6 Mok-Kong Shen: "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."
• 2001-09- 7 SCOTT19U.ZIP_GUY: "That is a false illusion that people who know little about crypto belive."
• 2001-09- 7 Mok-Kong Shen: "The error propagation property means the mutual 'influence' among the blocks."
• 2001-09- 7 SCOTT19U.ZIP_GUY: " . . . the user would falsely be assuming something like CBC unless told otherwise."
• 2001-09- 7 Mok-Kong Shen: ". . . 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."
• 2001-09- 7 SCOTT19U.ZIP_GUY: "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."
• 2001-09- 7 David Wagner: "I see no good reason to use predictable IV's, and good reasons to avoid them."
• 2001-09- 7 SCOTT19U.ZIP_GUY: "Seems look good reasoning to apply to CTR mode doesn't it?"
• 2001-09- 7 Tom St Denis: "Anyways CTR is provably information theoretically secure."
• 2001-09-15 Mark Wooding: "As usual, you don't understand what the maths says. It's not just the first block that's weak:"
• 2001-09- 6 John Savard: "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."
• 2001-09- 6 David Wagner: "It's a little-known rule of thumb that, when secrecy is a requirement of the system, a MAC is also called for."
• 2001-09- 8 Paul Crowley: "In theory, a One-Time-Pad provides perfect secrecy with very bad integrity."
• 2001-09- 8 David Wagner: ". . . 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."
• 2001-09- 5 David Wagner: "Actually, merely hashing the message (with, say, SHA, or some other unkeyed hash) and then CBC-encrypting is not sufficient to ensure security."
• 2001-09- 6 Mark Wooding: "A quick back-of-the-envelope computation shows that a CBC-encrypted hash isn't /too/ bad, actually . . . ."
• 2001-09- 6 David Wagner: "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."
• 2001-09- 7 Mark Wooding: "Please excuse me. I was talking absolute rubbish."
• 2001-09- 6 John Savard: "My mistake was that I thought it could only be garbled. Yes, this is a significant distinction."
• 2001-09- 6 John Savard: "I've now made it explicit that bit-flipping is possible against the _first_ block in CBC - and the _last_ block in CFB."
• 2001-09- 1 John Savard: "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."
• 2001-09- 1 Fritz Schneider: "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?"
• 2001-09- 1 Tom St Denis: "The old variant of Squafer was weakened in CBC mode but in ECB/CTR mode it was ok."
• 2001-09- 1 RDionysus: "--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...""
• 2001-09- 4 David Wagner: "Stallings is probably talking about integrity protection for the IV, not secrecy. And he's wrong here, anyway, if I understand correctly his argument."
• 2001-09- 4 David Wagner: "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."
• 2001-09- 3 Fritz Schneider: "The conclusion as I understand it is that with a public IV the scheme is secure, although CTR might be "better" from several standpoints."
• 2001-09- 4 RDionysus: "Thank you for the reference."
• 2001-09- 4 RDionysus: "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?"
• 2001-09- 4 David Wagner: "Well, it is still susceptible to "dictionary attacks", if the user chooses a guessable passphrase."
• 2001-09- 4 Bodo Moeller: ". . . 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 . . . ."
• 2001-09- 4 Bodo Moeller: ""[...] it is hard to imagine how these modes could be secure even with secret IVs if public IVs were a problem"."

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:

- You are concerned about active attacks.  However, for some mysterious
reason, you don't use a MAC or some other effective defense against it [1].

- You are concerned with modifications on the first block

- However, you are *not* concerned with other types of modifications.  For
example, you don't care if the attacker modifies plaintext block N (by
engibberishing plaintext block N-1).  You are further unconcerned about
cut-and-paste attacks.

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
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036


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
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Terry Ritter, his current address, and his top page.

Last updated: 2001-09-18