pycrypto-checkins — CVS checkins, and bug/patch notifications

[Pycrypto-checkins] CVS: crypto/src SHA256.c,1.4,1.5

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16121/src

Modified Files:
	SHA256.c 
Log Message:
Fix 32-bit length limitation in SHA256

Index: SHA256.c
===================================================================
RCS file: /cvsroot/pycrypto/crypto/src/SHA256.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SHA256.c	29 Nov 2005 16:31:36 -0000	1.4
+++ SHA256.c	29 Nov 2005 18:16:22 -0000	1.5
@@ -25,7 +25,8 @@
 #endif
 
 typedef struct {
-    U32 state[8], length, curlen;
+    U32 state[8], curlen;
+    U32 length_upper, length_lower;
     unsigned char buf[64];
 }
 hash_state;
@@ -100,7 +101,7 @@
 /* init the SHA state */
 void sha_init(hash_state * md)
 {
-    md->curlen = md->length = 0;
+    md->curlen = md->length_upper = md->length_lower = 0;
     md->state[0] = 0x6A09E667UL;
     md->state[1] = 0xBB67AE85UL;
     md->state[2] = 0x3C6EF372UL;
@@ -119,8 +120,13 @@
 
         /* is 64 bytes full? */
         if (md->curlen == 64) {
+	    U32 orig_length;
             sha_compress(md);
-            md->length += 512;
+	    orig_length = md->length_lower;
+            md->length_lower += 512;
+	    if (orig_length > md->length_lower) {
+	      md->length_upper++;
+	    }
             md->curlen = 0;
         }
     }
