From ngps at POST1.COM  Wed Mar 21 17:29:56 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Thu, 22 Mar 2001 00:29:56 +0800
Subject: [PYTHON-CRYPTO] M2Crypto 0.06 snapshot #3 -- ZSmime
Message-ID: <20010322002956.B1195@madcap.dyndns.org>

Hello,

M2Crypto 0.06 snapshot #3 is now available.

This release bundles ZSmime, a Zope product that enables Zope
to generate S/MIME-signed/encrypted messages. A HOWTO explains
its usage.

Win32 binaries for this snapshot will be available RSN.


Get M2Crypto here:

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


Info on ZSmime is here:

    http://www.post1.com/home/ngps/zope/zsmime


As usual, feedback is appreciated.
--
Ng Pheng Siong <ngps at post1.com> * http://www.post1.com/home/ngps




From greg at ELECTRICRAIN.COM  Fri Mar 23 00:08:49 2001
From: greg at ELECTRICRAIN.COM (Gregory P. Smith)
Date: Fri, 23 Mar 2001 00:08:49 +0100
Subject: [PYTHON-CRYPTO] Existing python APIs
Message-ID: <PYTHON-CRYPTO%2001032300202776@NIC.SURFNET.NL>

On Sun, 18 Feb 2001 01:03:56 +0800, Ng Pheng Siong <ngps at POST1.COM> wrote:

>
>> - Mojonation writes their own crypto.  It's slow.
>
>IIRC, Mojonation's crypto is from one of the well-known C/C++ libraries.
>The crypto shouldn't be slow; it's probably the bandwidth.
>

