[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