@@ -129,17 +135,22 @@
 void sha_done(hash_state * md, unsigned char *hash)
 {
     int i;
+    U32 orig_length;
 
     /* increase the length of the message */
-    md->length += md->curlen * 8;
+    orig_length = md->length_lower;
+    md->length_lower += md->curlen * 8;
+    if (orig_length > md->length_lower) {
+        md->length_upper++;
+    }
 
     /* append the '1' bit */
     md->buf[md->curlen++] = 0x80;
 
     /* if the length is currently above 56 bytes we append zeros
-                               * then compress.  Then we can fall back to padding zeros and length
-                               * encoding like normal.
-                             */
+     * then compress.  Then we can fall back to padding zeros and length
+     * encoding like normal.
+     */
     if (md->curlen > 56) {
         for (; md->curlen < 64;)
             md->buf[md->curlen++] = 0;
@@ -151,13 +162,11 @@
     for (; md->curlen < 56;)
         md->buf[md->curlen++] = 0;
 
-    /* since all messages are under 2^32 bits we mark the top bits zero */
-    for (i = 56; i < 60; i++)
-        md->buf[i] = 0;
-
     /* append length */
+    for (i = 56; i < 60; i++)
+        md->buf[i] = (md->length_upper >> ((59 - i) * 8)) & 255;
     for (i = 60; i < 64; i++)
-        md->buf[i] = (md->length >> ((63 - i) * 8)) & 255;
+        md->buf[i] = (md->length_lower >> ((63 - i) * 8)) & 255;
     sha_compress(md);
 
     /* copy output */

[Pycrypto-checkins] CVS: crypto ChangeLog,1.37,1.38

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16121

Modified Files:
	ChangeLog 
Log Message:
Fix 32-bit length limitation in SHA256

Index: ChangeLog
===================================================================
RCS file: /cvsroot/pycrypto/crypto/ChangeLog,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ChangeLog	29 Nov 2005 16:31:36 -0000	1.37
+++ ChangeLog	29 Nov 2005 18:16:21 -0000	1.38
@@ -4,6 +4,9 @@
 
 	* Fix padding bug in SHA256; this resulted in bad digests whenever
 	  (the number of bytes hashed) mod 64 == 55.
+	* Fix a 32-bit limitation on the length of messages the SHA256 module 
+	  could hash.
+
 
 2.0.1
 =====

[Pycrypto-checkins] CVS: crypto/test test_hashes.py,1.4,1.5

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/test
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15214/test

Modified Files:
	test_hashes.py 
Log Message:
Test SHA256 on 512Mb and 520 Mb of zeros

Index: test_hashes.py
===================================================================
RCS file: /cvsroot/pycrypto/crypto/test/test_hashes.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- test_hashes.py	13 Aug 2004 22:23:12 -0000	1.4
+++ test_hashes.py	29 Nov 2005 18:12:11 -0000	1.5
@@ -39,7 +39,20 @@
         self.test_val('obj.digest()', result)
         self.test_val('obj.copy().digest()', result)
 
+    def hash_large_file (self, hash_mod, size, hex_result):
+        obj = hash_mod.new()
+        zeros = 1024*1024*10*'\0'        
+        count = 0
 
+        while count < size:
+            diff = size-count
+            block_size = min(diff, len(zeros))
+            obj.update(zeros[:block_size])
+            count += block_size
+
+        self.test_val('obj.hexdigest()', hex_result)
+        
+        
     def run_test_suite (self, hash_mod, test_vectors):
         for text, digest in test_vectors:
             self.compare(hash_mod, text, digest)
@@ -84,8 +97,12 @@
     def check_sha256 (self):
         "SHA256 module"
         self.run_test_suite(SHA256,testdata.sha256)
+        self.hash_large_file(SHA256, 512 * 1024 * 1024,
+                             '9acca8e8c22201155389f65abbf6bc9723edc7384ead80503839f49dcc56d767')
+        self.hash_large_file(SHA256, 520 * 1024 * 1024,
+                             'abf51ad954b246009dfe5a50ecd582fd5b8f1b8b27f30393853c3ef721e7fa6e')
         self.benchmark(SHA256)
-
+        
 # class HashTest
 
 

[Pycrypto-checkins] CVS: crypto/src SHA256.c,1.3,1.4

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21439/src

Modified Files:
	SHA256.c 
Log Message:
Fix SHA256 padding bug

Index: SHA256.c
===================================================================
RCS file: /cvsroot/pycrypto/crypto/src/SHA256.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SHA256.c	10 Jun 2005 19:22:55 -0000	1.3
+++ SHA256.c	29 Nov 2005 16:31:36 -0000	1.4
@@ -136,11 +136,11 @@
     /* append the '1' bit */
     md->buf[md->curlen++] = 0x80;
 
-    /* if the length is currenlly above 56 bytes we append zeros
+    /* if the length is currently above 56 bytes we append zeros
                                * then compress.  Then we can fall back to padding zeros and length
                                * encoding like normal.
                              */
-    if (md->curlen >= 56) {
+    if (md->curlen > 56) {
         for (; md->curlen < 64;)
             md->buf[md->curlen++] = 0;
         sha_compress(md);

[Pycrypto-checkins] CVS: crypto ChangeLog,1.36,1.37

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21439

Modified Files:
	ChangeLog 
Log Message:
Fix SHA256 padding bug

Index: ChangeLog
===================================================================
RCS file: /cvsroot/pycrypto/crypto/ChangeLog,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- ChangeLog	14 Jun 2005 00:22:35 -0000	1.36
+++ ChangeLog	29 Nov 2005 16:31:36 -0000	1.37
@@ -1,4 +1,10 @@
 
+2.0.2
+=====
+
+	* Fix padding bug in SHA256; this resulted in bad digests whenever
+	  (the number of bytes hashed) mod 64 == 55.
+
 2.0.1
 =====
 

[Pycrypto-checkins] CVS: crypto/test testdata.py,1.6,1.7

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/test
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21439/test

Modified Files:
	testdata.py 
Log Message:
Fix SHA256 padding bug

Index: testdata.py
===================================================================
RCS file: /cvsroot/pycrypto/crypto/test/testdata.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- testdata.py	29 Nov 2005 16:28:51 -0000	1.6
+++ testdata.py	29 Nov 2005 16:31:36 -0000	1.7
@@ -120,6 +120,8 @@
     		    "5e3dfe0cc98fd1c2de2a9d2fd893446da43d290f2512200c515416313cdf3192"),
 		   ("Rijndael is AES" * 1024, 
   	 	    "80fced5a97176a5009207cd119551b42c5b51ceb445230d02ecc2663bbfb483a"),
+                   ('This message is precisely 55 bytes long, to test a bug.',
+                    'f7fd017a3c721ce7ff03f3552c0813adcc48b7f33f07e5e2ba71e23ea393d103'),
 ]
 
 # DES validation data

[Pycrypto-checkins] CVS: crypto setup.py,1.30,1.31

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21188

Modified Files:
	setup.py 
Log Message:
Bump version

Index: setup.py
===================================================================
RCS file: /cvsroot/pycrypto/crypto/setup.py,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- setup.py	14 Jun 2005 01:20:22 -0000	1.30
+++ setup.py	29 Nov 2005 16:30:22 -0000	1.31
@@ -127,7 +127,7 @@
         self.extensions += exts
 
 kw = {'name':"pycrypto",
-      'version':"2.0.1",
+      'version':"2.0.2",
       'description':"Cryptographic modules for Python.",
       'author':"A.M. Kuchling",
       'author_email':"am...@am...",

[Pycrypto-checkins] CVS: crypto/test testdata.py,1.5,1.6

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/test
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20901/test

Modified Files:
	testdata.py 
Log Message:
Remove debug code which truncated the test suite

Index: testdata.py
===================================================================
RCS file: /cvsroot/pycrypto/crypto/test/testdata.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- testdata.py	1 Aug 2004 18:53:31 -0000	1.5
+++ testdata.py	29 Nov 2005 16:28:51 -0000	1.6
@@ -121,7 +121,6 @@
 		   ("Rijndael is AES" * 1024, 
   	 	    "80fced5a97176a5009207cd119551b42c5b51ceb445230d02ecc2663bbfb483a"),
 ]
-sha256 = sha256[:1]
 
 # DES validation data
 

[Pycrypto-checkins] CVS: crypto/Doc pycrypt.tex,1.24,1.25

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto/Doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20294/Doc

Modified Files:
	pycrypt.tex 
Log Message:
Bump version

Index: pycrypt.tex
===================================================================
RCS file: /cvsroot/pycrypto/crypto/Doc/pycrypt.tex,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- pycrypt.tex	14 Jun 2005 01:20:22 -0000	1.24
+++ pycrypt.tex	29 Nov 2005 16:24:52 -0000	1.25
@@ -2,7 +2,7 @@
 
 \title{Python Cryptography Toolkit}
 
-\release{2.0.1}
+\release{2.0.2}
 
 \author{A.M. Kuchling}
 \authoraddress{\url{www.amk.ca}}

[Pycrypto-checkins] CVS: crypto __init__.py,1.12,1.13

[A.M. K. <aku...@us...>]

Update of /cvsroot/pycrypto/crypto
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20294

Modified Files:
	__init__.py 
Log Message:
Bump version

Index: __init__.py
===================================================================
RCS file: /cvsroot/pycrypto/crypto/__init__.py,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- __init__.py	14 Jun 2005 01:20:22 -0000	1.12
+++ __init__.py	29 Nov 2005 16:24:52 -0000	1.13
@@ -19,7 +19,7 @@
 
 __all__ = ['Cipher', 'Hash', 'Protocol', 'PublicKey', 'Util']
 
-__version__ = '2.0.1'
+__version__ = '2.0.2'
 __revision__ = "$Id$"
 
 

[Pycrypto-checkins] [ pycrypto-Bugs-1364920 ] bug in Zooko's fast-CTR-mode patch

[SourceForge.net <no...@so...>]

Bugs item #1364920, was opened at 2005-11-23 19:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in Zooko's fast-CTR-mode patch

Initial Comment:
My patch for fast CTR mode (all in C -- no Python) has
a bug in that it isn't "restartable" -- if you encrypt
or decrypt some data which is not itself a multiple of
the block length, then subsequent calls to
encrypt/decrypt will give incorrect results.

I'll make fixes for this soon.  In the meantime, here's
a unit test showing how it doesn't work.

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches

Wed Nov 23 15:00:57 AST 2005  zo...@zo...
  * add unit test that shows that CTR mode is not
restartable -- this is a bug
diff -rN -u
old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py
new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py
---
old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py
2005-11-23 15:06:39.000000000 -0400
+++
new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py
2005-11-23 15:06:39.000000000 -0400
@@ -146,6 +146,23 @@
     print_timing(256, end-start, verbose)
     del obj1, obj2
 
+    if verbose: print '  CTR mode, variable length,
restart:',
+    strv = str[:-1]
+    obj1=ciph.new(password, ciph.MODE_CTR,
counterstart=long_to_bytes(startctr, ciph.block_size))
+    obj2=ciph.new(password, ciph.MODE_CTR,
counterstart=long_to_bytes(startctr, ciph.block_size))
+    start=time.time()
+    tempstrv = strv
+    while tempstrv:
+        chunksiz = random.randrange(1, len(tempstrv)+1)
+        ciphertext = obj1.encrypt(tempstrv[:chunksiz])
+        tempstrv = tempstrv[chunksiz:]
+    plaintext=obj2.decrypt(ciphertext)
+    end=time.time()
+    if (plaintext!=strv):
+        die('Error in resulting plaintext from CTR
mode, variable length, restart')
+    print_timing(256, end-start, verbose)
+    del obj1, obj2
+
     # Test the IV handling
     if verbose: print '  Testing IV handling'
     obj1=ciph.new(password, ciph.MODE_CBC, IV)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1343753 ] winrand.c in CryptAcquireContext raises NTE_BAD_KEYSET

[SourceForge.net <no...@so...>]

Bugs item #1343753, was opened at 2005-10-31 04:34
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: winrand.c in CryptAcquireContext raises NTE_BAD_KEYSET

Initial Comment:
pycrypto acquires context of container that is unique
to each user, but inproperly handles error when
required key set isn't aviable.

Better way (recomended in MSDN):

if (!CryptAcquireContext(&hProv,
                         "Container",
                         NULL,
                         PROV_RSA_FULL,
                         0))
{
    if (GetLastError() == NTE_BAD_KEYSET)
    {
        if (!CryptAcquireContext(&hProv,
                                 "Container",
                                 NULL,
                                 PROV_RSA_FULL,
                                 CRYPT_NEWKEYSET))
        {
            // Error ...
        }
    }
}



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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-11-03 04:09

Message:
Logged In: NO 

I had the exact same problem, and the exact same fix solved
it...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1343753 ] winrand.c in CryptAcquireContext raises NTE_BAD_KEYSET

[SourceForge.net <no...@so...>]

Bugs item #1343753, was opened at 2005-10-31 04:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: winrand.c in CryptAcquireContext raises NTE_BAD_KEYSET

Initial Comment:
pycrypto acquires context of container that is unique
to each user, but inproperly handles error when
required key set isn't aviable.

Better way (recomended in MSDN):

if (!CryptAcquireContext(&hProv,
                         "Container",
                         NULL,
                         PROV_RSA_FULL,
                         0))
{
    if (GetLastError() == NTE_BAD_KEYSET)
    {
        if (!CryptAcquireContext(&hProv,
                                 "Container",
                                 NULL,
                                 PROV_RSA_FULL,
                                 CRYPT_NEWKEYSET))
        {
            // Error ...
        }
    }
}



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1266515 ] RSA encryption without proper padding considered weak

