Pure Python HTTPS Server

[Trevor Perrin]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7xd67zsfqg.fsf at ruckus.brouhaha.com>...
> trevp at trevp.net (Trevor Perrin) writes:
> > >  I proposed a standard block cipher API and wrote a
> > > sample implementation last year,
> > 
> > I like that API.  I wonder if there's any performance issues in
> > separating the codebook from the mode-of-operation, but I haven't
> > thought about that much.
> 
> If needed, the C-level API can be expanded so codebook modules have a
> way to communicate directly with the modes-of-operation module,
> without needing to do Python attribute lookups all the time.  But even
> without that optimization, I don't think the performance issues should
> be so bad.  The attribute lookup shouldn't be any slower than a
> codebook call, so if you do it just once when you invoke a chaining
> mode, the overhead for large buffers should be minimal.

Sounds good, as long as you don't have to do anything expensive
per-block.


> Do you happen to have a pure-Python DES implementation around?  I
> started writing one once, but it had some bug (i.e. it didn't pass
> FIPS test vectors) that I never got around chasing down.

I found one here:
http://home.pacific.net.au/~twhitema/des.html

It's too slow to do anything useful (that's DES's fault, I think, not
the progammer's).


> 
> Did you ever look at the key management scheme I circulated a while
> back?  Is it the kind of thing anyone cares about?

I didn't see that.  I did see that you've talked about a stdlib
interface to OS-level Random Number Generators, like /dev/urandom and
CryptGenRandom.  I think that's an excellent idea.

(aside from ciphers and RNGs, the other thing on my wish-list is
faster modular exponentiation..  Python use a simple right-to-left
square-and-multiply.  I'm no expert here, but I think it would be
pretty easy to make that a few times faster for crypto sized numbers. 
tlslite's handshaking, in python code, is ~5x slower than OpenSSL
right now..)


Trevor