SHA-based encryption function in Python

[Bryan Olson]

Paul Rubin wrote:

 > I thought of adding a function that would allow encrypting in segments
 > but don't currently have applications that need that.  Remember that
 > the main goal of this code (and I didn't expect it to become such a
 > complicated project) was to just have something in portable Python
 > that could be used instead of the silly rotor module.

I'm surprised such a trivial goal interests you.  If this isn't worth
doing well, then I think it's just another case of "hey look - I
invented a cipher", and personally I respond to those with "O.K. throw
it on the 'unused' pile."

The reason I'm enthusiastic about this project is that it actually meets
a need.  Due to silly politics, a variety of programming environments
ship with SHA-1 and without a decent cipher.  The value here is in
creating a strong and efficient cipher without stepping outside the
native programming languages.

The definition of the cryptosystem is much more valuable than any
particular implementation.  If you don't have a need to encrypt in
segments while preserving state in-between, then fine don't implement
it.  The definition of the system should still have that potential.

The reference implementation I offered doesn't offer a piece-by-piece
facility either, but by separating the IV and MAC from the ciphertext,
it defines what such a system should produce.

 > It's slow
 > enough that it would be painful to encrypt large files with it.

Sure, but stand-alone (en/de)cryption a large file at one time is
usually a mistake.  Even my reference implementation, on my 'budget'
Celeron 1200, is fast enough to saturate my DSL line many times over.

A Python-only cipher is of little, maybe negative, value.  A cipher that
is very fast in C (or ASM) and moderately fast in a variety of scripting
languages could be a serious player.  We should aim for the big-time.


 > And
 > in an SSL-like protocol it still seems ok to encrypt-and-sign each
 > message.  (You couldn't implement real SSL with this module because of
 > the nonstandard cipher).

Well, I kind of disagree with the principle.  If this cipher is to be of
real value, we should definitely not assume it will always be
"nonstandard".  It's unlikely to be a FIPS, but it could be at least as
standard as RC4.

SSL/TLS is designed to support multiple ciphers.  Certainly support for
AES is coming.  There's no reason this cipher can't be included.  I see
little use for an "SSL-like" protocol.  Protocols are valuable if and
only if they are widely implemented.


--Bryan