[SourceForge.net <no...@so...>]

Bugs item #1266515, was opened at 2005-08-22 13:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1266515&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: RSA encryption without proper padding considered weak

Initial Comment:
I've just read PKCS#1 v1.5 (which has become RFC 2313)
and PKCS#1 v2.1 (RFC 3447)

PKCS#1 v2.1 (RFC 3447)
    http://www.rsasecurity.com/rsalabs/node.asp?id=2125
   
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

v2.1 states that cryptographic primitives (such as the
simple m**e mod n of RSA) "are not intended to provide
apart from a scheme" (p.9). It then defines a slightly
more complex encryption "scheme" which encodes the
plaintext prior to the plain RSA encryption.

The encryption function of RSAobj keys is a simple
exponentiation modula n.

This is weak for several reasons:

* decryption == signing, and an attacker could use this
to retrieve a valid signature for an arbitrary document
even if the entity that holds the private key has
disabled signing.

* Given that the set of expected plain texts is small,
an opponent is able to precompute the corresponding
ciphertext.

* Even more serious, there seem to be attacks which
reveal the private key (or parts of it), but haven't
read about the mathematics at all. But the encoding
stuff in PKCS#1 can't be all useless!? 

IMHO all of the above would apply to signatures and
qNEW encryptions/signatures as well. ElGamal depends on
a private one-time value, but I don't know if this
implicates that the above weaknesses don't apply to
ElGamal.

