This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: New block cipher API
Type: Stage:
Components: None Versions:
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: collinwinter, intgr, phr
Priority: normal Keywords: patch

Created on 2003-01-27 20:05 by phr, last changed 2022-04-10 16:06 by admin. This issue is now closed.

Messages (4)
msg42549 - (view) Author: paul rubin (phr) Date: 2003-01-27 20:05
This is a preliminary, pure-Python implementation of a
new block cipher API, superseding PEP 272 (I've been in
contact with Andrew about it and he says it's ok). 
It's loosely patterned after the Java cipher classes,
but less fancy and maybe more Pythonic.  The API is
divided into two layers, a "codebook" layer which
implements a raw block cipher (like DES or AES), and a
"modes of operation" layer which implements the
standard FIPS modes (ECB, CTR, CBC, CFB, OFB) by
calling the codebook layer.  There's just one "modes of
operation" module, which can call any codebook
interchangeably.  This makes more sense to me than PEP
272, which required each codebook module to implement
all the FIPS modes itself.

I'm hoping to finalize the API and submit a C
implementation, along with C implementations of
DES/3DES and AES in time for 2.3a2.  I'm submitting
this Python version as a patch per Andrew's suggestion,
to get it onto the radar for upcoming releases.  The
Python version includes 64- and 128-bit block ciphers
based on the Luby-Rackoff construction with SHA1 as the
round function.  This is mainly for reference and
testing purposes--while these ciphers should be secure,
they're pretty slow and won't interoperate with
anything else out there.

There is a test harness included, "test.py", which
works under Linux and Cygwin.  It won't work under
Windows because it depends on a random number module
(included) that uses a Linux system device.  I have a
separate effort (i.e. search for volunteers with
Windows dev tools) to provide a Windows RNG that calls
the Windows CAPI to get random numbers.

Note: I haven't tested the Python implementation
extensively, since it's intended as a throwaway.  Don't
use it for anything serious.  Before submitting a C
module, I'll make sure that all the FIPS test vectors
work for all the modes.
msg42550 - (view) Author: paul rubin (phr) Date: 2003-01-27 20:09
Logged In: YES 
user_id=72053

Somehow the file attachment didn't work.  Oh well.  The
reference implementation is at:

http://www.nightsong.com/phr/crypto/blockcipher.tgz
msg42551 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-21 18:16
The referenced tarball's fips.py fails to import ("No module named aes"), and the four year-old c.l.p thread I found about this (http://mail.python.org/pipermail/python-list/2003-January/183331.html) didn't seem to go anywhere. If you're still interested in this, write up a formal proposal to amend or supersede PEP 272 and submit it to python-dev, targeting either Python 2.6 or 3000.
msg42552 - (view) Author: paul rubin (phr) Date: 2007-03-21 18:43
From the clpy discussion it became apparent that the maintainers weren't likely to accept a module like this for the distribution, because of concerns that distributing the crypto functions might cause legal problems in some countries.  If that has changed then I'm willing to do more work on the module.  

I do vaguely remember something about aes.py going missing.  If someone cares I can maybe figure out what happened.  However, it should be possible to test the module with just the sha1-based ciphers.
History
Date User Action Args
2022-04-10 16:06:12adminsetgithub: 37846
2010-09-20 20:26:32intgrsetnosy: + intgr
2003-01-27 20:05:03phrcreate