lightweight encryption of text file
no.email at nospam.invalid
Sun Jan 10 21:26:05 CET 2010
geremy condra <debatem1 at gmail.com> writes:
> Not sure why in the world you would homebrew something like this- a
> small dependency isn't that bad, and aes can be pretty simple to use.
> Might as well go for the industrial strength approach.
In my experience, 1) small dependencies ARE that bad, since they mean
you have to develop and test on every platform that you want your code
to run on; 2) using a serious library requires quite a bit of knowledge
and decision-making which not everyone is equipped to do. "AES" is not
so simple to use unless you know what you're doing in terms of modes,
nonces, etc. Having supported this kind of package in a commercial
setting in the past, IMO, for the sort of (common) application in
question, it's best to keep things as simple as possible and supply a
single interface that provides encryption, authentication, and random
initialization all in one call. The cost is a little bit of ciphertext
bloat, but it prevents all kinds of security failures frequently
overlooked by novices.
I'd like it a lot if the Python stdlib could include a serious
cryptography module. That was rejected for regulatory reasons several
years ago, but maybe things are changing enough that the issue can be
More information about the Python-list