RFC 2440 (OpenPGP) cites (p.17) PKCS#1 and uses the
"old" encoding format of v1.5 which is no longer
recommended by v2.1 but still secure if used like in
RFC 2440. However, an OpenPGP implementtion is required
to "make new PKCS-1
padding for each key" (recipient) when encryption for
several recipients.  RFC 3560 (RSAES-OAEP in CMS)
refers to known "adaptive chosen ciphertext attacks"
that apply to the PKCS#1 v1.5 padding algorithm and, so
far I'm sure, also to unpadded RSA.

If it turns out that the encryption provided by the
Python Cryptography Toolkit is weak, this would be a
serious issue.
In this case, I propose

    - to provide "EME-OAEP" encoding (as defined in PKCS#1)
    - to consider subclassing the
Crypto.PublicKey.pubkey.pubkey class, owerwriting the
encrypt/decrypt/sign/verify methods so that they
support EME-OAEP and recommending the new class.

bye,
    dpj

ps. I'd like to take the opportunity to thank amk and
all the other Python-Crypto people; I've learned a lot
about cryptogrophy and even more about python from your
sources.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1266515&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1255031 ] do CTR mode in pure C

[SourceForge.net <no...@so...>]

Patches item #1255031, was opened at 2005-08-09 15:16
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: do CTR mode in pure C

