lightweight encryption of text file

Paul Rubin at nospam.invalid
Mon Jan 11 05:27:55 CET 2010

Nobody <nobody at> writes:

> But, yeah, the OP needs to be aware of the difference (and probably isn't,
> yet). So to take that a step further ...
> The key passed to arcfour.schedule() shouldn't be re-used....
> If you need to verify the data, append a hash of the ciphertext ...
> If you want to encrypt multiple files with the same "password",
> generate a unique key by hashing a combination of the password and a
> random salt (e.g. from /dev/random)...

Yep, a whole lot of stuff that's easy to get wrong if it's left to the
user (for example, you mean "a MAC of the ciphertext", not "a hash of
the ciphertext"), and a lot of extra work even if the user gets it
right.  It's simplest for the library to provide a single interface that
does all of it.

>> It also looks rather slow.
> Any kind of bulk binary data processing in pure Python is slow. 

Well, slow is a relative term, but is about 5x faster than the
fastest pure-Python rc4 implementation that I compared it to.  Its
heavy lifting is done by the SHA and array modules, that are written in C.

More information about the Python-list mailing list