I'm going to play with this to observe the behavior of the ciphertext, but I'm a priori skeptical that the ciphertext size will not approach the summed (compres

I'm going to play with this to observe the behavior of the ciphertext, but I'm a priori skeptical that the ciphertext size will not approach the summed (compressed) size of the original cleartexts. Otherwise, you'd achieve theoretically impossible compression (e.g., a million 1k texts compressed into n<<1Gbyte). I probably don't understand the requirements for the keys; do they need to be at least as long as the cleartext? Otherwise, there's a bug: With copies of keys and cleartexts from /usr/bin, I tried ./lenticrypt.py -e eqn shotwell -e grep php -o f1 php was the largest cleartext at 4388Kb. Memory use by lenticrypt stopped growing at 474Mb. The eqn and grep keys were both about 148k. After 15 minutes (on an admittedly rather old laptop, though very high end six years ago) and 57% encrypted, the program suddenly exited with no error and status 0, and f1 at a size of 6468K. Regrettably, bash-4.2$ ./lenticrypt.py -d eqn f1 > shotwell.d Found length header. File format version is 3 Traceback (most recent call last): File "./lenticrypt.py", line 773, in <module> for byte in decrypt(args.decrypt[1], args.decrypt[0]): File "./lenticrypt.py", line 630, in decrypt file_length = struct.unpack("<Q", raw_length)[0] struct.error: unpack requires a string argument of length 8 [Edit] the 15 minutes were spent with one core at about 100% CPU use. L1 cache 32k, L2 cache 4Mb, no L3 cache. DDR2-667 memory.