lightweight encryption of text file

[geremy condra]

On Sun, Jan 10, 2010 at 3:26 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> 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;

And having no dependencies frees you from the burden of testing
where your software will be deployed? I don't think so.

> 2) using a serious library requires quite a bit of knowledge
> and decision-making which not everyone is equipped to do.

Homebrewing is not a good solution to the problem of being
ignorant of modern cryptography.

> "AES" is not so simple to use unless you know what you're doing in
> terms of modes, nonces, etc.

Seems pretty simple to me- use AES 192, don't use ECB mode, and
use your library of choice's key strengthening utilities. Even blatantly
ignoring that advice would still probably give you better results than
homebrewing though, so I don't really see the issue here.

> 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
> revisited sometime.

I agree. I inquired about it not too long ago on python-ideas; little
serious discussion ensued.

Geremy Condra