Mojo Nation uses Wei Dai's Crypto++ library.  Either v3.2 or v4.0 based on
flags given at compile time (v4.1 should work with no or minor tweaking; we
haven't tried).

What we've crudely wrapped from Crypto++ is the following:

* Modular arithmetic (modval module) used for RSA and other signature style
operations.
* DESX stream cipher in CBC mode (incorrectly named tripledescbc module)
* crypto++'s random number generator (randsource module)

The C++ used in Crypto++ is a *real* pain in the ass.  It makes heavy use of
templates, etc.  (read: a porting and wrapping nightmare).  We'd ultimately
prefer not to use Crypto++ and our custom interface at all if something
better (prefferably based on a C library such as OpenSSL) is available.




From aarchiba at YAHOO.COM  Fri Mar 23 10:22:31 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 23 Mar 2001 04:22:31 -0500
Subject: [PYTHON-CRYPTO] existing crypto APIs
In-Reply-To: <E14gEco-0001GM-00@imp>; from zooko@zooko.com on Thu, Mar 22,
              2001 at 03:36:14PM -0800
References: <E14gEco-0001GM-00@imp>
Message-ID: <20010323042231.A26364@hedgehog>

On Thu, Mar 22, 2001 at 03:36:14PM -0800, zooko at zooko.com wrote:
>
> I'm curious why Andrew Archibald thought that MN's crypto was slow!

I apologize.  I misread the code!  Sorry about that.  Between thinking that
everthing was written in python and noticing how slowly the crypto ran on
my machine I jumped to the conclusion that the underlying crypto is slow.
In the end it just seems that mojonation does a whole lot of work.  (And
some of your algorithms are slow, e.g., your random pool)

Sorry,
Andrew




From jason-list-python-crypto at MASTALER.COM  Fri Mar 23 19:06:51 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Fri, 23 Mar 2001 18:06:51 -0000
Subject: [PYTHON-CRYPTO] confused about state of crypto in python
Message-ID: <20010323180651.1769.qmail@nightshade.la.mastaler.com>

Greetings,

I'm trying to locate the "standard" implementation of popular
cryptography algorithms such as Blowfish, Twofish, and IDEA for Python
but have found this task more daunting than I originally anticipated.

A quick stroll through the search engines reveals a dizzying array of
code and modules, and no clear picture as to which packages are
supported, endorsed by Python, etc.  Some examples,

"mxCrypto", "amkCrypto", "pycrypt", "aescrypt", "twofishmodule", etc..

This is very confusing when coming from Perl, where the Crypto modules
are neatly organized in one place (http://search.cpan.org/Catalog/Security/)
and share a common API.

In fact, I'm not even sure if I'm asking this in the right place.  The
archives for this mailing list only show three articles for this
month, and the pycrypto-* lists at sourceforge are even emptier.

Can someone help me out here?

Thanks.




From aarchiba at YAHOO.COM  Fri Mar 23 22:51:23 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 23 Mar 2001 16:51:23 -0500
Subject: [PYTHON-CRYPTO] confused about state of crypto in python
In-Reply-To: <20010323180651.1769.qmail@nightshade.la.mastaler.com>; from
              jason-list-python-crypto@MASTALER.COM on Fri, Mar 23,
              2001 at 06:06:51PM -0000
References: <20010323180651.1769.qmail@nightshade.la.mastaler.com>
Message-ID: <20010323165123.B26364@hedgehog>

On Fri, Mar 23, 2001 at 06:06:51PM -0000, Jason R. Mastaler wrote:
> Greetings,
>
> I'm trying to locate the "standard" implementation of popular
> cryptography algorithms such as Blowfish, Twofish, and IDEA for Python
> but have found this task more daunting than I originally anticipated.

Heh.  Yes, it is daunting; the goal of this list is to solve that problem.

> A quick stroll through the search engines reveals a dizzying array of
> code and modules, and no clear picture as to which packages are
> supported, endorsed by Python, etc.  Some examples,
>
> "mxCrypto", "amkCrypto", "pycrypt", "aescrypt", "twofishmodule", etc..

mxCrypto: superseded by amkCrypto
pycrypt: superseded by mxCrypto
pyaes: not a generic module
twofishmodule: just has twofish

there is also m2crypto, which is used by Zope and is generic.

So you have two choices for a general-purpose crypto wrapper (that I know
of): amkCrypto and m2crypto.  amkCrypto is pretty nice, wrapping things in
a very convenient pythonic way, but this limits its security (python
strings are immutable and cannot be wiped, for example).  I have little
experience with m2crypto, but it seems to be a somewhat thinner wrapper of
OpenSSL.  It also does not allow wiping of data.

I would use amkCrypto.

> This is very confusing when coming from Perl, where the Crypto modules
> are neatly organized in one place (http://search.cpan.org/Catalog/Security/)
> and share a common API.

Is there some convenient API doc online?  What do you think of the API?
Should python's resemble it?

Thanks,
Andrew




From akuchlin at mems-exchange.org  Fri Mar 23 23:50:31 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 23 Mar 2001 17:50:31 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
Message-ID: <E14gaO7-00034o-00@ute.cnri.reston.va.us>

Here's an informational PEP describing the API for hashing that I
posted to the list last month.  This draft includes the suggested
revisions of dropping the hexdigest() method and adding clear(),
adding an optional key argument to the constructor for a hash object.

Comments requested; if there are none, then its status can be changed
to 'Accepted'.  (No PEP number allocated yet, but I've sent it off to
Barry to get one.)

--amk

PEP: XXX
Title: Standard API for Cryptographic Hash Algorithms
Status: Draft
Version: $Revision: 1.14 $
Author: A.M. Kuchling <amk1 at bigfoot.com>
Type: Informational
Created: 23-Mar-2001
Post-History:

Abstract

   There are several different modules available that implement
   cryptographic hashing algorithms such as MD5 or SHA.  This document
   specifies a standard API for such algorithms, to make it easier to
   switch between different implementations.


Specification

   All hashing modules should present the same interface.  Additional
   methods or variables can be added, but those described in this
   document should always be present.

   Hash function modules define one function:

   new([string], [key])

      Create a new hashing object and return it.  You can now feed
      arbitrary strings into the object using its update() method, and
      can ask for the hash value at any time by calling its digest()
      method.

      The 'string' parameter, if supplied, will be immediately hashed
      into the object's starting state.  For keyed hashes such as
      HMAC, 'key' is a string containing the starting key.

   Hash function modules define one variable:

   digest_size

      An integer value; the size of the digest produced by the
      hashing objects. You could also obtain this value by creating a
      sample object, and taking the length of the digest string it
      returns, but using digest_size is faster.

   The methods for hashing objects are always the following:

   clear ()

      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.

   copy ()

      Return a separate copy of this hashing object. An update to this
      copy won't affect the original object.

   digest ()

      Return the hash value of this hashing object, as a string
      containing 8-bit data. The object is not altered in any way by
      this function; you can continue updating the object after
      calling this function.

   update (arg)

      Update this hashing object with the string arg.

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

       >>> from Crypto.Hash import MD5
       >>> m = MD5.new()
       >>> m.update('abc')
       >>> m.digest()
       '\220\001P\230<\322O\260\326\226?@}(\341\177r'

   Or, more compactly:

       >>> MD5.new('abc').digest()
       '\220\001P\230<\322O\260\326\226?@}(\341\177r'


Copyright

    This document has been placed in the public domain.




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




From akuchlin at mems-exchange.org  Sat Mar 24 00:15:36 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Fri, 23 Mar 2001 18:15:36 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
In-Reply-To: <E14gaO7-00034o-00@ute.cnri.reston.va.us>; from
              akuchlin@mems-exchange.org on Fri, Mar 23,
              2001 at 05:50:31PM -0500
References: <E14gaO7-00034o-00@ute.cnri.reston.va.us>
Message-ID: <20010323181536.A12179@ute.cnri.reston.va.us>

On Fri, Mar 23, 2001 at 05:50:31PM -0500, Andrew Kuchling wrote:
>Here's an informational PEP...

To follow up to my own posting: are there any other lists where this
should be posted for discussion?  Is it worth posting to sci.crypt to
get opinions on it?

--amk




From aarchiba at YAHOO.COM  Sat Mar 24 04:36:41 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 23 Mar 2001 22:36:41 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
In-Reply-To: <E14gaO7-00034o-00@ute.cnri.reston.va.us>; from
              akuchlin@MEMS-EXCHANGE.ORG on Fri, Mar 23,
              2001 at 05:50:31PM -0500
References: <E14gaO7-00034o-00@ute.cnri.reston.va.us>
Message-ID: <20010323223641.D26364@hedgehog>

On Fri, Mar 23, 2001 at 05:50:31PM -0500, Andrew Kuchling wrote:
> Here's an informational PEP describing the API for hashing that I
> posted to the list last month.  This draft includes the suggested
> revisions of dropping the hexdigest() method and adding clear(),
> adding an optional key argument to the constructor for a hash object.
>
> Comments requested; if there are none, then its status can be changed
> to 'Accepted'.  (No PEP number allocated yet, but I've sent it off to
> Barry to get one.)
>
> --amk

I like it, in general, but I have a few comments:

Currently, sha objects have a digestsize attribute.  This is convenient;
should it be required by the PEP?

How common are variable-size hashes?  (For example, the SHA-160, SHA-256,
SHA-384, SHA-512 family)  Is it worth allowing a module to support multiple
digest sizes?  I would suggest allowing this by having such a module (say
SHA_variable) export a digestsize of 0.  Then new() can accept a digestsize
argument, and each object will have its own digestsize attribute.

Some hashes have additional parameters (HAVAL has a rounds parameter, I
believe); perhaps new should accept arbitrary additional keyword arguments?

What should unkeyed hashes do when presented with a key?  Presumably, raise
an exception.


Thanks,
Andrew




From rsalz at ZOLERA.COM  Sat Mar 24 06:01:14 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Sat, 24 Mar 2001 00:01:14 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
References: <E14gaO7-00034o-00@ute.cnri.reston.va.us>
Message-ID: <3ABC2A1A.D582242A@zolera.com>

Shouldn't clear() be reset() ?
        /r$




From michael at STROEDER.COM  Sat Mar 24 16:33:23 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 24 Mar 2001 16:33:23 +0100
Subject: [PYTHON-CRYPTO] confused about state of crypto in python
References: <20010323180651.1769.qmail@nightshade.la.mastaler.com>
Message-ID: <3ABCBE43.B99D70A3@stroeder.com>

"Jason R. Mastaler" wrote:
> 
> In fact, I'm not even sure if I'm asking this in the right place.  The
> archives for this mailing list only show three articles for this
> month, and the pycrypto-* lists at sourceforge are even emptier.

The good news: This is exactly the right place to discuss it.

The bad news: Although I started working on a proposal for a generic
API (see old posting below) I got stuck in other work since then.

Ciao, Michael.

-------- Original Message --------
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
Date: Sun, 18 Feb 2001 18:57:48 +0100
From: Michael Str?der <michael at STROEDER.COM>
Reply-To: Michael Str?der <michael at STROEDER.COM>
Organization: stroeder.com
To: PYTHON-CRYPTO at NIC.SURFNET.NL

HI!

I started to design the module layout, wrote some base classes for
hashs and the loader mechanism for my PyCrypto proposal. I did not
get as far as I wanted (yeah, social and commercial life... ;-) but
it's a start.

Please have a look at this small archive:


http://www.stroeder.com/python/PyCrypto/PyCrypto-proposal-2001-02-18.tar.gz

I will try to continously improve the documentation found on:

 http://www.stroeder.com/python/PyCrypto/proposal.html

I would like to follow this short-time roadmap:

1. Discuss open issues of loader mechanism and module layout:
 - Which key type for registry dictionary?
   OIDs? Which representation of OIDs? String vs. tuple.
 - Should we maintain the alias registry? How? dumpasn1.cfg?
 - Passing arguments in factory function
PyCrypto.registry.getInstance()
   to __init__() methods of implementation classes.
 - Performance? (mainly startup latency)
 - Implementors here should think about how to tie their modules to
   this loader.
 - Implementation registration unambigous and thread-safe?
 - Documentation of this part.

2. Discuss class API of algorithm implementations:
 - Hashes are easy and almost complete (see sources for examples).
 - Please provide some wrapper class examples for e.g. M2Crypto.
 - Collect as many requirements for cipher class API as possible
   + key formats
   + modes
   + etc.

Ciao, Michael.




From akuchlin at mems-exchange.org  Sat Mar 24 17:43:07 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Sat, 24 Mar 2001 11:43:07 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
In-Reply-To: <20010323223641.D26364@hedgehog>; from aarchiba@YAHOO.COM on Fri,
              Mar 23, 2001 at 10:36:41PM -0500
References: <E14gaO7-00034o-00@ute.cnri.reston.va.us>
            <20010323223641.D26364@hedgehog>
Message-ID: <20010324114307.A12725@ute.cnri.reston.va.us>

On Fri, Mar 23, 2001 at 10:36:41PM -0500, Andrew Archibald wrote:
>Currently, sha objects have a digestsize attribute.  This is convenient;
>should it be required by the PEP?

Good point; it can be added.  (Ditto for Rich Salz's suggestion of changing
clear() to reset().)

>How common are variable-size hashes?  (For example, the SHA-160, SHA-256,
>SHA-384, SHA-512 family)  Is it worth allowing a module to support multiple
>digest sizes?  I would suggest allowing this by having such a module (say
>SHA_variable) export a digestsize of 0.  Then new() can accept a digestsize
>argument, and each object will have its own digestsize attribute.

That seems reasonable.  An alternate way would be to have sha, sha256,
sha512 modules, but that would be a bit annoying.  (Though it's not clear to
me that there would be much sharing of code between SHA-{160,256,384,512}
implementations.

>Some hashes have additional parameters (HAVAL has a rounds parameter, I
>believe); perhaps new should accept arbitrary additional keyword arguments?

Yes; additional random keyword arguments would be allowed (they'd count as
extensions).  The PEP wouldn't specify them -- except maybe for 'rounds' --
but if there was a variable blocksize hash it could choose its own keyword.

>What should unkeyed hashes do when presented with a key?  Presumably, raise
>an exception.

Yes.  Hmm.. should there be a requires_key variable or function, and a
key_size value?

--amk




From rsalz at ZOLERA.COM  Sat Mar 24 18:34:38 2001
From: rsalz at ZOLERA.COM (Rich Salz)
Date: Sat, 24 Mar 2001 12:34:38 -0500
Subject: [PYTHON-CRYPTO] Draft hashing PEP
References: <E14gaO7-00034o-00@ute.cnri.reston.va.us>
            <20010323223641.D26364@hedgehog>
            <20010324114307.A12725@ute.cnri.reston.va.us>
Message-ID: <3ABCDAAE.772316EB@zolera.com>

> Yes.  Hmm.. should there be a requires_key variable or function, and a
> key_size value?

Well, presumably you know if you're doing a keyed hash or not, right?

So suppose the init function took a
        with_key=my_key_obj
parameter, where my_key_obj is
        class KeyedHashKey:
                def size(): return 0 # number of bits in the key
                def bits(): return 0 # the actual bits




From jason-list-python-crypto at MASTALER.COM  Mon Mar 26 20:52:49 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Mon, 26 Mar 2001 18:52:49 -0000
Subject: [PYTHON-CRYPTO] confused about state of crypto in python
In-Reply-To: <20010323165123.B26364@hedgehog> (Andrew Archibald's message of
              "Fri, 23 Mar 2001 16:51:23 -0500")
References: <20010323180651.1769.qmail@nightshade.la.mastaler.com>
            <20010323165123.B26364@hedgehog>
Message-ID: <20010326185249.12740.qmail@nightshade.la.mastaler.com>

Andrew Archibald <aarchiba at YAHOO.COM> writes:

> Heh.  Yes, it is daunting; the goal of this list is to solve that problem.

Glad to hear that.

> I would use amkCrypto.

Thanks for the clarification.

> Is there some convenient API doc online?  What do you think of the API?

Not that I can find, but perl Crypt modules generally implement the
Crypt::BlockCipher interface, which has the following methods:

       blocksize =item keysize =item encrypt =item decrypt

(from Crypt::Blowfish)

       blocksize
           Returns the size (in bytes) of the block cipher.

       keysize
           Returns the size (in bytes) of the key.

       new
                   my $cipher = new Crypt::Blowfish $key;

           This creates a new Crypt::Blowfish BlockCipher object,
           using $key, where $key is a key of `keysize()' bytes.

       encrypt
                   my $cipher = new Crypt::Blowfish $key;
                   my $ciphertext = $cipher->encrypt($plaintext);

           This function encrypts $plaintext and returns the
           $ciphertext where $plaintext and $ciphertext should be
           of `blocksize()' bytes.

       decrypt
                   my $cipher = new Crypt::Blowfish $key;
                   my $plaintext = $cipher->decrypt($ciphertext);

           This function decrypts $ciphertext and returns the
           $plaintext where $plaintext and $ciphertext should be
           of `blocksize()' bytes.

EXAMPLE
               my $key = pack("H16", "0123456789ABCDEF");
               my $cipher = new Crypt::Blowfish $key;
               my $ciphertext = $cipher->encrypt("plaintex");  # NB - 8 bytes
               print unpack("H16", $ciphertext), "\n";

--
Tired of receiving SPAM/UCE?  See <http://jason.mastaler.com/tms>




From jason-list-python-crypto at MASTALER.COM  Mon Mar 26 22:47:40 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Mon, 26 Mar 2001 20:47:40 -0000
Subject: [PYTHON-CRYPTO] amkCrypto RPM?
Message-ID: <20010326204740.12867.qmail@nightshade.la.mastaler.com>

Has anyone put together a Linux RPM for amkCrypto?

--
Tired of receiving SPAM/UCE?  See <http://jason.mastaler.com/tms>




From jason-list-python-crypto at MASTALER.COM  Mon Mar 26 22:53:11 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Mon, 26 Mar 2001 20:53:11 -0000
Subject: [PYTHON-CRYPTO] confused about state of crypto in python
In-Reply-To: <3ABCBE43.B99D70A3@stroeder.com> (Michael =?ISO-8859-1?Q?Str?=
              =?ISO-8859-1?Q?=F6der's?= message of "Sat, 24 Mar 2001 16:33:23
              +0100")
References: <20010323180651.1769.qmail@nightshade.la.mastaler.com>
            <3ABCBE43.B99D70A3@stroeder.com>
Message-ID: <20010326205311.12879.qmail@nightshade.la.mastaler.com>

Michael Str?der <michael at STROEDER.COM> writes:

> > In fact, I'm not even sure if I'm asking this in the right place.  The
> > archives for this mailing list only show three articles for this
> > month, and the pycrypto-* lists at sourceforge are even emptier.
> 
> The good news: This is exactly the right place to discuss it.

What is the story with the pycrypto-* lists at sourceforge then?

--
Tired of receiving SPAM/UCE?  See <http://jason.mastaler.com/tms>




From akuchlin at mems-exchange.org  Tue Mar 27 00:34:33 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Mon, 26 Mar 2001 17:34:33 -0500
Subject: [PYTHON-CRYPTO] amkCrypto RPM?
In-Reply-To: <20010326204740.12867.qmail@nightshade.la.mastaler.com>; from
              jason-list-python-crypto@MASTALER.COM on Mon, Mar 26,
              2001 at 08:47:40PM -0000
References: <20010326204740.12867.qmail@nightshade.la.mastaler.com>
Message-ID: <20010326173433.C21730@ute.cnri.reston.va.us>

On Mon, Mar 26, 2001 at 08:47:40PM -0000, Jason R. Mastaler wrote:
>Has anyone put together a Linux RPM for amkCrypto?

It uses the Distutils, so simply running "python setup.py bdist
--formats=rpm" should work, though I've never tried it.

--amk




From jason-list-python-crypto at MASTALER.COM  Tue Mar 27 23:29:05 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Tue, 27 Mar 2001 21:29:05 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
Message-ID: <20010327212905.9196.qmail@nightshade.la.mastaler.com>

I'm experimenting with amkCrypto, and I'm confused about the output
I'm getting back from a decrypted string.

        #!/usr/bin/env python
        import time
        from Crypto.Cipher import Blowfish
        key = '146bfea4ab7274e6f0ccff25351c2f39'
        cipherobj=Blowfish.new(key, Blowfish.CBC)
        input =  '%16d' % (time.time() +1)
        dated_cookie = cipherobj.encrypt(input)
        plaintext = cipherobj.decrypt(dated_cookie)

        print input
        print plaintext

This code produces the following output:
       985728133
?
-------------- next part --------------
?X~?
-------------- next part --------------
?{85728133

Why aren't input and plaintext identical?  The strings end the same,
but plaintext seems to have some binary characters at its beginning.

From jason-list-python-crypto at MASTALER.COM  Tue Mar 27 23:31:37 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Tue, 27 Mar 2001 21:31:37 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
Message-ID: <20010327213137.9205.qmail@nightshade.la.mastaler.com>

I'm experimenting with amkCrypto, and I'm confused about the output
I'm getting back from a decrypted string.

        #!/usr/bin/env python
        import time
        from Crypto.Cipher import Blowfish
        key = '146bfea4ab7274e6f0ccff25351c2f39'
        cipherobj=Blowfish.new(key, Blowfish.CBC)
        input =  '%16d' % (time.time() +1)
        dated_cookie = cipherobj.encrypt(input)
        plaintext = cipherobj.decrypt(dated_cookie)

        print input
        print plaintext

This code produces the following output where `*' is really a binary
character:

       985728133
********85728133

Why aren't input and plaintext identical?  The strings end the same,
but plaintext has some binary characters at its beginning.




From jason-list-python-crypto at MASTALER.COM  Tue Mar 27 23:44:28 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Tue, 27 Mar 2001 21:44:28 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: why 2-byte conversion for str2hex()?
Message-ID: <20010327214428.9225.qmail@nightshade.la.mastaler.com>

Why does Crypto.Utils.str2hex() convert each byte of its string to a
2-byte HEX representation (as opposed to a 1-byte HEX representation).

I ask because this might account for the difference in output I'm
seeing between two functionally equivalent pieces of code (one in
Perl, the other in Python).

        #!/usr/bin/env python

        import time
        from Crypto.Cipher import Blowfish
        key = '146bfea4ab7274e6f0ccff25351c2f39'
        cipherobj=Blowfish.new(key, Blowfish.CBC)
        input =  '%16d' % (time.time() +864000)
        from Crypto.Utils import str2hex
        dated_cookie = str2hex(cipherobj.encrypt(input))
        print dated_cookie

        -------------------------------------------------

        #!/usr/bin/perl

        use Crypt::Blowfish;
        $key = "146bfea4ab7274e6f0ccff25351c2f39";
        $cipherobj = new Crypt::Blowfish $key;
        $input = sprintf("%16d",time+864000);
        $dated_cookie = unpack("H*",$cipherobj->encrypt(pack("H*", $input)));
        print "$dated_cookie\n";

Their output:

        $ python datedcookie.py
        ec6bc328cbf0ab8c24a3ab68258bf773

        $ perl datedcookie.pl
        c9c7b6f9cb96e31c

As you can see, the Python code results in a string which is twice as
long as the original one, while the Perl code's string is the same
length as the original.  So it seems Perl converts to 1-byte HEX
instead of two.  Is there a way to convert to one-byte HEX in Python
as well?




From jason-list-python-crypto at MASTALER.COM  Wed Mar 28 02:43:39 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Wed, 28 Mar 2001 00:43:39 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010327213137.9205.qmail@nightshade.la.mastaler.com> ("Jason R.
              Mastaler"'s message of "Tue, 27 Mar 2001 21:31:37 -0000")
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
Message-ID: <20010328004339.9537.qmail@nightshade.la.mastaler.com>

"Jason R. Mastaler" <jason-list-python-crypto at MASTALER.COM> writes:

> I'm experimenting with amkCrypto, and I'm confused about the output
> I'm getting back from a decrypted string.
>
>         #!/usr/bin/env python
>         import time
>         from Crypto.Cipher import Blowfish
>         key = '146bfea4ab7274e6f0ccff25351c2f39'
>         cipherobj=Blowfish.new(key, Blowfish.CBC)
>         input =  '%16d' % (time.time() +1)
>         dated_cookie = cipherobj.encrypt(input)
>         plaintext = cipherobj.decrypt(dated_cookie)
>
>         print input
>         print plaintext
>
> This code produces the following output where `*' is really a binary
> character:
>
>        985728133
> ********85728133
>
> Why aren't input and plaintext identical?  The strings end the same,
> but plaintext has some binary characters at its beginning.

Strangely, if I create a new cipher object using ECB mode instead of
CBC mode, I no longer have this problem, but I'm unsure as to why this
makes a difference.  Here is the above piece of code with only line 5
changed:

         #!/usr/bin/env python
         import time
         from Crypto.Cipher import Blowfish
         key = '146bfea4ab7274e6f0ccff25351c2f39'
         cipherobj=Blowfish.new(key, Blowfish.ECB)
         input =  '%16d' % (time.time() +1)
         dated_cookie = cipherobj.encrypt(input)
         plaintext = cipherobj.decrypt(dated_cookie)

         print input
         print plaintext

Output:

       985740024
       985740024




From aarchiba at YAHOO.COM  Wed Mar 28 07:14:19 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Wed, 28 Mar 2001 00:14:19 -0500
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010327213137.9205.qmail@nightshade.la.mastaler.com>; from
              jason-list-python-crypto@MASTALER.COM on Tue, Mar 27,
              2001 at 09:31:37PM -0000
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
Message-ID: <20010328001418.B21110@hedgehog>

On Tue, Mar 27, 2001 at 09:31:37PM -0000, Jason R. Mastaler wrote:
> I'm experimenting with amkCrypto, and I'm confused about the output
> I'm getting back from a decrypted string.
>
>         #!/usr/bin/env python
>         import time
>         from Crypto.Cipher import Blowfish
>         key = '146bfea4ab7274e6f0ccff25351c2f39'
>         cipherobj=Blowfish.new(key, Blowfish.CBC)
>         input =  '%16d' % (time.time() +1)
>         dated_cookie = cipherobj.encrypt(input)
>         plaintext = cipherobj.decrypt(dated_cookie)
>
>         print input
>         print plaintext
>
> This code produces the following output where `*' is really a binary
> character:
>
>        985728133
> ********85728133
>
> Why aren't input and plaintext identical?  The strings end the same,
> but plaintext has some binary characters at its beginning.

You're using CBC mode, which has state (You should be supplying an IV when
you create the Blowfish object, BTW), and you're re-using a Blowfish
object.  That is, when you create a CBC-mode encryptor object, you supply
an initialization vector.  Every time you encrypt a block, the IV is XORed
into the plaintext, the result is encrypted, and the output replaces the
IV.  So if you encrypt the same string more than once with the same object,
you get different data.  This is a feature.

You probably want to be creating a new Blowfish object every time.
However, there is an undocumented feature of amkCrypto which allows you
to reset the IV (by assigning to cipherobj.IV) if creating new Blowfish
objects is too expensive.  If it's not, you should be using triple DES,
which will be faster and more secure (if prehaps not as sexy[1]) than
constantly re-keying Blowfish.

Andrew

[1]http://www.blowfish.com/




From jason-list-python-crypto at MASTALER.COM  Wed Mar 28 08:24:54 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Wed, 28 Mar 2001 06:24:54 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010328001418.B21110@hedgehog> (Andrew Archibald's message of
              "Wed, 28 Mar 2001 00:14:19 -0500")
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
            <20010328001418.B21110@hedgehog>
Message-ID: <20010328062454.9829.qmail@nightshade.la.mastaler.com>

Andrew Archibald <aarchiba at YAHOO.COM> writes:

> You're using CBC mode, which has state (You should be supplying an
> IV when you create the Blowfish object, BTW), and you're re-using a
> Blowfish object.  That is, when you create a CBC-mode encryptor
> object, you supply an initialization vector.  Every time you encrypt
> a block, the IV is XORed into the plaintext, the result is
> encrypted, and the output replaces the IV.  So if you encrypt the
> same string more than once with the same object, you get different
> data.  This is a feature.

So, if given a cipherobj.encrypt(string), the only way to get back the
identical plaintext string is to create a second Blowfish object with
the same key AND the same IV, and then use that to decrypt?  I thought
one only needed the key to go from ciphertext to plaintext?




From jason-list-python-crypto at MASTALER.COM  Wed Mar 28 20:42:34 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Wed, 28 Mar 2001 18:42:34 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: why 2-byte conversion for
              str2hex()?
In-Reply-To: <20010327214428.9225.qmail@nightshade.la.mastaler.com> ("Jason R.
              Mastaler"'s message of "Tue, 27 Mar 2001 21:44:28 -0000")
References: <20010327214428.9225.qmail@nightshade.la.mastaler.com>
Message-ID: <20010328184234.10412.qmail@nightshade.la.mastaler.com>

"Jason R. Mastaler" <jason-list-python-crypto at MASTALER.COM> writes:

> Why does Crypto.Utils.str2hex() convert each byte of its string to a
> 2-byte HEX representation (as opposed to a 1-byte HEX representation).
>
> I ask because this might account for the difference in output I'm
> seeing between two functionally equivalent pieces of code (one in
> Perl, the other in Python).

Ignore this, I figured out the difference.  The perl code was packing
the plaintext into a binary structure before encrypting, and the
python code wasn't.  I was able to accomplish something similar using
python's ``struct'' module.




From jason-list-python-crypto at MASTALER.COM  Wed Mar 28 22:19:04 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Wed, 28 Mar 2001 20:19:04 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010328001418.B21110@hedgehog> (Andrew Archibald's message of
              "Wed, 28 Mar 2001 00:14:19 -0500")
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
            <20010328001418.B21110@hedgehog>
Message-ID: <20010328201904.10469.qmail@nightshade.la.mastaler.com>

Andrew Archibald <aarchiba at YAHOO.COM> writes:

> if creating new Blowfish objects is too expensive.  If it's not, you
> should be using triple DES, which will be faster and more secure (if
> prehaps not as sexy[1]) than constantly re-keying Blowfish.

I'm a bit confused by what you are saying here.  I don't mind creating
a new blowfish object to decrypt a piece of ciphertext, but it
seems that to do this I must use both the same key and the same IV
that were used to produce that ciphertext.  Is this correct?

Secondly, why exactly is using triple DES any better than blowfish?
Does not DES3 require re-keying as well?

Thanks.




From aarchiba at YAHOO.COM  Wed Mar 28 22:38:04 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Wed, 28 Mar 2001 15:38:04 -0500
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010328201904.10469.qmail@nightshade.la.mastaler.com>; from
              jason-list-python-crypto@mastaler.com on Wed, Mar 28,
              2001 at 08:19:04PM -0000
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
            <20010328001418.B21110@hedgehog>
            <20010328201904.10469.qmail@nightshade.la.mastaler.com>
Message-ID: <20010328153804.C21110@hedgehog>

On Wed, Mar 28, 2001 at 08:19:04PM -0000, Jason R. Mastaler wrote:
> Andrew Archibald <aarchiba at YAHOO.COM> writes:
>
> > if creating new Blowfish objects is too expensive.  If it's not, you
> > should be using triple DES, which will be faster and more secure (if
> > prehaps not as sexy[1]) than constantly re-keying Blowfish.
>
> I'm a bit confused by what you are saying here.  I don't mind creating
> a new blowfish object to decrypt a piece of ciphertext, but it
> seems that to do this I must use both the same key and the same IV
> that were used to produce that ciphertext.  Is this correct?

Yes.  In CBC mode, you need both key and IV to decrypt the message.
However, the IV can safely be sent along with the message.  It should be
unique, so that the same message will encrypt to different things, but it
does not need to be secret.  Read Applied Cryptography, or if you have more
patience and less money, see the Handbook of Applied Cryptography, which is
available on-line.

> Secondly, why exactly is using triple DES any better than blowfish?
> Does not DES3 require re-keying as well?

3DES also requires re-keying.  The difference is that Blowfish has a very
expensive key schedule --- something like 5k of subkeys need to be set up,
which involves doing many Blowfish encryptions, every time you create a new
state.  (This needs to be done when you change the key, but it's an API
limitation that requires you to do it when you want to reset, eg, the
cipher state).  So re-keying 3DES will be quicker, and 3DES is more secure,
having had many many years of essentially unsuccessful cryptanalysis.

Andrew




From akuchlin at mems-exchange.org  Wed Mar 28 23:00:51 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 28 Mar 2001 16:00:51 -0500
Subject: [PYTHON-CRYPTO] Needed: public CVS repository for amkCrypto
Message-ID: <E14iN3j-0006ah-00@ute.cnri.reston.va.us>

I've noted the recent threads about bugs in amkCrypto, and feel bad
about not being able to spend time issuing a new release to fix them
(lack of time, and partially lack of interest).  An obvious solution
would be to set up a publicly accessible CVS tree somewhere, but
where?  SourceForge is obviously available, but it's inside the US; is
there a SourceForge-like site available in Europe?

--amk




From jason-list-python-crypto at MASTALER.COM  Thu Mar 29 00:33:43 2001
From: jason-list-python-crypto at MASTALER.COM (Jason R. Mastaler)
Date: Wed, 28 Mar 2001 22:33:43 -0000
Subject: [PYTHON-CRYPTO] amkCrypto: Cipher decrypt(string) output
In-Reply-To: <20010328153804.C21110@hedgehog> (Andrew Archibald's message of
              "Wed, 28 Mar 2001 15:38:04 -0500")
References: <20010327213137.9205.qmail@nightshade.la.mastaler.com>
            <20010328001418.B21110@hedgehog>
            <20010328201904.10469.qmail@nightshade.la.mastaler.com>
            <20010328153804.C21110@hedgehog>
Message-ID: <20010328223343.10779.qmail@nightshade.la.mastaler.com>

Andrew Archibald <aarchiba at YAHOO.COM> writes:

> 3DES also requires re-keying.  The difference is that Blowfish has a
> very expensive key schedule --- something like 5k of subkeys need to
> be set up, which involves doing many Blowfish encryptions, every
> time you create a new state.  (This needs to be done when you change
> the key, but it's an API limitation that requires you to do it when
> you want to reset, eg, the cipher state).  So re-keying 3DES will be
> quicker, and 3DES is more secure, having had many many years of
> essentially unsuccessful cryptanalysis.

Triple DES' fixed key-size rules it out for what I am working on.
Is there a "second best" cipher you would recommend then?

Thanks.




From ngps at POST1.COM  Fri Mar 30 18:04:49 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Sat, 31 Mar 2001 00:04:49 +0800
Subject: [PYTHON-CRYPTO] [ANN] M2Crypto 0.06-snap3 with Win32 binaries
Message-ID: <20010331000449.B1214@madcap.dyndns.org>

Hi,

M2Crypto 0.06 snapshot #3 with Win32 binaries is now available. As usual,
the binary package contains DLLs for both Python 1.5.2 and Python 2.0.

Get it here:

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


M2Crypto needs SWIG 1.1-786 (or thereabouts) to build from source.
Apparently, that package is now hard to find on the net. I've put up a
source tarball of it at url above.

I'm hoping to start a "testimonials" page. If M2Crypto has done some good
for you, I'll appreciate if you can drop me a note with a few words to be
quoted on my website. TIA! ;-)

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