[PYTHON-CRYPTO] Near-term projects for pycrypto

[Paul Rubin]

    > 6) Discard some of the more obscure algorithms (HAVAL, Diamond,
    > Skipjack, maybe CAST, RC5 and IDEA, too)

    Yes! Those are nothing but temptation to naive would-be protocol
    designers.

This is a good reason to dump them, and is relevant to the public key issue.

    With the built-in pow() function most public-key things are just a
    few lines, and given the difficulty of making APIs match up
    exactly with what people will want later I'd say it's best to let
    people do the few lines of code themselves. Exceptions include
    random prime generation, gcf and maybe dsa (since dsa's API is
    fairly clear.) I'm probably missing a few others.

The thing is, public key is very easy to screw up.  Look at the
controversy over OAEP padding for RSA for example, and OAEP was
designed by people who knew what they were doing.  Recently I had to
review someone's RSA implementation and they used no random padding at
all.

The same logic that says to remove obscure block ciphers also says:
implement public key and do it right, and remove the need for naive
implementers to mess it up.

    In any case, I agree that public key is a fairly separate set of issues,
    and am in favor of it being separated out.

I don't see why it's separate--if there's really something different
about it that I'm missing, then fine, separate it out, but it
shouldn't be simply dropped.

    > If the pycrypto [sha,md5] implementations are better (e.g., faster),
    > then keep them.  Otherwise drop them.

    If they're faster, they can be substituted in with a later version of
    Python.

I don't think it's Python's job to necessarily have the fastest
implementations of functions like this.  Think of doing matrix
arithmetic in Python vs. doing it in Numerical Python; or bignum
arithmetic in Python vs. gmpy.  It's reasonable for Python to have
some generic, portable implementation of a given function, while a
specialized library duplicates the functionality in a more highly
tuned implementation.  For example, the fastest SHA implementation
might have conditionalized hand-tuned assembly code for 10 different
machines.  The Python maintainers would never ship such a thing, but
it's reasonable for Pycrypto to include it.

    > OTOH I'd like to propose supporting SHA in output feedback mode
    > as a stream cipher.  The reason is that it can be implemented
    > efficiently in pure Python using the built-in sha library.  My
    > own crypto lib uses it for that reason.

    sha1 has some weaknesses in that mode, although they may be
    theoretical.  It's also extremely slow - there's a fair amount of
    padding sha1 does on the theory that most things hashed are quite
    large and a fixed amount of padding is no big deal, and sha1 isn't
    all that fast to begin with. An altogether more reasonable stream
    cipher is AES in counter mode, which is what I'm using.

If AES is made part of the standard python library, then that's great.
I'm talking about what can be done with just the standard library and
no add-ons.  I haven't been able to come up with anything faster than
SHA-OFB that has any hope of decent security.  It's 4x faster than RC4
coded in Python.

    > Also, a Yarrow-like PRNG should be added.

    hear hear! I have an entropy.entropy() function which takes a number and
    returns a random string containing that number of bytes. Under unix it
    initially seeds from /dev/random, but under Windows I had to completely
    punt it with something very ugly and not terribly secure.

Maybe Yarrow can be ported to Python for Windows and included in
pycrypt.  Under Unix, it suffices to use /dev/urandom and let the
system take care of entropy gathering.  I guess it's ok to have a flag
to insist on /dev/random instead of /dev/urandom.