MAL wrote:
Andrew Kuchling wrote:
On Tue, Sep 18, 2001 at 04:31:31PM -0400, Gordon McMillan wrote:
RC4, maybe. But I think you're asking for trouble in trying to pretend a block-mode cipher is a stream.
Dunno, but we'll hash that out on the python-crypto list. For now I just wanted to know if parametrized codecs would be an inherently bad idea.
(Two ways of handling this would be requiring all write() calls to use a multiple of the block size, or reporting an error on the close() if you haven't written out an even number of blocks. I have no idea which is preferable; not sure I like either of them...)
I guess you'll need some kind of buffering in the reader/writer to handle this situation. The cipher.py tools in mxCrypto does this already, so it may serve as template for the needed code.
Sigh. If it's a stream, you can hook a writer through IPC to a reader. Let's say the first 15 bytes are enough to tell the reading process whether it's interested in the rest. So unsupecting programmer sends 15 bytes to the writer, then waits for the reading process to tell him whether to continue.
And waits. And waits...
It's not a stream.
(This is getting off-topic though for this list...)
It is on-topic to the extent that python dev-vers should be encouraged not to violate certan well-established notions.
- Gordon