encryption with python?

[Paul Rubin]

Robert Kern <rkern at ucsd.edu> writes:
> > http://www.nightsong.com/phr/crypto/p3.py
> 
> [Ed Hotchkiss wrote:]
> > Awesome. I just started Python today so I'd have no idea ... how good is
> > this encryption compared to PGP?

p3.py's functionality is nothing like PGP: it just encrypts character
strings with a secret key.  It has no public key encryption, no key
management, etc.  Also, its algorithm is nonstandard since it's
designed for fast encryption speed using only the Python standard
library, since some applications run in environments where they don't
have enough control to use C extensions, yet they still have reasons
to want to encrypt stuff.  If you're doing a high security
application, you need control over your computing environment (enough
to be able to run C extensions, etc.) and not just your algorithms,
and so you should use a C extensions that follows a standard like AES.

You also reduce your legal liability exposure by following standards.
Imagine you choose some algorithm and it gets broken and you have to
explain to a jury why your software lost megabucks of your clients'
money, or whatever.  If you chose 3DES or AES, you can say you
followed the best advice of both the federal government and the
banking industry.  If you chose anything else, you're in deep mazola.
So even if you somehow calculate that p3.py has .002% chance of
getting broken and AES-EAX has .003% chance, the "objectively" worse
choice of AES is still preferable in that kind of application since
you could still get unlucky either way.

That said, the algorithm in p3.py should be reasonably sound for most
typical purposes.  Also, its API is extremely simple.  It's harder to
mess up with it than with a typical crypto library that gives you
lower level building blocks.  The main cost of that ease of use is
that the ciphertext is several dozen bytes longer than the plaintext.

> That said, it's Paul's own algorithm, so it hasn't been tested and
> attacked as thoroughly as PGP's algorithms. It relies on the security of
> the underlying hash. Unfortunately, that hash has been broken recently,
> although I'm not sure if that break actually affects the security of how
> it's used in this algorithm. Paul could tell you more.

I think that attack (an O(2**63) method for finding free collisions in
SHA1) doesn't apply here, since the attacker doesn't have control over
the input to the hash function.