Initial Comment:
The design in which CTR mode calls a Python callable
for each block is very flexible, but suffers an obvious
performance cost.  After these patches, one can
optionally pass either a callable *or* a string of
block length.  If one passes a callable, then it
functions as before.  If one passes a string of length
block length, then it makes a copy of the contents of
the strings in an internal buffer, and increments that
value in C for each block.

This results in a nice speed-up, for example:

AES:
  ECB mode: 90841.10 K/sec
  CFB mode: 2380.59 K/sec
  CBC mode: 68653.57 K/sec
  PGP mode: 70991.19 K/sec
  OFB mode: 69941.49 K/sec
  CTR mode: 1251.37 K/sec
  CTR mode, variable length: 1728.07 K/sec
  CTR mode, fast increment: 68122.18 K/sec
  CTR mode, fast increment (slow decrypt): 2367.85 K/sec

That last line there is where it encrypts with the fast
incrementer and decrypts with the Python callback
incrementer to verify that the ctr increment is
computed the same way.

You can also browse and download these patches via my
web view:

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches

There are three patches in the attached file.


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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-08-17 15:27

Message:
Logged In: YES 
user_id=52562

Okay, if you browse this patch server cgi script you can get
the fix:

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches

Or just use HTTP to fetch the files from

https://yumyum.zooko.com:19144/pub/repos/pycrypto-zookopatches

As you can see there are a few other patches for testing and
benchmarking in there.  The benchmarking requires the pyutil
library.

The benchmarking shows that this backwards-incompatible
change of eliminating the python callback and simplifying
the code gives a speedup of somewhere between 0 and 4%
depending on the exact usage.

(You could also keep the speedup and keep the optional
backwards-compatible Python callback support, but you can't
keep all three of the speedup, the
optional-backwards-compatible Python callback support, and
the simpler code.)

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-08-17 12:07

Message:
Logged In: YES 
user_id=52562

There's an issue in this patch -- it increments the counter
before encrypting, so if you initialize the counter with 0
then the first block will be encrypted with 1.

I'm fixing this issue, but my new patch is going to get rid
of the optional Python callback entirely.  (Maintaining both
ways to do it is complicating things.)



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1255031 ] do CTR mode in pure C

[SourceForge.net <no...@so...>]

Patches item #1255031, was opened at 2005-08-09 15:16
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: do CTR mode in pure C

Initial Comment:
The design in which CTR mode calls a Python callable
for each block is very flexible, but suffers an obvious
performance cost.  After these patches, one can
optionally pass either a callable *or* a string of
block length.  If one passes a callable, then it
functions as before.  If one passes a string of length
block length, then it makes a copy of the contents of
the strings in an internal buffer, and increments that
value in C for each block.

This results in a nice speed-up, for example:

AES:
  ECB mode: 90841.10 K/sec
  CFB mode: 2380.59 K/sec
  CBC mode: 68653.57 K/sec
  PGP mode: 70991.19 K/sec
  OFB mode: 69941.49 K/sec
  CTR mode: 1251.37 K/sec
  CTR mode, variable length: 1728.07 K/sec
  CTR mode, fast increment: 68122.18 K/sec
  CTR mode, fast increment (slow decrypt): 2367.85 K/sec

