SHA-based encryption function in Python

[Paul Rubin]

Bryan Olson <fakeaddress at nowhere.org> writes:
>  > 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."

Well, the original reason I wrote it was as part of a fancier crypto
module that would provide a bunch of additional functions:
  
  http://www.nightsong.com/phr/crypto.txt

so I figured anything fancier than simple string encryption/signing
would go there (that's just the docs-- your comments on them are
welcome too--I guess I can also upload the code, though I want to
reorganize it a little first).

However, I'm planning to write an AES module in C that would be less
kludgy (plus a lot faster) than this SHA thing.  So the fancy module
should be able to use AES in most situations.

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

Yes, that was my motivation too, both for writing it and for putting
some effort into making it run fast.

I think the politics though, at least in the US, have settled down to
the point where exporting AES shouldn't be a big problem, so a
standard AES module may be in Python's future.  That will obviate the
need for this thing if it happens.

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

I think most users just want to pass in a string and get back a
string, rather than a tuple.  If the user wants to get the pieces
back separately, there could be a separate entry point for that.

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

Your "budget" Celeron 1200 is about 10x faster than the "high end" 200
mhz StrongARM PDA that I plan to run this thing on ;-).  The point
about large files is that's the situation where you need to encrypt in
segments.  For smaller files, it's ok to encrypt all at once, which
the function already does.  FWIW, you could probably saturate your DSL
line (1.4 mbit/sec) with RC4 written in Python, though just barely.

Anyway, I'm ok with adding more entry points if it doesn't confuse
non-cryptographer users too much or if there's user demand.  If I want
to confuse people though, I have the whole fancier library for that ;-).

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

I'm not sure how this SHA-OFB in C would compare to AES in C or asm.
FWIW, I'd tried using SHA-CTR but I found that in Python, SHA-OFB is
faster, so I switched.  So this design is very much steered by details
of the implementation, usually not a good sign in protocols that are
supposed to be long-lived.  I think of this scheme as more of a
short-term hack (famous last words...).

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

I think RC4 has been popular because 1) it's already a standard (part
of SSL because of marketing stunts from a past era that wouldn't be so
easy to accomplish now); 2) it's extremely simple to implement even in
scripting languages; 3) it's extremely fast when coded in C or asm
(faster than AES).  SHA-OFB is none of the above.

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

I guess SHA-OFB support could be integrated into something like
OpenSSL, but would anyone really want to write an interoperating SSL
peer completely in Python using SHA-OFB?  The same question would
arise for SSH, IPSEC, and so forth.  Do you really want to hair up
those implementations with more silly ciphers?