rotor replacement

S

Skip Montanaro

Nick> I think one of the special things about Python is its batteries
Nick> included approach, and a crypto library would seem to be an
Nick> obvious battery to install since it doesn't (or needn't) depend on
Nick> any other library or application.

Obvious for some I suppose (I've never used any). While it might be
convenient to not have to distribute some third party library in addition to
Python, there is a fundamental problem implementing a crypto algorithm from
scratch for inclusion into Python. There is always the problem that the new
code has to be more rigorously tested than typical code and new bugs means a
new distribution of Python, not just a replacement library. A bug in code
that is not security-related generally means something doesn't work and only
rarely means a security hole has been opened on the computer. A bug in
security-related code more often means the latter as well. I'd much rather
trust a widely-disseminated piece of crypto code that is simply wrapped by
Python than one that was written expressly written for Python (and that will
likely not be exercised much outside the Python community).

I realize the sha module is incorporated this way. It has this comment:

* This code for the SHA algorithm was noted as public domain. The original
* headers are pasted below.
*
* Several changes have been made to make it more compatible with the
* Python environment and desired interface.

While I imagine the changes were fairly small, the guys involved are all
very smart, and the code is fairly straightforward (little, if any, memory
allocation going on), there is still the possibility that a bug lurks in
either the incorporated code or in the changes to it. How quickly could the
Python community respond if a bug was found and fixed in the public domain
SHA code? How much harder would it be for people to adapt if they had to
reinstall Python instead of just an external library?

Skip
 
P

Paul Rubin

Skip Montanaro said:
While it might be convenient to not have to distribute some third
party library in addition to Python, there is a fundamental problem
implementing a crypto algorithm from scratch for inclusion into
Python. There is always the problem that the new code has to be
more rigorously tested than typical code

Actually and surprisingly, that's not really true. Crypto algorithms
are pretty straightforward, so if you examine the code and check that
it passes a bunch of test vectors, you can be pretty sure it's
correct. It's much harder to check something like a compiler, which
has a much bigger state space, far more decision points, etc. The
usual bugs in crypto apps (and there are lots of such bugs) are in how
the primitives are used, not in the primitives themselves.
and new bugs means a new distribution of Python, not just a
replacement library.

Why would that be true of a crypto module and not true of, say, the socket
module? If the socket module has a bug that allows a remote takeover of
the application, that's as bad as a crypto bug.
A bug in code that is not security-related generally means something
doesn't work and only rarely means a security hole has been opened
on the computer. A bug in security-related code more often means
the latter as well.

People often don't understand that that almost all code is
security-related. Any code that touches data that came from the
internet is security related. If the math library arctangent function
has a buffer overflow bug triggered by a certain input number, and
someone uses math.arctan in an image viewing program, then maybe a
specially concocted image designed to set off the bug can take over
the user's computer. So even something like math.arctan is security
related.
While I imagine the changes were fairly small, the guys involved are
all very smart, and the code is fairly straightforward (little, if
any, memory allocation going on), there is still the possibility
that a bug lurks in either the incorporated code or in the changes
to it. How quickly could the Python community respond if a bug was
found and fixed in the public domain SHA code? How much harder
would it be for people to adapt if they had to reinstall Python
instead of just an external library?

If they're able to install external libraries, what stops them from
reinstalling a patched sha module?

The hazards of using a crypto module are sort of like the hazards of
using the threading module. Unless you know what you're doing and are
very careful, it's easy to make an error. But the resulting bugs
happen because the module did exactly what you asked for, not because
it did something different from what you asked for.

If you ever write code that uses the Internet, I highly recommend the
book "Security Engineering", by Ross Anderson. It will give you some
idea of what you are up against.
 
N

Nick Craig-Wood

Paul Rubin said:
Actually and surprisingly, that's not really true. Crypto algorithms
are pretty straightforward, so if you examine the code and check that
it passes a bunch of test vectors, you can be pretty sure it's
correct.

I was going to write pretty much the same thing.

If a security flaw is found in a block cipher (say) it won't be
because it has a buffer overflow etc, it will be because the algorithm
is flawed. You can't patch up crypto algorithms, you have to throw
them away and start again (you can't have two incompatible versions of
DES for instance).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top