Issue675698
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.
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) * | 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:12 | admin | set | github: 37846 |
2010-09-20 20:26:32 | intgr | set | nosy:
+ intgr |
2003-01-27 20:05:03 | phr | create |