🚀 go-pugleaf

In article <1992Nov21.010043.4210@nwnexus.WA.COM>, 
ken@halcyon.com (Ken Pizzini) writes:

[stuff deleted...]

|> I don't see thay your "zipper" does anything but help protect the
|> first byte:
|>      outchar[2] = inchar[2] ^ key_stream[2] ^ outchar[1]
|> where outchar[1] is sitting right there in front of the cryptanalyst.

I get it.  I modified it so that zipper is no longer xor'd into the
output.  Now, (zipper modulo 113) is effectively added to the index
into the key_stream (skipping somewhere between 0 and 112 bytes of
key_stream).  Thus, I preserved my feedback, but in a way that is not
easily reversible.

Thanks, Ken.

BTW, I also added an initialization vector (based on keystroke delays, 
and some other factors), so that encrypting the same file twice with 
the same pass-phrase will produce totally different key streams.  The
initialization vector xor'd with a PRN (based on the text of the pass-
phrase) as the first byte of the ciphertext.

If you encrypt the same file twice with the same pass-phrase, you can
observe the following:

  ciphertext1[1] == init_vector1 ^ PRN
  ciphertext2[1] == init_vector2 ^ PRN

  thus,

  ciphertext1[1] ^ ciphertext2[1] == init_vector1 ^ init_vector2

Is there a way to deduce either initialization vector?

-- 
Peter K. Boucher
--
RIPEM public key available upon request.