Right, it sounds like the same approach I alluded to, except I didn't use a salt -- I just used a fast pseudon random number generator to make the IV less structured than using the block number directly.
I did some experiments with a used disk and found that if you use the block number directly for the IV, with CBC mode the block number and plaintext difference cancel to result in the same input text to the block cipher, resulting in the same ciphertext in a fair proportion of cases (don't have the figures handy, but clearly this not-insignificant number of collisions represents a leakage about the plaintext on the disk). The with aforementioned fast pseudo-random number generator I got no collisions on the disk sample size (10Gig disk almost full of windows application software and data). I figure that's good empirical evidence of the soundness of the approach, however another glitch may be if you consider that the attacker can work partly from the inside -- eg influencing the plaintext choice, as well as having read-only access to the ciphertext -- in this case he could perhaps build up a partial codebook for the cipher with the disk key, by influencing plaintext choices to create values equal to the suspected differences between plaintext and predicatable IVs. How do you salt the random number generator? Is it resistant to the above type of attack do you think? Adam On Sat, Apr 27, 2002 at 11:19:04AM +1000, Julian Assange wrote: > > You could encrypt twice (CBC in each direction or something), but that > > will again slow you down by a factor of 2. > > You can't easily get away with storing the IV as multiple parts of the IO > pipe like to see blocks in 2^n form. > > The approach I take in Rubberhose is to calculate the IV from a > very fast checksum routine and salt.