That last line there is where it encrypts with the fast
incrementer and decrypts with the Python callback
incrementer to verify that the ctr increment is
computed the same way.

You can also browse and download these patches via my
web view:

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches

There are three patches in the attached file.


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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-08-17 12:07

Message:
Logged In: YES 
user_id=52562

There's an issue in this patch -- it increments the counter
before encrypting, so if you initialize the counter with 0
then the first block will be encrypted with 1.

I'm fixing this issue, but my new patch is going to get rid
of the optional Python callback entirely.  (Maintaining both
ways to do it is complicating things.)



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1258276 ] time.time -> time.clock

[SourceForge.net <no...@so...>]

Patches item #1258276, was opened at 2005-08-13 08:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1258276&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Andersén (erik_andersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.time -> time.clock

Initial Comment:
When timing, the test program often says that the
program executed to fast to measure the time 
used.

To time a program, time.clock should be used 
instead of time.time. The former will give better 
resolution, at least on some systems.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1258276&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1255031 ] do CTR mode in pure C

[SourceForge.net <no...@so...>]

Patches item #1255031, was opened at 2005-08-09 15:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: do CTR mode in pure C

Initial Comment:
The design in which CTR mode calls a Python callable
for each block is very flexible, but suffers an obvious
performance cost.  After these patches, one can
optionally pass either a callable *or* a string of
block length.  If one passes a callable, then it
functions as before.  If one passes a string of length
block length, then it makes a copy of the contents of
the strings in an internal buffer, and increments that
value in C for each block.

This results in a nice speed-up, for example:

AES:
  ECB mode: 90841.10 K/sec
  CFB mode: 2380.59 K/sec
  CBC mode: 68653.57 K/sec
  PGP mode: 70991.19 K/sec
  OFB mode: 69941.49 K/sec
  CTR mode: 1251.37 K/sec
  CTR mode, variable length: 1728.07 K/sec
  CTR mode, fast increment: 68122.18 K/sec
  CTR mode, fast increment (slow decrypt): 2367.85 K/sec

That last line there is where it encrypts with the fast
incrementer and decrypts with the Python callback
incrementer to verify that the ctr increment is
computed the same way.

You can also browse and download these patches via my
web view:

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches

There are three patches in the attached file.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1041588 ] wishlist: DH key agreement

[SourceForge.net <no...@so...>]

Bugs item #1041588, was opened at 2004-10-06 16:26
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1041588&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: wishlist: DH key agreement

Initial Comment:
I need something that is not encryption nor
authentication, but key agreement.  That is: Alice
generates random x, Bob generates random y, Alice
computes g^x mod p, Bob computes g^y mod p, Alice
(given g^y), computes (g^y)^x.

How can I accomplish this?


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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-08-04 12:22

Message:
Logged In: YES 
user_id=52562

I'm attempting to close this since it turns out DH key
agreement already works.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-06-14 21:27

Message:
Logged In: YES 
user_id=52562

Yes, I eventually noticed that Python does this efficiently.
 It was fine.  Not stellar -- I think it was something like
1 second for 4096 bit DH or something -- but fine.

I'm glad to see that AMK is tending to pycrypto again...

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-06-14 21:07

Message:
Logged In: NO 

Umm...The plain DH is rather weak in itself. I'd strongly
recommend that you pick up B. Schneiener's Practical
Cryptography.

-NcF

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

Comment By: A.M. Kuchling (akuchling)
Date: 2004-10-20 16:56

Message:
Logged In: YES 
user_id=11375

Python supports pow(g,y,p) to compute g**y mod p.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2004-10-06 16:36

Message:
Logged In: YES 
user_id=52562

Well I looked into the source of pycrypto to see what it
would take to add this functionality.  It turns out that the
El Gamal stuff is implemented in 100% Pure Python!  That's
kind of shocking, but at least it answers my question about
how to compute this.  The answer is something that includes
lines like "pow(g, y) % p".  I'll be interested to see how
this performs.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1041588&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1251206 ] Traceback unpickling DSA keys if _fastmath.so unavailable

