encyption could use an IV

[gim]

Stream ciphers are vulnerable to attacks when a key is used to encrypt multiple streams of data. To mitigate this an IV (initialisation vector, eg one block of random bits) could be prepended to the input data. This would lose the nice reversible encryption property but reduce one attack area.

More at: http://en.wikipedia.org/wiki/Stream_cipher_attack http://en.wikipedia.org/wiki/Initialization_vector

[rlp1938]

Have taken a bit of time to study the issue. It's already not quite reversible because I expect to use as encrypt once with source file deletion and decrypt often without the source file deletion. While I would never reuse a pass-phrase on different targets, it will be much safer to use an IV. Will do it that way.

[rlp1938]

Now using a 16 byte ascii representation of time() as an IV. Safe to re-use pass-phrases but now the -d option must be selected when the intention is to decrypt a previously encrypted file.

[gim]

• The representation of time you use does not guarantee the most significant bits of the IV may be set (ie, the last half of the IV is almost always zero) which only protects a portion of the data from the attack.
• The most significant bits only change very slowly, so large parts of data encrypted in (lets say) the same year could be vulnerable to the attack.
• Using a hex representation reduces the IV entropy greatly. eg, the most significant bit is never set.

I would recommend a scheme which guarantees each bit in the IV may be set. Either a strong source of randomness or at least passing something through a hash function.

Note: Please research whatever I've suggested; I am not a cryptographer.

[rlp1938]

At first I thought to defend the use of time() because my experiments generating sha256sums a second or so apart yielded completely different sums. Not surprising because message digests are designed to do just that. But it is just as easy to grab 8 bytes from /dev/random so I'll change the program to do just that. I'll use those bytes as is, not convert to hex.

"Using a hex representation reduces the IV entropy greatly. eg, the most significant bit is never set." That's the weakness of my entire system not just the IV. It affects the entire one time pad. I will look to encrypt with the 32 byte result buffer without the hex conversion.

I'm no cryptographer either. The itch I wanted to scratch is the fact that gpg is unscriptable. I will replace my attempt finally with RC5 or similar because the source code is published. That will be some time down the road after I have finished some more options.