From akuchlin at mems-exchange.org  Mon Sep 17 19:45:14 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 17 Sep 2001 13:45:14 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
Message-ID: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>

After starting some discussion this spring about a standard hashing
API for Python, I kind of forgot about the issue for a long time.

As an effort at reviving it, I've updated the PEP, and the current
version is at http://python.sourceforge.net/peps/pep-0247.html.

Changes: renamed clear() to reset() (Rich Salz); added hexdigest()
method (Barry Warsaw); added digestsize attribute to objects (Andrew
Archibald).

There's one XXX issue left; what the reset() method does with a hash
that requires keys or other arguments.  The current text is:

        Reset this hashing object to its initial state, as if the
        object was created from new(key=<initially specified key>)
        (XXX what should this do for a keyed hash?  A proposed
        semantic follows:).  There is no way to supply a starting
        string as there is for the new() function, and there's no way
        to change the key specified for a keyed hash.

On further thought, the proposed semantic is bad, because it means
that objects will need to keep a copy of the key around.  I propose
that either 1) reset() raises an exception for hashes with parameters
-- changing the key or number of rounds would *always* require
creating a new object.  Or, 2) reset() takes the exact same arguments
as the constructor, and therefore the object can always be re-created
with any of its parameters being different.

1) is easier to implement, but 2) shouldn't be very hard.  The
constructor would probably initialize the C struct representing an
object, and then call reset() under the covers to do the argument
processing.  So, do people prefer 1 or 2?

--amk




From rsalz at ZOLERA.COM  Mon Sep 17 19:51:13 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Mon, 17 Sep 2001 13:51:13 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
References: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>
Message-ID: <3BA63811.E66DAB69@zolera.com>

slight preference for 2: reset() takes same args as __init__
--
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




From bram at GAWTH.COM  Mon Sep 17 20:27:14 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Mon, 17 Sep 2001 11:27:14 -0700
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.21.0109171123210.16257-100000@ultra.gawth.com>

On Mon, 17 Sep 2001, Andrew Kuchling wrote:

> As an effort at reviving it, I've updated the PEP, and the current
> version is at http://python.sourceforge.net/peps/pep-0247.html.

I rather like how sha.sha maps to the same thing as sha.new, so you can
say from sha import sha, that could be extended to the other hash
functions as well.

It would also be nice to have a convenience function for new(x).digest()

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From akuchlin at mems-exchange.org  Mon Sep 17 21:20:30 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 17 Sep 2001 15:20:30 -0400
Subject: [PYTHON-CRYPTO] CVS now open for SF pycrypto project
Message-ID: <E15j3wU-0004Fv-00@ute.cnri.reston.va.us>

