lightweight encryption of text file

[Paul Rubin]

geremy condra <debatem1 at gmail.com> writes:
> And having no dependencies frees you from the burden of testing
> where your software will be deployed? I don't think so.

If you just use the stdlib and are a bit careful about OS dependent
features, your code can run pretty much everywhere.  More to the point,
if (say) you develop a pure Python app on Linux and a Windows user
reports a problem, you can probably straighten it out without having to
actually use a Windows development system.  If you need C extensions you
need Windows compilers.

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

Not sure what you're getting at.  If you're referring to p3.py as a
homebrew algorithm designed by someone ignorant, I don't think that is
accurate.  I've been a fulltime crypto developer, and p3.py was reviewed
by several experts on sci.crypt who all felt that its design is sound.
I don't claim it's suitable for high-value data (stick with something
standards-conformant for that) but it was designed as a replacement for
the now-defunct rotor module, and is just about certainly better in
every regard.  Its only cryptographic assumption is that SHA1(key+X) is
a pseudorandom function for fixed length X.  That is not a certified
characteristic of SHA1, but the HMAC standard (RFC 2104) is based on the
same assumption (see Krawczyk's paper cited in the RFC).  I'd go as far
as to say that it is just about certainly better than RC4, which has
well-known distinguishers of quite low complexity.

>> "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. 

That does not address any questions of authentication, ciphertext
malleability, IV generation, etc.  p3.py handles all of that with no
fuss imposed on the user.  Really, p3.py was written because the same
basic desire (simple, pure-Python encryption) kept coming up over and
over in my own code and others', and it really seems to address the
constraints about as well as anything I've been able to think of.