[SourceForge.net <no...@so...>]

Bugs item #1251206, was opened at 2005-08-03 11:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1251206&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: matt chisholm (glyphobet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Traceback unpickling DSA keys if _fastmath.so unavailable

Initial Comment:
If I create a DSA key and save the public and private
keys to a file using pickle.dump() on a system where
Crypto.PublicKey._fastmath is available:


import pickle
from Crypto.PublicKey import DSA as pklib
from Crypto.Util import randpool
r = randpool.KeyboardRandomPool()
r.randomize()
pub_key_file = open(pub_key_path, 'wb')
pri_key_file = open(pri_key_path, 'wb')
r.add_event()
key = pklib.generate(2**10, r.get_bytes)
pickle.dump(key            , pri_key_file, protocol=2)
pickle.dump(key.publickey(), pub_key_file, protocol=2)


then I cannot pickle.load() those keys on another
system where _fastmath is not available. 


private_key_file = open(pri_key_path, 'rb')
key = pickle.load(private_key_file)


Instead, I get the following traceback:


Traceback (most recent call last):
  File "auto-update/sign_file.py", line 15, in ?
    key = pickle.load(private_key_file)
  File "/usr/lib/python2.3/pickle.py", line 1390, in load
    return Unpickler(file).load()
  File "/usr/lib/python2.3/pickle.py", line 872, in load
    dispatch[key](self)
  File "/usr/lib/python2.3/pickle.py", line 1237, in
load_build
    setstate(state)
  File
"/usr/lib/python2.3/site-packages/Crypto/PublicKey/DSA.py",
line 202, in __setstate__
    self.key = _fastmath.dsa_construct(y,g,p,q,x)
AttributeError: 'NoneType' object has no attribute
'dsa_construct'


If I create the DSA keys on a system without _fastmath,
I can load them on the system with _fastmath with no
problems.


Versions:

System #1:
Linux 2.4.26 debian testing, all stock packages
Python 2.3.5 (#2, May 29 2005, 00:34:43)
[GCC 3.3.6 (Debian 1:3.3.6-5)] on linux2
pycrypto 2.0+dp1-2
_fastmath.so available

System #2:
Linux 2.6.10-5-686 ubuntu hoary, all stock packages
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
pycrypto 2.0+dp1-2ubuntu1
_fastmath.so *not* available

System #3:
Windows XP SP2
Python 2.3.4 (from python.org)
pycrypto 2.0 (from http://twisted.sourceforge.net/contrib/)
_fastmath.so *not* available

Please contact me if you need more information.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1251206&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1239513 ] let CTR mode work as a real stream cipher

[SourceForge.net <no...@so...>]

Patches item #1239513, was opened at 2005-07-16 18:00
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: let CTR mode work as a real stream cipher

Initial Comment:
I said I would attach this to the OFB patch thread, but
instead I'm making a new patch tracker entry.

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:33

Message:
Logged In: YES 
user_id=52562

Here's an addition to test.py.  After this patch, test.py
fails when it attempts to use CTR mode on variable-length
inputs.  Then if you apply the other patch then the test passes.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:32

Message:
Logged In: YES 
user_id=52562

Um..  I don't see the patch itself on this web site.  Maybe
I failed to upload it last time.  Here is one that might be
slightly different.  There was a mistake in the previous
patch, which you perhaps never received anyway.  Oh yes, I
see there is a checkbox that I have to check in order to
upload...

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:00

Message:
Logged In: YES 
user_id=52562

The patch is against the 2.0.1 tarball.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1239513 ] let CTR mode work as a real stream cipher

[SourceForge.net <no...@so...>]

Patches item #1239513, was opened at 2005-07-16 18:00
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: let CTR mode work as a real stream cipher

Initial Comment:
I said I would attach this to the OFB patch thread, but
instead I'm making a new patch tracker entry.

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:32

Message:
Logged In: YES 
user_id=52562

Um..  I don't see the patch itself on this web site.  Maybe
I failed to upload it last time.  Here is one that might be
slightly different.  There was a mistake in the previous
patch, which you perhaps never received anyway.  Oh yes, I
see there is a checkbox that I have to check in order to
upload...

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:00

Message:
Logged In: YES 
user_id=52562

The patch is against the 2.0.1 tarball.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1239513 ] let CTR mode work as a real stream cipher