At some point SourceForge got around to importing the CVS tree
(finally!) for the 'pycrypto' project
(http://sourceforge.net/cvs/?group_id=20937).  This means that commit
privileges can now be offered to anyone with a SourceForge account.

If you want commit privileges, please send me your SourceForge ID,
and join the checkins list at
http://lists.sourceforge.net/lists/listinfo/pycrypto-checkins .

Time to get this project moving again!

--amk




From akuchlin at mems-exchange.org  Mon Sep 17 22:12:55 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 17 Sep 2001 16:12:55 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <Pine.LNX.4.21.0109171123210.16257-100000@ultra.gawth.com>; from
              bram@GAWTH.COM on Mon, Sep 17, 2001 at 11:27:14AM -0700
References: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>
            <Pine.LNX.4.21.0109171123210.16257-100000@ultra.gawth.com>
Message-ID: <20010917161254.B16376@ute.mems-exchange.org>

On Mon, Sep 17, 2001 at 11:27:14AM -0700, Bram Cohen wrote:
>On Mon, 17 Sep 2001, Andrew Kuchling wrote:
>I rather like how sha.sha maps to the same thing as sha.new, so you can
>say from sha import sha, that could be extended to the other hash
>functions as well.

How come?  IMHO it's clearer to always use new() for creating a new
object. md5.md5() or sha.sha() don't make it clear what the return
value would be, at least in my eyes.

>It would also be nice to have a convenience function for new(x).digest()

-0 from me; it only shortens a single line.

--amk




From greg at ELECTRICRAIN.COM  Mon Sep 17 22:14:57 2001
From: greg at ELECTRICRAIN.COM (Gregory P. Smith)
Date: Mon, 17 Sep 2001 13:14:57 -0700
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <20010917161254.B16376@ute.mems-exchange.org>; from
              akuchlin@MEMS-EXCHANGE.ORG on Mon, Sep 17,
              2001 at 04:12:55PM -0400
References: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>
            <Pine.LNX.4.21.0109171123210.16257-100000@ultra.gawth.com>
            <20010917161254.B16376@ute.mems-exchange.org>
Message-ID: <20010917131457.B3681@zot.electricrain.com>

On Mon, Sep 17, 2001 at 04:12:55PM -0400, Andrew Kuchling wrote:
> On Mon, Sep 17, 2001 at 11:27:14AM -0700, Bram Cohen wrote:
> >On Mon, 17 Sep 2001, Andrew Kuchling wrote:
> >I rather like how sha.sha maps to the same thing as sha.new, so you can
> >say from sha import sha, that could be extended to the other hash
> >functions as well.
>
> How come?  IMHO it's clearer to always use new() for creating a new
> object. md5.md5() or sha.sha() don't make it clear what the return
> value would be, at least in my eyes.

I agree.  I think what Bram suggested above is better written as:

from sha import new as sha

(python 2+ ism)

-G




From bram at GAWTH.COM  Mon Sep 17 22:16:47 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Mon, 17 Sep 2001 13:16:47 -0700
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <20010917161254.B16376@ute.mems-exchange.org>
Message-ID: <Pine.LNX.4.21.0109171313140.16257-100000@ultra.gawth.com>

On Mon, 17 Sep 2001, Andrew Kuchling wrote:

> On Mon, Sep 17, 2001 at 11:27:14AM -0700, Bram Cohen wrote:
> >On Mon, 17 Sep 2001, Andrew Kuchling wrote:
> >I rather like how sha.sha maps to the same thing as sha.new, so you can
> >say from sha import sha
>
> How come?  IMHO it's clearer to always use new() for creating a new
> object. md5.md5() or sha.sha() don't make it clear what the return
> value would be, at least in my eyes.

I tend to say from sha import sha and then sha(x).digest instead of
sha.new(x).digest()

I forgot about import new as sha, that makes my point moot.

> >It would also be nice to have a convenience function for new(x).digest()
>
> -0 from me; it only shortens a single line.

What does -0 mean?

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From akuchlin at mems-exchange.org  Mon Sep 17 22:27:01 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 17 Sep 2001 16:27:01 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <Pine.LNX.4.21.0109171313140.16257-100000@ultra.gawth.com>; from
              bram@gawth.com on Mon, Sep 17, 2001 at 01:16:47PM -0700
References: <20010917161254.B16376@ute.mems-exchange.org>
            <Pine.LNX.4.21.0109171313140.16257-100000@ultra.gawth.com>
Message-ID: <20010917162701.C16376@ute.mems-exchange.org>

On Mon, Sep 17, 2001 at 01:16:47PM -0700, Bram Cohen wrote:
>> -0 from me; it only shortens a single line.
>
>What does -0 mean?

It's from the Apache voting guidelines
(http://dev.apache.org/guidelines.html), which are also loosely
followed by the python-dev group.  +1 means "yes, definitely, follow
this suggestion", -1 means "no, this is a bad idea.".  +/- 0 means
"abstain" or "I don't care about this suggestion", with the sign
indicating whether you lean toward positive or negative.  +0 is sort
of "oh, go ahead" and -0 is "why bother?"

So, my -0 meant I don't see the need for this, but if everyone else
likes the idea, then it can go in.

--amk




From akuchlin at mems-exchange.org  Tue Sep 18 16:51:11 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 18 Sep 2001 10:51:11 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
Message-ID: <20010918105111.A17774@ute.mems-exchange.org>

Here's a first cut at a secret-key encryption API.  It's very rough.
Note that the existing API in the Python cryptography modules is
rather silly at times.  I think it's worth breaking compatibility in
this specification if need be, in order to get a decent API.

--amk

PEP: XXX
Title: API for Secret-Key Encryption Algorithms
Version: $Revision: 1.3 $
Author: A.M. Kuchling <akuchlin at mems-exchange.org>
Status: Draft
Type: Informational
Created: 18-Sep-2001
Post-History:

Abstract

    This document specifies a standard API for secret-key encryption
    algorithms, such as DES or Rijndael, making it easier to switch
    between different algorithms and implementations.  The API is
    intended to be suitable for both block and stream ciphers.


Introduction

    Encryption algorithms transform their input data (called
    plaintext) in some way that is dependent on a variable key,
    producing ciphertext.  The transformation can easily be reversed,
    if and only if one knows the key (we hope).  The key is a sequence
    of bits chosen from some very large space of possible keys.

    Block ciphers take multibyte inputs of a fixed size (frequently 8
    or 16 bytes long) and encrypt them.  Block ciphers can be operated
    in various feedback modes.  The feedback modes supported in this
    specification are:

        Number    Constant      Description
        1         ECB           Electronic Code Book
        2         CBC           Cipher Block Chaining
        3         CFB           Cipher FeedBack
        4         PGP           Variant of CFB used by the OpenPGP standard

    In a strict formal sense, stream ciphers encrypt data bit-by-bit;
    practically, stream ciphers work on a character-by-character
    basis.  Stream ciphers use exactly the same interface as block
    ciphers, with a block length that will always be 1; this is how
    block and stream ciphers can be distinguished.  The only feedback
    mode available for stream ciphers is ECB mode.


Specification

    All cipher algorithms share a common interface.  After importing a
    given module, there is exactly one function and two variables
    available.

    Secret-key encryption modules define one function:

    new(key, mode, [IV], **kwargs)

    Returns a ciphering object, using the secret key contained in the
    string 'key', and using the feedback mode 'mode', which must be
    one of the constants from the following table.

    If 'mode' is CBC or CFB, 'IV' must be provided, and must be a
    string of the same length as the block size.  Not providing a
    value of 'IV' will result in a XXXError exception being raised.
    (what exception?  ValueError?  ciphermodule.error?)

    Depending on the algorithm, a module may support additional
    keyword arguments to this function.  The most common keyword
    argument will likely be 'rounds', to set the number of rounds to
    be used.

    Secret-key encryption modules define two variables:

    blocksize

        An integer value; the size of the blocks encrypted by this
        module.  For all feedback modes, the length of strings passed to
        the encrypt() and decrypt() must be a multiple of the block size.
        For stream ciphers, \code{blocksize} will be 1.

    keysize

        An integer value; the size of the keys required by this
        module.  If keysize is zero, then the algorithm accepts
        arbitrary-length keys.  You cannot pass a key of length 0
        (that is, the null string '') as such a variable-length key.

    All cipher objects have at least three attributes:

    blocksize

        An integer value equal to the size of the blocks encrypted by
        this object.  For algorithms with a variable block size, this
        value is equal to the block size selected for this object.

    IV

        Contains the initial value which will be used to start a
        cipher feedback mode; it will always be a string exactly one
        block in length.  After encrypting or decrypting a string,
        this value is updated to reflect the modified feedback text.
        It is read-only, and cannot be assigned a new value.

    keysize (XXX this is in mxCrypto, but do we actually need this?
        I can't remember why it was there, and it seems stupid.)

        An integer value equal to the size of the keys used by this
        object.  If keysize is zero, then the algorithm accepts
        arbitrary-length keys.  For algorithms that support variable
        length keys, this will be 0.  Identical to the module variable
        of the same name.  It does *not* contain the size of the key
        actually used to create this object.

    The methods for secret-key encryption objects are as follows:

    decrypt(string)

        Decrypts 'string, using the key-dependent data in the object,
        and with the appropriate feedback mode.  The string's length
        must be an exact multiple of the algorithm's block size.
        Returns a string containing the plaintext.

    encrypt(string)

        Encrypts a non-null string, using the key-dependent data in
        the object, and with the appropriate feedback mode.  The
        string's length must be an exact multiple of the algorithm's
        block size; for stream ciphers, the string can be of any
        length.  Returns a string containing the ciphertext.

    Here's an example, using a module named 'DES':

    >>> import DES
    >>> obj = DES.new('abcdefgh', DES.ECB)
    >>> plain="Guido van Rossum is a space alien."
    >>> len(plain)
    34
    >>> obj.encrypt(plain)
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
    ValueError: Strings for DES must be a multiple of 8 in length
    >>> ciph=obj.encrypt(plain+'XXXXXX')
    >>> ciph
    '\021,\343Nq\214DY\337T\342pA\372\255\311s\210\363,\300j\330\250\312\347\342I\3215w\03561\303dgb/\006'
    >>> obj.decrypt(ciph)
    'Guido van Rossum is a space alien.XXXXXX'


References

    RFC2440: "OpenPGP Message Format" (http://rfc2440.x42.com,
    http://www.faqs.org/rfcs/rfc2440.html)

    Applied Cryptography


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:




From rsalz at ZOLERA.COM  Tue Sep 18 16:56:31 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Tue, 18 Sep 2001 10:56:31 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
References: <20010918105111.A17774@ute.mems-exchange.org>
Message-ID: <3BA7609F.7D69F9EE@zolera.com>

For symmetric keys is it really important to distinguish between encrypt
and decrypt?  Or rather to insist on it?

Particularly as these are typically bulk encryption, I think a
file-oriented interface is more useful (and important -- i don't want to
keep two copies of my divx encoded video stream in core :).  Something
like
        arc4 = ARC4(.....
        arc.write('......')
        plain = arc4.read()
etc.  read and write calls can be intermixed.

--
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




From akuchlin at mems-exchange.org  Tue Sep 18 21:28:17 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Tue, 18 Sep 2001 15:28:17 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <3BA7609F.7D69F9EE@zolera.com>; from rsalz@zolera.com on Tue,
              Sep 18, 2001 at 10:56:31AM -0400
References: <20010918105111.A17774@ute.mems-exchange.org>
            <3BA7609F.7D69F9EE@zolera.com>
Message-ID: <20010918152817.H17774@ute.mems-exchange.org>

On Tue, Sep 18, 2001 at 10:56:31AM -0400, Rich Salz wrote:
>For symmetric keys is it really important to distinguish between encrypt
>and decrypt?  Or rather to insist on it?

Encryption and decryption are not necessarily symmetric, even if the
keys are.  Look at an explanation of IDEA, for example; see
http://home.ecn.ab.ca/~jsavard/crypto/co0404.htm .

>Particularly as these are typically bulk encryption, I think a
>file-oriented interface is more useful (and important -- i don't want to
>keep two copies of my divx encoded video stream in core :).  Something
>like
>       arc4 = ARC4(.....
>       arc.write('......')
>       plain = arc4.read()
>etc.  read and write calls can be intermixed.

Great idea!  Do you care more about programming convenience or raw
performance?  If it's convenience, that how about if encryption
modules simply registered a codec?  That way something like this would
work:

import codecs
f = codecs.open('output', 'wb', encoding='DES',
                key='...',
                mode= DES.ECB    # Hmm... that constant will be annoying.
                                 # Maybe the feedback mode should be a string?
               )
f.write('This will be encrypted\n')
f.close()

This would go through some layers of Python code, so it wouldn't be
absolutely optimal performance.  I'm reluctant to require that every
implementor of an encryption module re-implement sizable chunks of the
file object API (read(), readline(), writelines(), &c.)

Not sure how to handle padding...  Also, making this work will require
some patches to codecs.py, which I'll bring up on python-dev.

--amk




From rsalz at ZOLERA.COM  Wed Sep 19 06:01:16 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Wed, 19 Sep 2001 00:01:16 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
References: <20010918105111.A17774@ute.mems-exchange.org>
            <3BA7609F.7D69F9EE@zolera.com>
            <20010918152817.H17774@ute.mems-exchange.org>
Message-ID: <3BA8188C.FA0D9362@zolera.com>

I don't know codecs, but it seems okay.

My primary concern is not requiring all the data to be in memory at
once.  As long as some kind of streaming model is supported, I'm
satisfied.

> Encryption and decryption are not necessarily symmetric, even if the
> keys are.  Look at an explanation of IDEA, for example; see
> http://home.ecn.ab.ca/~jsavard/crypto/co0404.htm .

I always forget IDEA. :( thanks.

> This would go through some layers of Python code, so it wouldn't be
> absolutely optimal performance.  I'm reluctant to require that every
> implementor of an encryption module re-implement sizable chunks of the
> file object API (read(), readline(), writelines(), &c.)

I think read/write/close is enough.  But a simple mixin class that did
all the others is easy enough to write in a couple-dozen lines if really
needed.

> Not sure how to handle padding.

Right.  You can't pad until you know there's no more input coming in the
"to be encrypted" side.  Which means either another API or close() has
special semantics affecting only the write method.
        /r$

--
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com




From gerhard at bigfoot.de  Wed Sep 19 06:17:40 2001
From: gerhard at bigfoot.de (Gerhard =?iso-8859-1?Q?H=E4ring?=)
Date: Wed, 19 Sep 2001 06:17:40 +0200
Subject: Python's SSL: Would you like to help?
Message-ID: <20010919061739.A1243@lilith.hqd-internal>

Hello,

sorry for mailing you all at once, if you're not interested, just drop this
mail and nobody will know ;-)

According to undisclosed sources, you have some knowledge in both Python and
OpenSSL. As you might know, the OpenSSL support in Python itself is far from
perfect, that's why there exist several third-party packages that implement SSL
support for Python.

I myself am quite new to sockets and OpenSSL and all that stuff, but somehow I
decided that I wanted to fix the current problems with Python's OpenSSL support
(Guido van Rossum said that Pythonlabs people don't have the resources): 
http://sourceforge.net/tracker/index.php?func=detail&aid=461337&group_id=5470&atid=305470

I've just submitted a patch that tries to solve some of these problems:
http://sourceforge.net/tracker/index.php?func=detail&aid=462759&group_id=5470&atid=305470

If you have a few spare cycles, it would be much appreciated if you could
review the patch (and perhaps the SSL code in socketmodule.c, in the context of
which the patch is). That would help the Python community getting a stable,
basic OpenSSL implementation by default in Python 2.2.

Thanks for reading this far :-)

From my limited experience, I think the OpenSSL stuff in socketmodule.c is
quite broken. I think that it would be better to implement a new module
sslmodule.c in the Python standard library that would be largely interface
compatible with socketmodule.c, say .recv(), .send(), .makefile() methods and
so on.

If you have any interest in contributing to such an effort, please let me know.
Testing or code review only would of course be also important. But as I said, I
am a SSL newbie, I can't do it myself. Neither can Pythonlabs.

Many thanks,

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010919/8a5c06b5/attachment.pgp>

From bram at GAWTH.COM  Wed Sep 19 09:42:23 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Wed, 19 Sep 2001 00:42:23 -0700
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <20010918105111.A17774@ute.mems-exchange.org>
Message-ID: <Pine.LNX.4.21.0109190040050.19149-100000@ultra.gawth.com>

On Tue, 18 Sep 2001, Andrew Kuchling wrote:

> Here's a first cut at a secret-key encryption API.  It's very rough.
> Note that the existing API in the Python cryptography modules is
> rather silly at times.  I think it's worth breaking compatibility in
> this specification if need be, in order to get a decent API.

For what it's worth, my project uses rijndael in counter mode, which you
don't have included, and the API is that you call make_encrypter() and it
returns a function, which you call repeatedly passing different strings
and it encrypts them in order (it's not threadsafe). Decryption is done
using the same function. To be general you'd want this to be able to
specify big vs. little endian and the starting block.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From ngps at POST1.COM  Wed Sep 19 18:29:13 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Thu, 20 Sep 2001 00:29:13 +0800
Subject: [PYTHON-CRYPTO] [Announce] M2Crypto 0.07 snapshot #1 - now does
              FTP/TLS
Message-ID: <20010920002913.B437@madcap.dyndns.org>

Hello,

I am pleased to announce that M2Crypto 0.07 snapshot #1 is now available.
This snapshot features the following:

- FTP/TLS as specified in draft-murray-auth-ftp-ssl-07.txt.

    M2Crypto.ftpslib builds on Python's ftplib to provide client-side
    FTP/TLS functionality. (This uses blocking SSL sockets.)

    demo/medusa/ftps_server.py is based on Medusa's ftp_server.py and
    provides FTP/TLS server-side functionality. (This uses non-blocking
    SSL sockets and is currently the best demonstration of how to do so
    in M2Crypto.)

    Both M2Crypto client and server interoperate with each other, as well
    as with Peter Runestig's patched-for-TLS-and-portability OpenBSD FTP
    server and client.

- Improved SSL connect/accept methods. (Some minor API changes to come.)

- Fixed M2Crypto.m2urllib to handle HTTP redirects.


Next up, FTP/TLS for ZServerSSL/Zope!

This FTP/TLS implementation has been generously sponsored by me. ;-)

This snapshot is dedicated to the innocent victims of the 0911 terrorist
attacks on the US.


As usual, the snapshot is available here:

    http://www.post1.com/home/ngps/m2/

Your feedback is appreciated. Cheers.

--
Ng Pheng Siong <ngps at post1.com> * http://www.post1.com/home/ngps




From akuchlin at mems-exchange.org  Wed Sep 19 21:41:19 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 19 Sep 2001 15:41:19 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <3BA63811.E66DAB69@zolera.com>; from rsalz@ZOLERA.COM on Mon,
              Sep 17, 2001 at 01:51:13PM -0400
References: <E15j2SI-0004CS-00@ute.cnri.reston.va.us>
            <3BA63811.E66DAB69@zolera.com>
Message-ID: <20010919154119.B21359@ute.mems-exchange.org>

On Mon, Sep 17, 2001 at 01:51:13PM -0400, Rich Salz wrote:
>slight preference for 2: reset() takes same args as __init__

Any other opinions on this issue?  It's the last thing holding up
stamping the PEP "done".

To repeat the question: what should reset() for a hash that takes
keyword parameters do -- raise an exception, or accept the same
arguments as the constructor?

--amk




From richard at bizarsoftware.com.au  Thu Sep 20 03:48:26 2001
From: richard at bizarsoftware.com.au (Richard Jones)
Date: Thu, 20 Sep 2001 11:48:26 +1000
Subject: [PYTHON-CRYPTO] [Announce] M2Crypto 0.07 snapshot #1 - now
              does FTP/TLS
In-Reply-To: <20010920002913.B437@madcap.dyndns.org>
References: <20010920002913.B437@madcap.dyndns.org>
Message-ID: <0109201148262I.01597@ike>

On Thursday 20 September 2001 02:29, Ng Pheng Siong wrote:
> Next up, FTP/TLS for ZServerSSL/Zope!

Could I put in a strong vote for a distutils setup please? Pre-swigged is
fine. Actually, pre-swigged would be a really nice middle-ground, but a
disutils setup would be wonderful!


> This FTP/TLS implementation has been generously sponsored by me. ;-)

Very generous :)



     Richard




From itamarst at YAHOO.COM  Thu Sep 20 08:43:20 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Wed, 19 Sep 2001 23:43:20 -0700
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <20010919154119.B21359@ute.mems-exchange.org>
Message-ID: <20010920064320.28419.qmail@web13005.mail.yahoo.com>

--- Andrew Kuchling <akuchlin at MEMS-EXCHANGE.ORG>
wrote:

> To repeat the question: what should reset() for a
> hash that takes
> keyword parameters do -- raise an exception, or
> accept the same
> arguments as the constructor?

What is the point of having a reset() method at all?



=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/




From akuchlin at mems-exchange.org  Thu Sep 20 17:27:10 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Thu, 20 Sep 2001 11:27:10 -0400
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <20010920064320.28419.qmail@web13005.mail.yahoo.com>; from
              itamarst@YAHOO.COM on Wed, Sep 19, 2001 at 11:43:20PM -0700
References: <20010919154119.B21359@ute.mems-exchange.org>
            <20010920064320.28419.qmail@web13005.mail.yahoo.com>
Message-ID: <20010920112710.A22860@ute.mems-exchange.org>

On Wed, Sep 19, 2001 at 11:43:20PM -0700, Itamar S.-T. wrote:
>--- Andrew Kuchling <akuchlin at MEMS-EXCHANGE.ORG>
>What is the point of having a reset() method at all?

Erm... umm... hmm...  good point.  reset() isn't in Python's built-in
md5 and SHA modules at all, so it's an addition from the cryptography
modules.  I was younger and stupider in those days, so reset()
probably seemed like a good idea at the time.

So, forget it; I'll rip reset() out of the PEP and post it to
c.l.py.announce for any final comments, but the API is now done.

Thanks, everyone!

--amk




From michael at STROEDER.COM  Thu Sep 20 18:06:55 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 20 Sep 2001 18:06:55 +0200
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
References: <20010919154119.B21359@ute.mems-exchange.org>
            <20010920064320.28419.qmail@web13005.mail.yahoo.com>
            <20010920112710.A22860@ute.mems-exchange.org>
Message-ID: <3BAA141F.CD543EC5@stroeder.com>

Andrew Kuchling wrote:
>
> On Wed, Sep 19, 2001 at 11:43:20PM -0700, Itamar S.-T. wrote:
> >--- Andrew Kuchling <akuchlin at MEMS-EXCHANGE.ORG>
> >What is the point of having a reset() method at all?
>
> Erm... umm... hmm...  good point.  reset() isn't in Python's built-in
> md5 and SHA modules at all, so it's an addition from the cryptography
> modules.  I was younger and stupider in those days, so reset()
> probably seemed like a good idea at the time.
>
> So, forget it; I'll rip reset() out of the PEP and post it to
> c.l.py.announce for any final comments, but the API is now done.

reset() seems handy if creating an hash object takes some time.

E.g. JCA/JCE defines methods reset() without any parameters for
java.security.MessageDigest and javax.crypto.Mac. That seems to be
the same like your proposed semantic where the key has to be stored
in the object. Is that really a problem? Well, if someone pickles
and stores the HMAC object...

Ciao, Michael.




From bram at GAWTH.COM  Thu Sep 20 19:45:54 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Thu, 20 Sep 2001 10:45:54 -0700
Subject: [PYTHON-CRYPTO] Reviving PEP 247: Hashing API
In-Reply-To: <20010920112710.A22860@ute.mems-exchange.org>
Message-ID: <Pine.LNX.4.21.0109201045090.19149-100000@ultra.gawth.com>

On Thu, 20 Sep 2001, Andrew Kuchling wrote:

> On Wed, Sep 19, 2001 at 11:43:20PM -0700, Itamar S.-T. wrote:
> >--- Andrew Kuchling <akuchlin at MEMS-EXCHANGE.ORG>
> >What is the point of having a reset() method at all?
>
> Erm... umm... hmm...  good point.  reset() isn't in Python's built-in
> md5 and SHA modules at all, so it's an addition from the cryptography
> modules.  I was younger and stupider in those days, so reset()
> probably seemed like a good idea at the time.
>
> So, forget it; I'll rip reset() out of the PEP and post it to
> c.l.py.announce for any final comments, but the API is now done.

The mark of a mature programmer is willingness to throw out code you spent
time on when you realize it's pointless :-)

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From itamarst at YAHOO.COM  Fri Sep 21 12:44:30 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Fri, 21 Sep 2001 03:44:30 -0700
Subject: [PYTHON-CRYPTO] Random data API
Message-ID: <20010921104430.8818.qmail@web13003.mail.yahoo.com>

Hi everyone,

There is a need for a standard API for getting random
data to be used in cryptographic applications.

Background:
1) Random sources may rely on other such sources for
an initial seed. Therefore basic sources should be
built upon which more complex sources may be built.
2) Some sources may not be available on certain
platforms (/dev/urandom is not available on Windows).

This is my suggestion:

Each module implementing a source of random data must
provide two functions - new() and available(). The
arguments they get are determined by each module,
except that new() and available() must both accept the
same arguments.

available() returns a boolean telling us if this
source can be used or not. If the result is false the
output of new() is undefined.

new() returns an object, which has at least single
method, read(bytes). read() accepts one argument, an
integer, and returns a string of this length. The
object returned by new() may optionally have other
methods as well.
Should there be a meta-API allowing the user to get
the strongest available source?


For example, a source that reads from a file:
============================================

import os.path

class FileSource:
    def __init__(self, path):
        self.f = open(path, "rb")

    def read(self, bytes):
        return self.f.read(bytes)


def available(file="/dev/urandom"):
    return os.path.exists(file)

def new(file="/dev/urandom"):
    return FileSource(file)


=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/




From akuchlin at mems-exchange.org  Fri Sep 21 22:00:18 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 21 Sep 2001 16:00:18 -0400
Subject: [PYTHON-CRYPTO] Random data API
In-Reply-To: <20010921104430.8818.qmail@web13003.mail.yahoo.com>; from
              itamarst@YAHOO.COM on Fri, Sep 21, 2001 at 03:44:30AM -0700
References: <20010921104430.8818.qmail@web13003.mail.yahoo.com>
Message-ID: <20010921160018.A26053@ute.mems-exchange.org>

On Fri, Sep 21, 2001 at 03:44:30AM -0700, Itamar S.-T. wrote:
>new() returns an object, which has at least single
>method, read(bytes). read() accepts one argument, an
>integer, and returns a string of this length. The
>object returned by new() may optionally have other
>methods as well.

What about tracking the entropy and only returning a certain number of
bytes.  read() could just start returning "" when it runs out, or it
could raise an exception.  Perhaps there should be multiple levels of
support; at the minimum level only available() and new() are
supported, and the object only supports read().  Higher levels could
then define additional methods for checking how many bytes are left.

--amk




From rsalz at ZOLERA.COM  Fri Sep 21 22:08:10 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Fri, 21 Sep 2001 16:08:10 -0400
Subject: [PYTHON-CRYPTO] Random data API
References: <20010921104430.8818.qmail@web13003.mail.yahoo.com>
            <20010921160018.A26053@ute.mems-exchange.org>
Message-ID: <3BAB9E2A.FD4DEFA7@zolera.com>

yes, available() should be in the basic api and read should throw an
exception or block if not enough bytes are available, to avoid the risk
of someone ignoring "EOF"
        /r$

--
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




From bram at GAWTH.COM  Sat Sep 22 08:17:20 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Fri, 21 Sep 2001 23:17:20 -0700
Subject: [PYTHON-CRYPTO] Random data API
In-Reply-To: <20010921104430.8818.qmail@web13003.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0109210927010.10559-100000@ultra.gawth.com>

On Fri, 21 Sep 2001, Itamar S.-T. wrote:

> Each module implementing a source of random data must
> provide two functions - new() and available(). The
> arguments they get are determined by each module,
> except that new() and available() must both accept the
> same arguments.

I'd like a simpler approach - a single function called entropy.entropy()
or something like that which takes a number of bytes as an argument and
returns a random string of that length. It should block if it hasn't yet
gotten some minimum amount of entropy and never again after that (once you
have 100 or so bits of entropy you only re-seed to prevent continuation
attacks, which are mostly academic - blocking at that point just causes
performance problems with no security win).

Having another method which you could write random strings to for extra
seeding would be nice as well, although that's fairly obscure.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From itamarst at YAHOO.COM  Sat Sep 22 13:45:19 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Sat, 22 Sep 2001 04:45:19 -0700
Subject: [PYTHON-CRYPTO] Random data API
In-Reply-To: <Pine.LNX.4.21.0109210927010.10559-100000@ultra.gawth.com>
Message-ID: <20010922114519.50312.qmail@web13001.mail.yahoo.com>

--- Bram Cohen <bram at GAWTH.COM> wrote:

> I'd like a simpler approach - a single function
> called entropy.entropy()
> or something like that which takes a number of bytes
> as an argument and
> returns a random string of that length. It should
> block if it hasn't yet
> gotten some minimum amount of entropy and never
> again after that

What you are suggesting is an API for a single
standalone entropy source that is the "standard". It
doesn't take into account multiple sources, some of
which may not available on the current platform, nor
does it address letting people
 create their own sources that are (somewhat)
compatible on the API level.

If you are suggesting a single module level function
for getting entropy (this is probably a a better word
than "random", yes) instaed of having to create a new
object,  this doesn't address the need for
initialization in certain cases. In this case we have
two actions acting on the same object, which strongly
suggests the use of a class to encapsulate it.

Additionally, you may want to support multiple
instances so that one blocking doesn't prevent the
other ones from providing more entropy.


=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com




From michael at STROEDER.COM  Sat Sep 22 14:53:57 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Sep 2001 14:53:57 +0200
Subject: [PYTHON-CRYPTO] Random data API
References: <20010921104430.8818.qmail@web13003.mail.yahoo.com>
            <20010921160018.A26053@ute.mems-exchange.org>
            <3BAB9E2A.FD4DEFA7@zolera.com>
Message-ID: <3BAC89E5.11649301@stroeder.com>

Rich Salz wrote:
>
> yes, available() should be in the basic api and read should throw an
> exception or block if not enough bytes are available, to avoid the risk
> of someone ignoring "EOF"

I would prefer read() throwing an exception rather than blocking
behaviour.

Ciao, Michael.




From bram at GAWTH.COM  Sun Sep 23 01:04:24 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Sat, 22 Sep 2001 16:04:24 -0700
Subject: [PYTHON-CRYPTO] Random data API
In-Reply-To: <20010922114519.50312.qmail@web13001.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0109221558290.10559-100000@ultra.gawth.com>

On Sat, 22 Sep 2001, Itamar S.-T. wrote:

> What you are suggesting is an API for a single
> standalone entropy source that is the "standard". It
> doesn't take into account multiple sources

There are a number of counterintuitive properties of random number
generation, which are summarized pretty well in this paper -

http://www.counterpane.com/yarrow-notes.html

Random data from multiple sources can always be consolidated into a single
random number stream which is as cryptographically sound as the strongest
of the sources. Also, there's no need to block on new output once a
sufficient amount of entropy has been collected initially.

I'll happily write a PRNG kernel which handles entropy collation and
output generation properly if you need an example. The actual insertion of
entropy is, of course, a separate and necessarily platform-dependant
piece.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From rsalz at ZOLERA.COM  Tue Sep 25 05:09:21 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Mon, 24 Sep 2001 23:09:21 -0400
Subject: [PYTHON-CRYPTO] Comments on PEP 247 (Hashing)
Message-ID: <200109250309.f8P39Ln10632@zolera.com>

Discussions with my colleage here reminded me that I let some things
slip through the cracks.

1.  Why is there a new method; why isn't the classic constructor
    good enough?  The PEP needs to justify this.
2.  I'm concerned that the new([key],[string]) calling sequence
    makes ambiguity possible, mistaking a string for a key if
    not realizing I'm using HMAC, e.g.  I suggest removing the initial
    string.
3.  I'd like to see write available as a required synonym for update:
        print >>h, "This is what I'm talking about."




From itamarst at YAHOO.COM  Tue Sep 25 13:41:15 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Tue, 25 Sep 2001 04:41:15 -0700
Subject: [PYTHON-CRYPTO] Comments on PEP 247 (Hashing)
In-Reply-To: <200109250309.f8P39Ln10632@zolera.com>
Message-ID: <20010925114115.41498.qmail@web13008.mail.yahoo.com>

--- Rich Salz <rsalz at ZOLERA.COM> wrote:

> 1.  Why is there a new method; why isn't the classic
> constructor
>     good enough?  The PEP needs to justify this.

That way you don't have to worry about what the
constructor is called.

> 2.  I'm concerned that the new([key],[string])
> calling sequence
>     makes ambiguity possible, mistaking a string for
> a key if
>     not realizing I'm using HMAC, e.g.  I suggest
> removing the initial
>     string.

Maybe instead:
new(str="")
new(key, str="")

Having the initial string is useful:
digest = sha.new(str).digest()


=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com




From rsalz at ZOLERA.COM  Tue Sep 25 16:48:43 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Tue, 25 Sep 2001 10:48:43 -0400
Subject: [PYTHON-CRYPTO] Comments on PEP 247 (Hashing)
References: <20010925114115.41498.qmail@web13008.mail.yahoo.com>
Message-ID: <3BB0994B.7F2210C7@zolera.com>

> > 1.  Why is there a new method; why isn't the classic
> > constructor good enough?  The PEP needs to justify this.
>
> That way you don't have to worry about what the
> constructor is called.

This seems a weak argument.  My code already has to know what module to
import:
        from hash import SHA1
        s = SHA1.SHA1()
as opposed to
        from hash import SHA1
        s = SHA1.new()
or
        from hash import SHA1 as HASH
        s = HASH.new()

The first is the standard pythnon way to do things, the second shows no
gain for being non-standard, and the third seems like risky code.  Am I
missing something?

I think the PEP should (a) justify why new() is defined; and (b) define
standard Python constructor use.

> Maybe instead:
> new(str="")
> new(key, str="")
>
> Having the initial string is useful:
> digest = sha.new(str).digest()

If update() (or write() :) returned self, you could do
        digest = sha1.sha1().update(str).digest()

I don't care, as long as the initial text is an explicit keyword. :
        /r$
--
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




From itamarst at YAHOO.COM  Tue Sep 25 17:55:23 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Tue, 25 Sep 2001 08:55:23 -0700
Subject: [PYTHON-CRYPTO] Comments on PEP 247 (Hashing)
In-Reply-To: <3BB0994B.7F2210C7@zolera.com>
Message-ID: <20010925155523.81623.qmail@web13008.mail.yahoo.com>

--- Rich Salz <rsalz at zolera.com> wrote:

> If update() (or write() :) returned self, you could
> do
>       digest = sha1.sha1().update(str).digest()

Returning self is icky, in my opinion.

=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com




From itamarst at YAHOO.COM  Wed Sep 26 14:25:36 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Wed, 26 Sep 2001 05:25:36 -0700
Subject: [PYTHON-CRYPTO] Fwd: Re: Random data API
Message-ID: <20010926122536.98490.qmail@web13004.mail.yahoo.com>


Note: forwarded message attached.


=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
-------------- next part --------------
An embedded message was scrubbed...
From: Bram Cohen <bram at gawth.com>
Subject: Re: Random data API
Date: Mon, 24 Sep 2001 12:25:44 -0700 (PDT)
Size: 2722
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010926/d956e74a/attachment.mht>

From itamarst at YAHOO.COM  Wed Sep 26 14:26:03 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Wed, 26 Sep 2001 05:26:03 -0700
Subject: [PYTHON-CRYPTO] Fwd: Re: Random data API
Message-ID: <20010926122603.28522.qmail@web13008.mail.yahoo.com>


Note: forwarded message attached.


=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
-------------- next part --------------
An embedded message was scrubbed...
From: Bram Cohen <bram at gawth.com>
Subject: Re: Random data API
Date: Mon, 24 Sep 2001 11:15:19 -0700 (PDT)
Size: 1619
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010926/d3302610/attachment.mht>

From akuchlin at mems-exchange.org  Fri Sep 28 23:37:27 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 28 Sep 2001 17:37:27 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <Pine.LNX.4.21.0109190040050.19149-100000@ultra.gawth.com>; from
              bram@GAWTH.COM on Wed, Sep 19, 2001 at 12:42:23AM -0700
References: <20010918105111.A17774@ute.mems-exchange.org>
            <Pine.LNX.4.21.0109190040050.19149-100000@ultra.gawth.com>
Message-ID: <20010928173727.I30916@ute.mems-exchange.org>

On Wed, Sep 19, 2001 at 12:42:23AM -0700, Bram Cohen wrote:
>For what it's worth, my project uses rijndael in counter mode, which you
>don't have included, and the API is that you call make_encrypter() and it
>returns a function, which you call repeatedly passing different strings
>and it encrypts them in order (it's not threadsafe). Decryption is done

Where can I find a description of counter mode?  Should it be added as
one of the required feedback modes?

--amk




From akuchlin at mems-exchange.org  Fri Sep 28 23:55:40 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 28 Sep 2001 17:55:40 -0400
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <3BA8188C.FA0D9362@zolera.com>; from rsalz@ZOLERA.COM on Wed,
              Sep 19, 2001 at 12:01:16AM -0400
References: <20010918105111.A17774@ute.mems-exchange.org>
            <3BA7609F.7D69F9EE@zolera.com>
            <20010918152817.H17774@ute.mems-exchange.org>
            <3BA8188C.FA0D9362@zolera.com>
Message-ID: <20010928175540.J30916@ute.mems-exchange.org>

On Wed, Sep 19, 2001 at 12:01:16AM -0400, Rich Salz wrote:
>I think read/write/close is enough.  But a simple mixin class that did
>all the others is easy enough to write in a couple-dozen lines if really
>needed.

OK.  Well, I think there isn't much burning need to nail down the
codec implementation in this PEP, so it can focus on the basic module
API.  We can then put a codec in the amkCrypto distribution.

--amk




From bram at GAWTH.COM  Sat Sep 29 00:33:48 2001
From: bram at GAWTH.COM (Bram Cohen)
Date: Fri, 28 Sep 2001 15:33:48 -0700
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <20010928173727.I30916@ute.mems-exchange.org>
Message-ID: <Pine.LNX.4.21.0109281516380.20209-100000@ultra.gawth.com>

On Fri, 28 Sep 2001, Andrew Kuchling wrote:

> On Wed, Sep 19, 2001 at 12:42:23AM -0700, Bram Cohen wrote:
> >For what it's worth, my project uses rijndael in counter mode, which you
> >don't have included, and the API is that you call make_encrypter() and it
> >returns a function, which you call repeatedly passing different strings
> >and it encrypts them in order (it's not threadsafe). Decryption is done
>
> Where can I find a description of counter mode?  Should it be added as
> one of the required feedback modes?

Counter mode is where you take a encrypt 0, 1, 2, etc. with the key and
xor the resulting blocks with plaintext to get the ciphertext. Decryption
is done in the same way. It has big-endian and little-endian variants,
depending on how you translate the counter into a block. The main API
wrinkle is whether you want to allow the counter to be initially set to
something other than 0.

Counter mode isn't discussed much in the literature, mostly because it's
security properties are obvious enough that there isn't much interesting
to say about them (this is a good thing). It's a strict improvement on OFB
- random access is allowed, and there isn't a short cycle problem.

I'm in favor of it being supported, since I'm using it, and would like to
get my app back to being pure python again :-)

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes




From itamarst at YAHOO.COM  Sat Sep 29 02:14:43 2001
From: itamarst at YAHOO.COM (Itamar S.-T.)
Date: Fri, 28 Sep 2001 17:14:43 -0700
Subject: [PYTHON-CRYPTO] First draft of secret-key encryption PEP
In-Reply-To: <Pine.LNX.4.21.0109281516380.20209-100000@ultra.gawth.com>
Message-ID: <20010929001443.50504.qmail@web13003.mail.yahoo.com>

One comment -

I think that for compatability reasons the modes
should be at least the ones Java supports.

=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com