[SourceForge.net <no...@so...>]

Patches item #1239513, was opened at 2005-07-16 18:00
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: let CTR mode work as a real stream cipher

Initial Comment:
I said I would attach this to the OFB patch thread, but
instead I'm making a new patch tracker entry.

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 18:00

Message:
Logged In: YES 
user_id=52562

The patch is against the 2.0.1 tarball.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

[Pycrypto-checkins] [ pycrypto-Patches-1239513 ] let CTR mode work as a real stream cipher

[SourceForge.net <no...@so...>]

Patches item #1239513, was opened at 2005-07-16 18:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: let CTR mode work as a real stream cipher

Initial Comment:
I said I would attach this to the OFB patch thread, but
instead I'm making a new patch tracker entry.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1239513&group_id=20937

[Pycrypto-checkins] [ pycrypto-Bugs-1054714 ] wishlist: variable length CTR mode

[SourceForge.net <no...@so...>]

Bugs item #1054714, was opened at 2004-10-26 17:13
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1054714&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: wishlist: variable length CTR mode

Initial Comment:
I'm using AES in CTR mode.  It objects if I give it a
plaintext whose length isn't an integer multiple of 16.
 So I'll have to check for that, pad, encrypt, then
truncate.

It would be nice if pycrypto would do this itself.

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-07-16 17:59

Message:
Logged In: YES 
user_id=52562

I've updated my patch to make CTR mode support variable
length texts so that it applies against 2.0.1.  (We need it
for a product I'm working on.)

I'll attach the current version of the patch to the thread
about the OFB patch in the patch tracker.

I would like to unify the CTR mode patch and the OFB patch,
but not right now as I need to go work on the aforementioned
product...


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2004-10-27 12:58

Message:
Logged In: YES 
user_id=52562

details about CTR mode and not-using-padding:

RFC 3711:

http://www.faqs.org/rfcs/rfc3711.html

the default encryption transform is AES-CTR mode.  "None of
the pre-defined encryption transforms uses any padding; for
these, the RTP and SRTP payload sizes match exactly"

Comments to NIST concerning AES Modes of Operations:
CTR-Mode Encryption (2000),  Helger Lipmaa, Phillip Rogaway,
David Wagner:
http://citeseer.ist.psu.edu/lipmaa00comments.html


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2004-10-26 19:51

Message:
Logged In: YES 
user_id=52562

Man, the linewrapping of this HTML form thingie is irritating.

I made symlinks so here are the slightly shorter URLs:

list of my patches:

http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zp?c=patches

The test patch:

http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zp/?c=diff&p=20041026183323-92b7f-c777a077c2f516680a548c486d4f3c2730b2b0e7.gz

(If that URL is too long to deal with then just go to the
list above and click on the name of the patch and then click
"diff" to get a unified diff.)

The variable-length-input-for-CTR-mode patch:
http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zp/?c=diff&p=20041026191834-92b7f-72995f81f2b92accfc02254869d2ea84ecdbc960.gz


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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2004-10-26 19:24

Message:
Logged In: YES 
user_id=52562

CTR mode as typically used doesn't add any padding.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2004-10-26 19:23

Message:
Logged In: YES 
user_id=52562

Okay I implemented it.
Here is a list of my patches to pycrypto:
http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zookopatches?c=patches&t=

The only interesting ones are this one:
http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zookopatches/?c=diff&p=20041026183323-92b7f-c777a077c2f516680a548c486d4f3c2730b2b0e7.gz

which adds a unit test for non-multiple-of-blocksize inputs
and this one:
http://zooko.com/cgi-bin/darcs.cgi/pycrypto/zookopatches/?c=diff&p=20041026191834-92b7f-72995f81f2b92accfc02254869d2ea84ecdbc960.gz

which makes CTR mode handle variable length inputs.



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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-10-26 17:24

Message:
Logged In: NO 

I'm almost certian this will never happen.  There are too
many variations on how to pad the block.  Also, truncating
the block will make it undecipherable.  If you want an easy
way to pad your string:

bs = 16
pad = '\x00'
s = 'something that is not of length 16'

s += (bs - (len(s) % bs)) * pad

Alternatively, you can use a stream cipher like RC4, which
doesn't have a block size.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1054714&group_id=20937