hawq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r...@apache.org
Subject [8/8] incubator-hawq git commit: HAWQ-926. Remove pycrypto from HAWQ source code
Date Thu, 14 Jul 2016 09:10:00 GMT
HAWQ-926. Remove pycrypto from HAWQ source code

User need to install it by pip before install HAWQ


Project: http://git-wip-us.apache.org/repos/asf/incubator-hawq/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-hawq/commit/ac031357
Tree: http://git-wip-us.apache.org/repos/asf/incubator-hawq/tree/ac031357
Diff: http://git-wip-us.apache.org/repos/asf/incubator-hawq/diff/ac031357

Branch: refs/heads/master
Commit: ac031357b3b29978772f1e7478d97d21da653df4
Parents: 077f708
Author: rlei <rlei@pivotal.io>
Authored: Thu Jul 14 10:40:42 2016 +0800
Committer: rlei <rlei@pivotal.io>
Committed: Thu Jul 14 17:08:51 2016 +0800

----------------------------------------------------------------------
 .travis.yml                                     |   11 +-
 pom.xml                                         |    3 -
 tools/bin/Makefile                              |    3 +-
 tools/bin/pythonSrc/pycrypto-2.0.1/ACKS         |   34 -
 tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog    |  316 ----
 .../pythonSrc/pycrypto-2.0.1/Cipher/__init__.py |   33 -
 .../pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex    | 1188 --------------
 tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py |  108 --
 tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py  |   13 -
 tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py  |   11 -
 .../pythonSrc/pycrypto-2.0.1/Hash/__init__.py   |   24 -
 tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE      |   15 -
 tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST     |   63 -
 tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO     |   18 -
 .../pycrypto-2.0.1/Protocol/AllOrNothing.py     |  295 ----
 .../pycrypto-2.0.1/Protocol/Chaffing.py         |  229 ---
 .../pycrypto-2.0.1/Protocol/__init__.py         |   17 -
 .../pythonSrc/pycrypto-2.0.1/PublicKey/DSA.py   |  238 ---
 .../pycrypto-2.0.1/PublicKey/ElGamal.py         |  132 --
 .../pythonSrc/pycrypto-2.0.1/PublicKey/RSA.py   |  256 ---
 .../pycrypto-2.0.1/PublicKey/__init__.py        |   17 -
 .../pycrypto-2.0.1/PublicKey/pubkey.py          |  172 ---
 .../pythonSrc/pycrypto-2.0.1/PublicKey/qNEW.py  |  170 --
 .../pycrypto-2.0.1/PublicKey/test/rsa_speed.py  |   48 -
 tools/bin/pythonSrc/pycrypto-2.0.1/README       |   76 -
 tools/bin/pythonSrc/pycrypto-2.0.1/TODO         |   31 -
 .../pythonSrc/pycrypto-2.0.1/Util/RFC1751.py    |  342 ----
 .../pythonSrc/pycrypto-2.0.1/Util/__init__.py   |   16 -
 .../bin/pythonSrc/pycrypto-2.0.1/Util/number.py |  201 ---
 .../pythonSrc/pycrypto-2.0.1/Util/randpool.py   |  421 -----
 tools/bin/pythonSrc/pycrypto-2.0.1/Util/test.py |  453 ------
 .../pycrypto-2.0.1/Util/test/prime_speed.py     |   24 -
 tools/bin/pythonSrc/pycrypto-2.0.1/__init__.py  |   25 -
 tools/bin/pythonSrc/pycrypto-2.0.1/setup.py     |  168 --
 tools/bin/pythonSrc/pycrypto-2.0.1/src/AES.c    | 1459 ------------------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/ARC2.c   |  185 ---
 tools/bin/pythonSrc/pycrypto-2.0.1/src/ARC4.c   |   72 -
 .../bin/pythonSrc/pycrypto-2.0.1/src/Blowfish.c |  499 ------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/CAST.c   |  436 ------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/DES.c    |  665 --------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/DES3.c   |  688 ---------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/IDEA.c   |  196 ---
 tools/bin/pythonSrc/pycrypto-2.0.1/src/MD2.c    |  118 --
 tools/bin/pythonSrc/pycrypto-2.0.1/src/MD4.c    |  203 ---
 tools/bin/pythonSrc/pycrypto-2.0.1/src/RC5.c    |  212 ---
 tools/bin/pythonSrc/pycrypto-2.0.1/src/RIPEMD.c |  507 ------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/SHA256.c |  200 ---
 tools/bin/pythonSrc/pycrypto-2.0.1/src/XOR.c    |   52 -
 tools/bin/pythonSrc/pycrypto-2.0.1/src/_dsa.c   |  331 ----
 .../pythonSrc/pycrypto-2.0.1/src/_fastmath.c    |  804 ----------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/_rsa.c   |  346 -----
 .../pycrypto-2.0.1/src/block_template.c         |  753 ---------
 tools/bin/pythonSrc/pycrypto-2.0.1/src/cast5.c  |  437 ------
 .../pycrypto-2.0.1/src/hash_template.c          |  248 ---
 .../pycrypto-2.0.1/src/stream_template.c        |  248 ---
 .../bin/pythonSrc/pycrypto-2.0.1/src/winrand.c  |  366 -----
 tools/bin/pythonSrc/pycrypto-2.0.1/test.py      |   38 -
 .../bin/pythonSrc/pycrypto-2.0.1/test/template  |   26 -
 .../pycrypto-2.0.1/test/test_chaffing.py        |   58 -
 .../pycrypto-2.0.1/test/test_hashes.py          |   94 --
 .../pycrypto-2.0.1/test/test_number.py          |   85 -
 .../pycrypto-2.0.1/test/test_publickey.py       |  122 --
 .../pycrypto-2.0.1/test/test_randpool.py        |   48 -
 .../pycrypto-2.0.1/test/test_rfc1751.py         |   45 -
 .../pythonSrc/pycrypto-2.0.1/test/testdata.py   |  681 --------
 65 files changed, 3 insertions(+), 15390 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/.travis.yml
----------------------------------------------------------------------
diff --git a/.travis.yml b/.travis.yml
index da49f5a..7e7c2aa 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,9 +3,6 @@ language: c
 os:
   - osx
 
-env:
-  - PYCHECKER_VERSION=0.8.19 FIGLEAF_VERSION=0.6.1
-
 compiler:
   - clang
 
@@ -30,13 +27,7 @@ install:
   - brew outdated maven || brew upgrade maven
   - brew tap brona/iproute2mac
   - brew install iproute2mac
-  - sudo pip install pygresql
-  - sudo pip install unittest2 pycrypto lockfile paramiko psi
-  - sudo pip install
-    "http://sourceforge.net/projects/pychecker/files/pychecker/${PYCHECKER_VERSION}/pychecker-${PYCHECKER_VERSION}.tar.gz/download"
-  - sudo pip install
-    "http://darcs.idyll.org/~t/projects/figleaf-${FIGLEAF_VERSION}.tar.gz"
-  - brew uninstall postgresql
+  - sudo pip install pycrypto paramiko
 
 before_script:
   - cd $TRAVIS_BUILD_DIR

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/pom.xml
----------------------------------------------------------------------
diff --git a/pom.xml b/pom.xml
index 03fe050..7d67ed6 100644
--- a/pom.xml
+++ b/pom.xml
@@ -40,9 +40,6 @@
               <!-- PyGreSQL an open-source Python module that interfaces to a PostgreSQL database under the Python Software Foundation License -->
               <exclude>tools/bin/pythonSrc/PyGreSQL-4.0/**</exclude>
 
-              <!-- Open-source Pyton module with "public domain" license -->
-              <exclude>tools/bin/pythonSrc/pycrypto-2.0.1/**</exclude>
-
               <!-- Open-source Python modules with MIT license -->
               <exclude>tools/bin/pythonSrc/PSI-0.3b2_gp/**</exclude>
               <exclude>tools/bin/pythonSrc/lockfile-0.9.1/**</exclude>

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/Makefile
----------------------------------------------------------------------
diff --git a/tools/bin/Makefile b/tools/bin/Makefile
index 3102537..280adb9 100644
--- a/tools/bin/Makefile
+++ b/tools/bin/Makefile
@@ -36,7 +36,7 @@ PYLIB_SRC=$(SRC)/pythonSrc
 LIB_DIR=$(SRC)/lib
 PYLIB_DIR=$(SRC)/ext
 
-all: lockfile pygresql stream pychecker psi unittest2 pycrypto
+all: lockfile pygresql stream pychecker psi unittest2
 
 #
 # Python Libraries
@@ -91,6 +91,7 @@ PYCRYPTO_DIR=pycrypto-$(PYCRYPTO_VERSION)
 
 pycrypto:
 	@echo "--- pycrypto"
+	cd $(PYLIB_SRC)/ && $(TAR) xzf $(PYCRYPTO_DIR).tar.gz
 	cd $(PYLIB_SRC)/$(PYCRYPTO_DIR)/ && CC="$(CC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" python setup.py build
 	cp -r $(PYLIB_SRC)/$(PYCRYPTO_DIR)/build/lib.*/Crypto $(PYLIB_DIR)
 

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/ACKS
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/ACKS b/tools/bin/pythonSrc/pycrypto-2.0.1/ACKS
deleted file mode 100644
index 2acfc30..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/ACKS
+++ /dev/null
@@ -1,34 +0,0 @@
-Acknowledgements
-----------------
-
-This list is sorted in alphabetical order, and is probably incomplete.
-I'd like to thank everybody who contributed in any way, with code, bug
-reports, and comments.
-
---amk
-
-Tim Berners-Lee
-Ian Bicking
-Joris Bontje
-Antoon Bosselaers
-Andrea Bottoni
-Andrew Eland
-Philippe Frycia
-Peter Gutmann
-Hirendra Hindocha
-Nikhil Jhingan
-Piers Lauder
-M.-A. Lemburg
-Wim Lewis
-Mark Moraes
-Lim Chee Siang
-Bryan Olson
-Wallace Owen
-Colin Plumb
-James P. Rutledge
-Matt Schreiner
-Peter Simmons
-Paul Swartz
-Kevin M. Turner
-Eric Young
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog b/tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog
deleted file mode 100644
index 30e325c..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog
+++ /dev/null
@@ -1,316 +0,0 @@
-
-2.0.1
-=====
-
-	* Fix SHA256 and RIPEMD on AMD64 platform.
-        * Deleted Demo/ directory.
-	* Add PublicKey to Crypto.__all__
-
-
-2.0
-===
-
-	* Added SHA256 module contributed by Jeethu Rao, with test data
-	  from Taylor Boon.
-
-	* Fixed AES.c compilation problems with Borland C.  
-	  (Contributed by Jeethu Rao.)
-
-	* Fix ZeroDivisionErrors on Windows, caused by the system clock
-	  not having enough resolution.
-	
-        * Fix 2.1/2.2-incompatible use of (key not in dict),
-	  pointed out by Ian Bicking.
-
-	* Fix FutureWarning in Crypto.Util.randpool, noted by James P Rutledge.
-
-	
-1.9alpha6
-=========
-
-	* Util.number.getPrime() would inadvertently round off the bit
-	  size; if you asked for a 129-bit prime or 135-bit prime, you
-	  got a 128-bit prime.
-
-	* Added Util/test/prime_speed.py to measure the speed of prime
- 	  generation, and PublicKey/test/rsa_speed.py to measure
-	  the speed of RSA operations.
-
-	* Merged the _rsa.c and _dsa.c files into a single accelerator
-	  module, _fastmath.c.  
-
-	* Speed improvements: Added fast isPrime() function to _fastmath,
-	  cutting the time to generate a 1024-bit prime by a factor of 10.
-	  Optimized the C version of RSA decryption to use a longer series
-	  of operations that's roughly 3x faster than a single
-	  exponentiation.  (Contributed by Joris Bontje.)
-
-	* Added support to RSA key objects for blinding and unblinding 
-	  data. (Contributed by Joris Bontje.)
-
-	* Simplified RSA key generation: hard-wired the encryption
-	  exponent to 65537 instead of generating a random prime;
-	  generate prime factors in a loop until the product 
-	  is large enough.
-	
-	* Renamed cansign(), canencrypt(), hasprivate(), to 
-	  can_sign, can_encrypt, has_private.  If people shriek about
-	  this change very loudly, I'll add aliases for the old method
-	  names that log a warning and call the new method.
-	
-
-1.9alpha5
-=========
-
-        * Many randpool changes.  RandomPool now has a
-          randomize(N:int) method that can be called to get N
-          bytes of entropy for the pool (N defaults to 0,
-          which 'fills up' the pool's entropy) KeyboardRandom
-          overloads this method.
-
-        * Added src/winrand.c for Crypto.Util.winrandom and
-          now use winrandom for _randomize if possible.
-          (Calls Windows CryptoAPI CryptGenRandom)
-
-        * Several additional places for stirring the pool,
-          capturing inter-event entropy when reading/writing,
-          stirring before and after saves.
-
-        * RandomPool.add_event now returns the number of
-          estimated bits of added entropy, rather than the
-          pool entropy itself (since the pool entropy is
-          capped at the number of bits in the pool)
-
-        * Moved termios code from KeyboardRandomPool into a
-          KeyboardEntry class, provided a version for Windows
-          using msvcrt.
-
-        * Fix randpool.py crash on machines with poor timer resolution.
-          (Reported by Mark Moraes and others.)
-
-        * If the GNU GMP library is available, two C extensions will be 
-          compiled to speed up RSA and DSA operations.  (Contributed by 
-          Paul Swartz.)
-
-        * DES3 with a 24-byte key was broken; now fixed.  
-	  (Patch by Philippe Frycia.)
-
-
-1.9alpha4
-=========
-
-        * Fix compilation problem on Windows.
-
-        * HMAC.py fixed to work with pre-2.2 Pythons
-        
-        * setup.py now dies if built with Python 1.x
-        
-
-1.9alpha3
-=========
-
-        * Fix a ref-counting bug that caused core dumps.  
-          (Reported by Piers Lauder and an anonymous SF poster.)
-        
-
-1.9alpha2
-=========
-
-        * (Backwards incompatible) The old Crypto.Hash.HMAC module is
-          gone, replaced by a copy of hmac.py from Python 2.2's standard
-          library.  It will display a warning on interpreter versions
-          older than 2.2.
-        
-        * (Backwards incompatible) Restored the Crypto.Protocol package,
-          and modernized and tidied up the two modules in it,
-          AllOrNothing.py and Chaffing.py, renaming various methods
-          and changing the interface.
-          
-        * (Backwards incompatible) Changed the function names in
-          Crypto.Util.RFC1751.
-        
-        * Restored the Crypto.PublicKey package at user request.  I
-          think I'll leave it in the package and warn about it in the
-          documentation.  I hope that eventually I can point to
-          someone else's better public-key code, and at that point I
-          may insert warnings and begin the process of deprecating
-          this code.
-
-        * Fix use of a Python 2.2 C function, replacing it with a 
-          2.1-compatible equivalent.  (Bug report and patch by Andrew
-          Eland.)  
-
-        * Fix endianness bugs that caused test case failures on Sparc,
-          PPC, and doubtless other platforms.
-
-        * Fixed compilation problem on FreeBSD and MacOS X.
-        
-        * Expanded the test suite (requires Sancho, from 
-          http://www.mems-exchange.org/software/sancho/)
-
-        * Added lots of docstrings, so 'pydoc Crypto' now produces 
-          helpful output.  (Open question: maybe *all* of the documentation
-          should be moved into docstrings?)
-          
-        * Make test.py automatically add the build/* directory to sys.path.
-
-        * Removed 'inline' declaration from C functions.  Some compilers
-          don't support it, and Python's pyconfig.h no longer tells you whether
-          it's supported or not.  After this change, some ciphers got slower,
-          but others got faster.
-          
-        * The C-level API has been changed to reduce the amount of
-          memory-to-memory copying.   This makes the code neater, but 
-          had ambiguous performance effects; again, some ciphers got slower
-          and others became faster.  Probably this is due to my compiler
-          optimizing slightly worse or better as a result.
-
-        * Moved C source implementations into src/ from block/, hash/, 
-          and stream/.  Having Hash/ and hash/ directories causes problems
-          on case-insensitive filesystems such as Mac OS.
-
-        * Cleaned up the C code for the extensions.
-                
-        
-1.9alpha1
-=========
-
-        * Added Crypto.Cipher.AES.
-
-        * Added the CTR mode and the variable-sized CFB mode from the
-          NIST standard on feedback modes. 
-        
-        * Removed Diamond, HAVAL, MD5, Sapphire, SHA, and Skipjack.  MD5
-          and SHA are included with Python; the others are all of marginal
-          usefulness in the real world.
-
-        * Renamed the module-level constants ECB, CFB, &c., to MODE_ECB,
-          MODE_CFB, as part of making the block encryption modules 
-          compliant with PEP 272.  (I'm not sure about this change;
-          if enough users complain about it, I might back it out.)
-        
-        * Made the hashing modules compliant with PEP 247 (not backward
-          compatible -- the major changes are that the constructor is now 
-          MD2.new and not MD2.MD2, and the size of the digest is now 
-          given as 'digest_size', not 'digestsize'.
-
-        * The Crypto.PublicKey package is no longer installed; the
-          interfaces are all wrong, and I have no idea what the right
-          interfaces should be.  
-
-
-1.1alpha2
-=========
-        * Most importantly, the distribution has been broken into two
-parts: exportable, and export-controlled.  The exportable part
-contains all the hashing algorithms, signature-only public key
-algorithms, chaffing & winnowing, random number generation, various
-utility modules, and the documentation.
-
-        The export-controlled part contains public-key encryption
-algorithms such as RSA and ElGamal, and bulk encryption algorithms
-like DES, IDEA, or Skipjack.  Getting this code still requires that
-you go through an access control CGI script, and denies you access if
-you're outside the US or Canada.
-
-        * Added the RIPEMD hashing algorithm.  (Contributed by
-Hirendra Hindocha.)
-
-        * Implemented the recently declassified Skipjack block
-encryption algorithm.  My implementation runs at 864 K/sec on a
-PII/266, which isn't particularly fast, but you're probably better off
-using another algorithm anyway.  :)
-
-        * A simple XOR cipher has been added, mostly for use by the
-chaffing/winnowing code.  (Contributed by Barry Warsaw.)
-
-        * Added Protocol.Chaffing and Hash.HMAC.py.  (Contributed by
-Barry Warsaw.)  
-
-        Protocol.Chaffing implements chaffing and winnowing, recently
-proposed by R. Rivest, which hides a message (the wheat) by adding
-many noise messages to it (the chaff).  The chaff can be discarded by
-the receiver through a message authentication code.  The neat thing
-about this is that it allows secret communication without actually
-having an encryption algorithm, and therefore this falls within the
-exportable subset.  
-
-        * Tidied up randpool.py, and removed its use of a block
-cipher; this makes it work with only the export-controlled subset
-available.
-
-        * Various renamings and reorganizations, mostly internal.
-
-        
-1.0.2
-=====
-
-        * Changed files to work with Python 1.5; everything has been
-re-arranged into a hierarchical package.  (Not backward compatible.)
-The package organization is:
-Crypto.
-        Hash.
-                MD2, MD4, MD5, SHA, HAVAL
-        Cipher.
-                ARC2, ARC4, Blowfish, CAST, DES, DES3, Diamond, 
-                IDEA, RC5, Sapphire
-        PublicKey.
-                DSA, ElGamal, qNEW, RSA
-        Util.
-                number, randpool, RFC1751
-
-        Since this is backward-incompatible anyway, I also changed
-module names from all lower-case to mixed-case: diamond -> Diamond,
-rc5 -> RC5, etc.  That had been an annoying inconsistency for a while.
-        
-        * Added CAST5 module contributed by <wiml@hhhh.org>.
-
-        * Added qNEW digital signature algorithm (from the digisign.py
-I advertised a while back).  (If anyone would like to suggest new
-algorithms that should be implemented, please do; I think I've got
-everything that's really useful at the moment, but...)
-
-        * Support for keyword arguments has been added.  This allowed
-removing the obnoxious key handling for Diamond and RC5, where the
-first few bytes of the key indicated the number of rounds to use, and
-various other parameters.  Now you need only do something like:
-
-from Crypto.Cipher import RC5
-obj = RC5.new(key, RC5.ECB, rounds=8)
-
-(Not backward compatible.) 
-
-        * Various function names have been changed, and parameter
-names altered.  None of these were part of the public interface, so it
-shouldn't really matter much.
-
-        * Various bugs fixed, the test suite has been expanded, and
-the build process simplified.
-
-        * Updated the documentation accordingly.
-
-        
-1.0.1
-=====
-        
-        * Changed files to work with Python 1.4 .
-
-        * The DES and DES3 modules now automatically correct the
-parity of their keys.
-        
-        * Added R. Rivest's DES test (see http://theory.lcs.mit.edu/~rivest/destest.txt)
-
-
-1.0.0
-=====
-
-        * REDOC III succumbed to differential cryptanalysis, and has
-been removed. 
-
-        * The crypt and rotor modules have been dropped; they're still
-available in the standard Python distribution. 
-
-        * The Ultra-Fast crypt() module has been placed in a separate
-distribution.
-
-        * Various bugs fixed.

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Cipher/__init__.py
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Cipher/__init__.py b/tools/bin/pythonSrc/pycrypto-2.0.1/Cipher/__init__.py
deleted file mode 100644
index 3b2f855..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Cipher/__init__.py
+++ /dev/null
@@ -1,33 +0,0 @@
-"""Secret-key encryption algorithms.
-
-Secret-key encryption algorithms transform plaintext in some way that
-is dependent on a key, producing ciphertext. This transformation can
-easily be reversed, if (and, hopefully, only if) one knows the key.
-
-The encryption modules here all support the interface described in PEP
-272, "API for Block Encryption Algorithms".
-
-If you don't know which algorithm to choose, use AES because it's
-standard and has undergone a fair bit of examination.
-
-Crypto.Cipher.AES         Advanced Encryption Standard
-Crypto.Cipher.ARC2        Alleged RC2
-Crypto.Cipher.ARC4        Alleged RC4
-Crypto.Cipher.Blowfish
-Crypto.Cipher.CAST
-Crypto.Cipher.DES         The Data Encryption Standard.  Very commonly used
-                          in the past, but today its 56-bit keys are too small.
-Crypto.Cipher.DES3        Triple DES.
-Crypto.Cipher.IDEA
-Crypto.Cipher.RC5
-Crypto.Cipher.XOR         The simple XOR cipher.
-"""
-
-__all__ = ['AES', 'ARC2', 'ARC4',
-           'Blowfish', 'CAST', 'DES', 'DES3', 'IDEA', 'RC5',
-           'XOR'
-           ]
-
-__revision__ = "$Id: __init__.py,v 1.7 2003/02/28 15:28:35 akuchling Exp $"
-
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex b/tools/bin/pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex
deleted file mode 100644
index d9c9bf6..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex
+++ /dev/null
@@ -1,1188 +0,0 @@
-\documentclass{howto}
-
-\title{Python Cryptography Toolkit}
-
-\release{2.0.1}
-
-\author{A.M. Kuchling}
-\authoraddress{\url{www.amk.ca}}
-
-\begin{document}
-\maketitle
-
-\begin{abstract}
-\noindent
-The Python Cryptography Toolkit describes a package containing various
-cryptographic modules for the Python programming language.  This
-documentation assumes you have some basic knowledge about the Python
-language, but not necessarily about cryptography.
-
-\end{abstract}
-
-\tableofcontents
-
-
-%======================================================================
-\section{Introduction}
-
-\subsection{Design Goals}
-The Python cryptography toolkit is intended to provide a reliable and
-stable base for writing Python programs that require cryptographic
-functions.
-
-A central goal of the author's has been to provide a simple,
-consistent interface for similar classes of algorithms.  For example,
-all block cipher objects have the same methods and return values, and
-support the same feedback modes.  Hash functions have a different
-interface, but it too is consistent over all the hash functions
-available.  Some of these interfaces have been codified as Python
-Enhancement Proposal documents, as \pep{247}, ``API for Cryptographic
-Hash Functions'', and \pep{272}, ``API for Block Encryption
-Algorithms''.  
-
-This is intended to make it easy to replace old algorithms with newer,
-more secure ones.  If you're given a bit of portably-written Python
-code that uses the DES encryption algorithm, you should be able to use
-AES instead by simply changing \code{from Crypto.Cipher import DES} to
-\code{from Crypto.Cipher import AES}, and changing all references to
-\code{DES.new()} to \code{AES.new()}.  It's also fairly simple to
-write your own modules that mimic this interface, thus letting you use
-combinations or permutations of algorithms.
-
-Some modules are implemented in C for performance; others are written
-in Python for ease of modification.  Generally, low-level functions
-like ciphers and hash functions are written in C, while less
-speed-critical functions have been written in Python.  This division
-may change in future releases.  When speeds are quoted in this
-document, they were measured on a 500 MHz Pentium II running Linux.
-The exact speeds will obviously vary with different machines,
-different compilers, and the phase of the moon, but they provide a
-crude basis for comparison.  Currently the cryptographic
-implementations are acceptably fast, but not spectacularly good.  I
-welcome any suggestions or patches for faster code.
-
-I have placed the code under no restrictions; you can redistribute the
-code freely or commercially, in its original form or with any
-modifications you make, subject to whatever local laws may apply in your
-jurisdiction.  Note that you still have to come to some agreement with
-the holders of any patented algorithms you're using.  If you're
-intensively using these modules, please tell me about it; there's little
-incentive for me to work on this package if I don't know of anyone using
-it.
-
-I also make no guarantees as to the usefulness, correctness, or legality
-of these modules, nor does their inclusion constitute an endorsement of
-their effectiveness.  Many cryptographic algorithms are patented;
-inclusion in this package does not necessarily mean you are allowed to
-incorporate them in a product and sell it.  Some of these algorithms may
-have been cryptanalyzed, and may no longer be secure.  While I will
-include commentary on the relative security of the algorithms in the
-sections entitled "Security Notes", there may be more recent analyses
-I'm not aware of.  (Or maybe I'm just clueless.)  If you're implementing
-an important system, don't just grab things out of a toolbox and put
-them together; do some research first.  On the other hand, if you're
-just interested in keeping your co-workers or your relatives out of your
-files, any of the components here could be used.
-
-This document is very much a work in progress.  If you have any
-questions, comments, complaints, or suggestions, please send them to me.
-
-\subsection{Acknowledgements}
-Much of the code that actually implements the various cryptographic
-algorithms was not written by me.  I'd like to thank all the people who
-implemented them, and released their work under terms which allowed me
-to use their code.  These individuals are credited in the relevant
-chapters of this documentation.  Bruce Schneier's book \emph{Applied
-Cryptography} was also very useful in writing this toolkit; I highly
-recommend it if you're interested in learning more about cryptography.
-
-Good luck with your cryptography hacking!
-
-A.M.K.
-
-\email{comments@amk.ca}
-
-Washington DC, USA
-
-June 2005
-
-
-%======================================================================
-\section{Crypto.Hash: Hash Functions}
-
-Hash functions take arbitrary strings as input, and produce an output
-of fixed size that is dependent on the input; it should never be
-possible to derive the input data given only the hash function's
-output.  One simple hash function consists of simply adding together
-all the bytes of the input, and taking the result modulo 256.  For a
-hash function to be cryptographically secure, it must be very
-difficult to find two messages with the same hash value, or to find a
-message with a given hash value.  The simple additive hash function
-fails this criterion miserably and the hash functions described below
-meet this criterion (as far as we know).  Examples of
-cryptographically secure hash functions include MD2, MD5, and SHA1.
-
-Hash functions can be used simply as a checksum, or, in association with a
-public-key algorithm, can be used to implement digital signatures.
- 
-The hashing algorithms currently implemented are:
-
-\begin{tableii}{c|l}{}{Hash function}{Digest length}
-\lineii{MD2}{128 bits}
-\lineii{MD4}{128 bits}
-\lineii{MD5}{128 bits}
-\lineii{RIPEMD}{160 bits}
-\lineii{SHA1}{160 bits}
-\lineii{SHA256}{256 bits}
-\end{tableii}
-
-All hashing modules share the same interface.  After importing a given
-hashing module, call the \function{new()} function to create a new
-hashing object. You can now feed arbitrary strings into the object
-with the \method{update()} method, and can ask for the hash value at
-any time by calling the \method{digest()} or \method{hexdigest()}
-methods.  The \function{new()} function can also be passed an optional
-string parameter that will be immediately hashed into the object's
-state.
-
-Hash function modules define one variable:
-
-\begin{datadesc}{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 \member{digest_size} is faster.
-\end{datadesc}
-
-The methods for hashing objects are always the following:
-
-\begin{methoddesc}{copy}{}
-Return a separate copy of this hashing object.  An \code{update} to
-this copy won't affect the original object.
-\end{methoddesc}
-
-\begin{methoddesc}{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.
-\end{methoddesc}
-
-\begin{methoddesc}{hexdigest}{}
-Return the hash value of this hashing object, as a string containing
-the digest data as hexadecimal digits.  The resulting string will be
-twice as long as that returned by \method{digest()}.  The object is not
-altered in any way by this function; you can continue updating the
-object after calling this function.
-\end{methoddesc}
-
-\begin{methoddesc}{update}{arg}
-Update this hashing object with the string \var{arg}.
-\end{methoddesc}
-
-Here's an example, using the MD5 algorithm:
-
-\begin{verbatim}
->>> from Crypto.Hash import MD5
->>> m = MD5.new()
->>> m.update('abc')
->>> m.digest()
-'\x90\x01P\x98<\xd2O\xb0\xd6\x96?}(\xe1\x7fr'
->>> m.hexdigest()
-'900150983cd24fb0d6963f7d28e17f72'
-\end{verbatim}
-
-
-\subsection{Security Notes}
-
-Hashing algorithms are broken by developing an algorithm to compute a
-string that produces a given hash value, or to find two messages that
-produce the same hash value. Consider an example where Alice and Bob
-are using digital signatures to sign a contract.  Alice computes the
-hash value of the text of the contract and signs the hash value with
-her private key.  Bob could then compute a different contract that has
-the same hash value, and it would appear that Alice signed that bogus
-contract; she'd have no way to prove otherwise.  Finding such a
-message by brute force takes \code{pow(2, b-1)} operations, where the
-hash function produces \emph{b}-bit hashes.
-
-If Bob can only find two messages with the same hash value but can't
-choose the resulting hash value, he can look for two messages with
-different meanings, such as "I will mow Bob's lawn for $10" and "I owe
-Bob $1,000,000", and ask Alice to sign the first, innocuous contract.
-This attack is easier for Bob, since finding two such messages by brute
-force will take \code{pow(2, b/2)} operations on average.  However,
-Alice can protect herself by changing the protocol; she can simply
-append a random string to the contract before hashing and signing it;
-the random string can then be kept with the signature.
-
-None of the algorithms implemented here have been completely broken.
-There are no attacks on MD2, but it's rather slow at 1250 K/sec.  MD4
-is faster at 44,500 K/sec but there have been some partial attacks on
-it.  MD4 makes three iterations of a basic mixing operation; two of
-the three rounds have been cryptanalyzed, but the attack can't be
-extended to the full algorithm.  MD5 is a strengthened version of MD4
-with four rounds; an attack against one round has been found XXX
-update this.  MD5 is still believed secure at the moment, but people
-are gravitating toward using SHA1 in new software because there are no
-known attacks against SHA1.  The MD5 implementation is moderately
-well-optimized and thus faster on x86 processors, running at 35,500
-K/sec.  MD5 may even be faster than MD4, depending on the processor
-and compiler you use.
-
-All the MD\var{n} algorithms produce 128-bit hashes; SHA1 produces a
-larger 160-bit hash, and there are no known attacks against it.  The
-first version of SHA had a weakness which was later corrected; the
-code used here implements the second, corrected, version.  It operates
-at 21,000 K/sec.  SHA256 is about as half as fast as SHA1.  RIPEMD has
-a 160-bit output, the same output size as SHA1, and operates at 17,600
-K/sec.
-
-\subsection{Credits}
-The MD2 and MD4 implementations were written by A.M. Kuchling, and the
-MD5 code was implemented by Colin Plumb.  The SHA1 code was originally
-written by Peter Gutmann.  The RIPEMD code was written by Antoon
-Bosselaers, and adapted for the toolkit by Hirendra Hindocha.  The
-SHA256 code was written by Tom St.~Denis and is part of the
-LibTomCrypt library (\url{http://www.libtomcrypt.org/}); it was
-adapted for the toolkit by Jeethu Rao and Taylor Boon.
-
-
-%======================================================================
-\section{Crypto.Cipher: Encryption Algorithms}
-
-Encryption algorithms transform their input data, or \dfn{plaintext},
-in some way that is dependent on a variable \dfn{key}, producing
-\dfn{ciphertext}. This transformation can easily be reversed, if (and,
-hopefully, only if) one knows the key.  The key can be varied by the
-user or application and chosen from some very large space of possible
-keys.
-
-For a secure encryption algorithm, it should be very difficult to
-determine the original plaintext without knowing the key; usually, no
-clever attacks on the algorithm are known, so the only way of breaking
-the algorithm is to try all possible keys. Since the number of possible
-keys is usually of the order of 2 to the power of 56 or 128, this is not
-a serious threat, although 2 to the power of 56 is now considered
-insecure in the face of custom-built parallel computers and distributed
-key guessing efforts.
-
-\dfn{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 modes.  The simplest is Electronic Code Book
-(or ECB) mode.  In this mode, each block of plaintext is simply
-encrypted to produce the ciphertext.  This mode can be dangerous,
-because many files will contain patterns greater than the block size;
-for example, the comments in a C program may contain long strings of
-asterisks intended to form a box.  All these identical blocks will
-encrypt to identical ciphertext; an adversary may be able to use this
-structure to obtain some information about the text.
-
-To eliminate this weakness, there are various feedback modes in which
-the plaintext is combined with the previous ciphertext before
-encrypting; this eliminates any repetitive structure in the
-ciphertext.   
-
-One mode is Cipher Block Chaining (CBC mode); another is Cipher
-FeedBack (CFB mode).  CBC mode still encrypts in blocks, and thus is
-only slightly slower than ECB mode.  CFB mode encrypts on a
-byte-by-byte basis, and is much slower than either of the other two
-modes.  The chaining feedback modes require an initialization value to
-start off the encryption; this is a string of the same length as the
-ciphering algorithm's block size, and is passed to the \code{new()}
-function.  There is also a special PGP mode, which is an oddball
-variant of CFB used by the PGP program.  While you can use it in
-non-PGP programs, it's quite non-standard.
-
-The currently available block ciphers are listed in the following table,
-and are in the \code{Crypto.Cipher} package:
-
-\begin{tableii}{c|l}{}{Cipher}{Key Size/Block Size}
-\lineii{AES}{16, 24, or 32 bytes/16 bytes}
-\lineii{ARC2}{Variable/8 bytes}
-\lineii{Blowfish}{Variable/8 bytes}
-\lineii{CAST}{Variable/8 bytes}
-\lineii{DES}{8 bytes/8 bytes}
-\lineii{DES3 (Triple DES)}{16 bytes/8 bytes}
-\lineii{IDEA}{16 bytes/8 bytes}
-\lineii{RC5}{Variable/8 bytes}
-\end{tableii}
-
-In a strict formal sense, \dfn{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. 
-
-The currently available stream ciphers are listed in the following table:
-
-\begin{tableii}{c|l}{}{Cipher}{Key Size}
-\lineii{Cipher}{Key Size}
-  \lineii{ARC4}{Variable}
-  \lineii{XOR}{Variable}
-\end{tableii}
-
-ARC4 is short for `Alleged RC4'.  In September of 1994, someone posted
-C code to both the Cypherpunks mailing list and to the Usenet
-newsgroup \code{sci.crypt}, claiming that it implemented the RC4
-algorithm.  This claim turned out to be correct.  Note that there's a
-damaging class of weak RC4 keys; this module won't warn you about such keys.
-% XXX other analyses of RC4?
-
-A similar anonymous posting was made for Alleged RC2 in January, 1996.
-
-An example usage of the DES module:
-\begin{verbatim}
->>> from Crypto.Cipher import DES
->>> obj=DES.new('abcdefgh', DES.MODE_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'
-\end{verbatim}
-
-All cipher algorithms share a common interface.  After importing a
-given module, there is exactly one function and two variables
-available.
-
-\begin{funcdesc}{new}{key, mode\optional{, IV}}
-Returns a ciphering object, using \var{key} and feedback mode
-\var{mode}.  If \var{mode} is \constant{MODE_CBC} or \constant{MODE_CFB}, \var{IV} must be provided,
-and must be a string of the same length as the block size.  Some
-algorithms support additional keyword arguments to this function; see
-the "Algorithm-specific Notes for Encryption Algorithms" section below for the details.
-\end{funcdesc}
-
-\begin{datadesc}{block_size}
-An integer value; the size of the blocks encrypted by this module.
-Strings passed to the \code{encrypt} and \code{decrypt} functions
-must be a multiple of this length.  For stream ciphers,
-\code{block_size} will be 1. 
-\end{datadesc}
-
-\begin{datadesc}{key_size}
-An integer value; the size of the keys required by this module.  If
-\code{key_size} is zero, then the algorithm accepts arbitrary-length
-keys.  You cannot pass a key of length 0 (that is, the null string
-\code{''} as such a variable-length key.  
-\end{datadesc}
-
-All cipher objects have at least three attributes:
-
-\begin{memberdesc}{block_size}
-An integer value equal to the size of the blocks encrypted by this object.
-Identical to the module variable of the same name.
-\end{memberdesc}
-
-\begin{memberdesc}{IV}
-Contains the initial value which will be used to start a cipher
-feedback mode.  After encrypting or decrypting a string, this value
-will reflect the modified feedback text; it will always be one block
-in length.  It is read-only, and cannot be assigned a new value.
-\end{memberdesc}
-
-\begin{memberdesc}{key_size}
-An integer value equal to the size of the keys used by this object.  If
-\code{key_size} 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.  
-\end{memberdesc}
-
-All ciphering objects have the following methods:
-
-\begin{methoddesc}{decrypt}{string}
-Decrypts \var{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.
-\end{methoddesc}
-
-\begin{methoddesc}{encrypt}{string}
-Encrypts a non-null \var{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.
-\end{methoddesc}
-
-
-\subsection{Algorithm-specific Notes for Encryption Algorithms}
-
-RC5 has a bunch of parameters; see Ronald Rivest's paper at
-\url{http://theory.lcs.mit.edu/~rivest/rc5rev.ps} for the
-implementation details.  The keyword parameters are:
-
-\begin{itemize}
-\item \code{version}:
-The version
-of the RC5 algorithm to use; currently the only legal value is
-\code{0x10} for RC5 1.0.  
-\item \code{wordsize}:
-The word size to use;
-16 or 32 are the only legal values.  (A larger word size is better, so
-usually 32 will be used.  16-bit RC5 is probably only of academic
-interest.)  
-\item \code{rounds}:
-The number of rounds to apply, the larger the more secure: this
-can be any value from 0 to 255, so you will have to choose a value
-balanced between speed and security. 
-\end{itemize}
-
-
-\subsection{Security Notes}
-Encryption algorithms can be broken in several ways.  If you have some
-ciphertext and know (or can guess) the corresponding plaintext, you can
-simply try every possible key in a \dfn{known-plaintext} attack.  Or, it
-might be possible to encrypt text of your choice using an unknown key;
-for example, you might mail someone a message intending it to be
-encrypted and forwarded to someone else.  This is a
-\dfn{chosen-plaintext} attack, which is particularly effective if it's
-possible to choose plaintexts that reveal something about the key when
-encrypted.
-
-DES (5100 K/sec) has a 56-bit key; this is starting to become too small
-for safety.  It has been estimated that it would only cost \$1,000,000 to
-build a custom DES-cracking machine that could find a key in 3 hours.  A
-chosen-ciphertext attack using the technique of \dfn{linear
-cryptanalysis} can break DES in \code{pow(2, 43)} steps.  However,
-unless you're encrypting data that you want to be safe from major
-governments, DES will be fine. DES3 (1830 K/sec) uses three DES
-encryptions for greater security and a 112-bit or 168-bit key, but is
-correspondingly slower.
-
-There are no publicly known attacks against IDEA (3050 K/sec), and
-it's been around long enough to have been examined.  There are no
-known attacks against ARC2 (2160 K/sec), ARC4 (8830 K/sec), Blowfish
-(9250 K/sec), CAST (2960 K/sec), or RC5 (2060 K/sec), but they're all
-relatively new algorithms and there hasn't been time for much analysis
-to be performed; use them for serious applications only after careful
-research.
-
-AES, the Advanced Encryption Standard, was chosen by the US National
-Institute of Standards and Technology from among 6 competitors, and is
-probably your best choice.  It runs at 7060 K/sec, so it's among the
-faster algorithms around.
-
-
-\subsection{Credits}
-The code for Blowfish was written by Bryan Olson, partially based on a
-previous implementation by Bruce Schneier, who also invented the
-algorithm; the Blowfish algorithm has been placed in the public domain
-and can be used freely.  (See \url{http://www.counterpane.com} for more
-information about Blowfish.)  The CAST implementation was written by 
-Wim Lewis.  The DES implementation was written by Eric Young, and the
-IDEA implementation by Colin Plumb. The RC5 implementation
-was written by A.M. Kuchling.
-
-The Alleged RC4 code was posted to the \code{sci.crypt} newsgroup by an
-unknown party, and re-implemented by A.M. Kuchling.  
-
-
-%======================================================================
-\section{Crypto.Protocol: Various Protocols}
-
-\subsection{Crypto.Protocol.AllOrNothing}
-
-This module implements all-or-nothing package transformations.
-An all-or-nothing package transformation is one in which some text is
-transformed into message blocks, such that all blocks must be obtained before
-the reverse transformation can be applied.  Thus, if any blocks are corrupted
-or lost, the original message cannot be reproduced.
-
-An all-or-nothing package transformation is not encryption, although a block
-cipher algorithm is used.  The encryption key is randomly generated and is
-extractable from the message blocks.
-
-\begin{classdesc}{AllOrNothing}{ciphermodule, mode=None, IV=None}
-Class implementing the All-or-Nothing package transform.
-
-\var{ciphermodule} is a module implementing the cipher algorithm to
-use.  Optional arguments \var{mode} and \var{IV} are passed directly
-through to the \var{ciphermodule}.\code{new()} method; they are the
-feedback mode and initialization vector to use.  All three arguments
-must be the same for the object used to create the digest, and to
-undigest'ify the message blocks.
-
-The module passed as \var{ciphermodule} must provide the \pep{272}
-interface.  An encryption key is randomly generated automatically when
-needed.
-\end{classdesc}
-
-The methods of the \class{AllOrNothing} class are:
-
-\begin{methoddesc}{digest}{text}
-Perform the All-or-Nothing package transform on the 
-string \var{text}.  Output is a list of message blocks describing the
-transformed text, where each block is a string of bit length equal
-to the cipher module's block_size.
-\end{methoddesc}
-
-\begin{methoddesc}{undigest}{mblocks}
-Perform the reverse package transformation on a list of message
-blocks.  Note that the cipher module used for both transformations
-must be the same.  \var{mblocks} is a list of strings of bit length
-equal to \var{ciphermodule}'s block_size.  The output is a string object.
-\end{methoddesc}
-
-
-\subsection{Crypto.Protocol.Chaffing}
-
-Winnowing and chaffing is a technique for enhancing privacy without requiring
-strong encryption.  In short, the technique takes a set of authenticated
-message blocks (the wheat) and adds a number of chaff blocks which have
-randomly chosen data and MAC fields.  This means that to an adversary, the
-chaff blocks look as valid as the wheat blocks, and so the authentication
-would have to be performed on every block.  By tailoring the number of chaff
-blocks added to the message, the sender can make breaking the message
-computationally infeasible.  There are many other interesting properties of
-the winnow/chaff technique.
-
-For example, say Alice is sending a message to Bob.  She packetizes the
-message and performs an all-or-nothing transformation on the packets.  Then
-she authenticates each packet with a message authentication code (MAC).  The
-MAC is a hash of the data packet, and there is a secret key which she must
-share with Bob (key distribution is an exercise left to the reader).  She then
-adds a serial number to each packet, and sends the packets to Bob.
-
-Bob receives the packets, and using the shared secret authentication key,
-authenticates the MACs for each packet.  Those packets that have bad MACs are
-simply discarded.  The remainder are sorted by serial number, and passed
-through the reverse all-or-nothing transform.  The transform means that an
-eavesdropper (say Eve) must acquire all the packets before any of the data can
-be read.  If even one packet is missing, the data is useless.
-
-There's one twist: by adding chaff packets, Alice and Bob can make Eve's job
-much harder, since Eve now has to break the shared secret key, or try every
-combination of wheat and chaff packet to read any of the message.  The cool
-thing is that Bob doesn't need to add any additional code; the chaff packets
-are already filtered out because their MACs don't match (in all likelihood --
-since the data and MACs for the chaff packets are randomly chosen it is
-possible, but very unlikely that a chaff MAC will match the chaff data).  And
-Alice need not even be the party adding the chaff!  She could be completely
-unaware that a third party, say Charles, is adding chaff packets to her
-messages as they are transmitted.
-
-\begin{classdesc}{Chaff}{factor=1.0, blocksper=1}
-Class implementing the chaff adding algorithm. 
-\var{factor} is the number of message blocks 
-            to add chaff to, expressed as a percentage between 0.0 and 1.0; the default value is 1.0.
-\var{blocksper} is the number of chaff blocks to include for each block
-            being chaffed, and defaults to 1.  The default settings 
-add one chaff block to every
-            message block.  By changing the defaults, you can adjust how
-            computationally difficult it could be for an adversary to
-            brute-force crack the message.  The difficulty is expressed as:
-
-\begin{verbatim}
-pow(blocksper, int(factor * number-of-blocks))
-\end{verbatim}
-
-For ease of implementation, when \var{factor} < 1.0, only the first
-\code{int(\var{factor}*number-of-blocks)} message blocks are chaffed.
-\end{classdesc}
-
-\class{Chaff} instances have the following methods:
-
-\begin{methoddesc}{chaff}{blocks}
-Add chaff to message blocks.  \var{blocks} is a list of 3-tuples of the
-form (\var{serial-number}, \var{data}, \var{MAC}).
-
-Chaff is created by choosing a random number of the same
-byte-length as \var{data}, and another random number of the same
-byte-length as \var{MAC}.  The message block's serial number is placed
-on the chaff block and all the packet's chaff blocks are randomly
-interspersed with the single wheat block.  This method then
-returns a list of 3-tuples of the same form.  Chaffed blocks will
-contain multiple instances of 3-tuples with the same serial
-number, but the only way to figure out which blocks are wheat and
-which are chaff is to perform the MAC hash and compare values.
-\end{methoddesc}
-
-
-%======================================================================
-\section{Crypto.PublicKey: Public-Key Algorithms}
-So far, the encryption algorithms described have all been \dfn{private
-key} ciphers.  The same key is used for both encryption and decryption
-so all correspondents must know it.  This poses a problem: you may
-want encryption to communicate sensitive data over an insecure
-channel, but how can you tell your correspondent what the key is?  You
-can't just e-mail it to her because the channel is insecure.  One
-solution is to arrange the key via some other way: over the phone or
-by meeting in person.
-
-Another solution is to use \dfn{public-key} cryptography.  In a public
-key system, there are two different keys: one for encryption and one for
-decryption.  The encryption key can be made public by listing it in a
-directory or mailing it to your correspondent, while you keep the
-decryption key secret.  Your correspondent then sends you data encrypted
-with your public key, and you use the private key to decrypt it.  While
-the two keys are related, it's very difficult to derive the private key
-given only the public key; however, deriving the private key is always
-possible given enough time and computing power.  This makes it very
-important to pick keys of the right size: large enough to be secure, but
-small enough to be applied fairly quickly.
-
-Many public-key algorithms can also be used to sign messages; simply
-run the message to be signed through a decryption with your private
-key key.  Anyone receiving the message can encrypt it with your
-publicly available key and read the message.  Some algorithms do only
-one thing, others can both encrypt and authenticate.
-
-The currently available public-key algorithms are listed in the
-following table:
-
-\begin{tableii}{c|l}{}{Algorithm}{Capabilities}
-\lineii{RSA}{Encryption, authentication/signatures}
-\lineii{ElGamal}{Encryption, authentication/signatures}
-\lineii{DSA}{Authentication/signatures}
-\lineii{qNEW}{Authentication/signatures}
-\end{tableii}
-
-Many of these algorithms are patented.  Before using any of them in a
-commercial product, consult a patent attorney; you may have to arrange
-a license with the patent holder.
-
-An example of using the RSA module to sign a message:
-\begin{verbatim}
->>> from Crypto.Hash import MD5
->>> from Crypto.PublicKey import RSA
->>> RSAkey = RSA.generate(384, randfunc)   # This will take a while...
->>> hash = MD5.new(plaintext).digest()
->>> signature = RSAkey.sign(hash, "")
->>> signature   # Print what an RSA sig looks like--you don't really care.
-('\021\317\313\336\264\315' ...,)
->>> RSAkey.verify(hash, signature)     # This sig will check out
-1
->>> RSAkey.verify(hash[:-1], signature)# This sig will fail
-0
-\end{verbatim}
-
-Public-key modules make the following functions available:
-
-\begin{funcdesc}{construct}{tuple}
-Constructs a key object from a tuple of data.  This is
-algorithm-specific; look at the source code for the details.  (To be
-documented later.)
-\end{funcdesc}
-
-\begin{funcdesc}{generate}{size, randfunc, progress_func=\code{None}}
-Generate a fresh public/private key pair.  \var{size} is a
-algorithm-dependent size parameter, usually measured in bits; the
-larger it is, the more difficult it will be to break the key.  Safe
-key sizes vary from algorithm to algorithm; you'll have to research
-the question and decide on a suitable key size for your application.
-An N-bit keys can encrypt messages up to N-1 bits long.
-
-\var{randfunc} is a random number generation function; it should
-accept a single integer \var{N} and return a string of random data
-\var{N} bytes long.  You should always use a cryptographically secure
-random number generator, such as the one defined in the
-\module{Crypto.Util.randpool} module; \emph{don't} just use the
-current time and the \module{random} module. 
-
-\var{progress_func} is an optional function that will be called with a short
-string containing the key parameter currently being generated; it's
-useful for interactive applications where a user is waiting for a key
-to be generated.
-\end{funcdesc}
-
-If you want to interface with some other program, you will have to know
-the details of the algorithm being used; this isn't a big loss.  If you
-don't care about working with non-Python software, simply use the
-\module{pickle} module when you need to write a key or a signature to a
-file.  It's portable across all the architectures that Python supports,
-and it's simple to use.
-
-Public-key objects always support the following methods.  Some of them
-may raise exceptions if their functionality is not supported by the
-algorithm.
-
-\begin{methoddesc}{can_blind}{}
-Returns true if the algorithm is capable of blinding data; 
-returns false otherwise.  
-\end{methoddesc}
-
-\begin{methoddesc}{can_encrypt}{}
-Returns true if the algorithm is capable of encrypting and decrypting
-data; returns false otherwise.  To test if a given key object can encrypt
-data, use \code{key.can_encrypt() and key.has_private()}.
-\end{methoddesc}
-
-\begin{methoddesc}{can_sign}{}
-Returns true if the algorithm is capable of signing data; returns false
-otherwise.  To test if a given key object can sign data, use
-\code{key.can_sign() and key.has_private()}.
-\end{methoddesc}
-
-\begin{methoddesc}{decrypt}{tuple}
-Decrypts \var{tuple} with the private key, returning another string.
-This requires the private key to be present, and will raise an exception
-if it isn't present.  It will also raise an exception if \var{string} is
-too long.
-\end{methoddesc}
-
-\begin{methoddesc}{encrypt}{string, K}
-Encrypts \var{string} with the private key, returning a tuple of
-strings; the length of the tuple varies from algorithm to algorithm.  
-\var{K} should be a string of random data that is as long as
-possible.  Encryption does not require the private key to be present
-inside the key object.  It will raise an exception if \var{string} is
-too long.  For ElGamal objects, the value of \var{K} expressed as a
-big-endian integer must be relatively prime to \code{self.p-1}; an
-exception is raised if it is not.
-\end{methoddesc}
-
-\begin{methoddesc}{has_private}{}
-Returns true if the key object contains the private key data, which
-will allow decrypting data and generating signatures.
-Otherwise this returns false.
-\end{methoddesc}
-
-\begin{methoddesc}{publickey}{}
-Returns a new public key object that doesn't contain the private key
-data. 
-\end{methoddesc}
-
-\begin{methoddesc}{sign}{string, K}
-Sign \var{string}, returning a signature, which is just a tuple; in
-theory the signature may be made up of any Python objects at all; in
-practice they'll be either strings or numbers.  \var{K} should be a
-string of random data that is as long as possible.  Different algorithms
-will return tuples of different sizes.  \code{sign()} raises an
-exception if \var{string} is too long.  For ElGamal objects, the value
-of \var{K} expressed as a big-endian integer must be relatively prime to
-\code{self.p-1}; an exception is raised if it is not.
-\end{methoddesc}
-
-\begin{methoddesc}{size}{}
-Returns the maximum size of a string that can be encrypted or signed,
-measured in bits.  String data is treated in big-endian format; the most
-significant byte comes first.  (This seems to be a \emph{de facto} standard
-for cryptographical software.)  If the size is not a multiple of 8, then
-some of the high order bits of the first byte must be zero.  Usually
-it's simplest to just divide the size by 8 and round down.
-\end{methoddesc}
-
-\begin{methoddesc}{verify}{string, signature}
-Returns true if the signature is valid, and false otherwise.
-\var{string} is not processed in any way; \code{verify} does
-not run a hash function over the data, but you can easily do that yourself.
-\end{methoddesc}
-
-\subsection{The ElGamal and DSA algorithms}
-For RSA, the \var{K} parameters are unused; if you like, you can just
-pass empty strings.  The ElGamal and DSA algorithms require a real
-\var{K} value for technical reasons; see Schneier's book for a detailed
-explanation of the respective algorithms.  This presents a possible
-hazard that can  
-inadvertently reveal the private key.  Without going into the
-mathematical details, the danger is as follows. \var{K} is never derived
-or needed by others; theoretically, it can be thrown away once the
-encryption or signing operation is performed.  However, revealing
-\var{K} for a given message would enable others to derive the secret key
-data; worse, reusing the same value of \var{K} for two different
-messages would also enable someone to derive the secret key data.  An
-adversary could intercept and store every message, and then try deriving
-the secret key from each pair of messages.
-
-This places implementors on the horns of a dilemma.  On the one hand,
-you want to store the \var{K} values to avoid reusing one; on the other
-hand, storing them means they could fall into the hands of an adversary.
-One can randomly generate \var{K} values of a suitable length such as
-128 or 144 bits, and then trust that the random number generator
-probably won't produce a duplicate anytime soon.  This is an
-implementation decision that depends on the desired level of security
-and the expected usage lifetime of a private key.  I can't choose and
-enforce one policy for this, so I've added the \var{K} parameter to the
-\method{encrypt} and \method{sign} methods.  You must choose \var{K} by
-generating a string of random data; for ElGamal, when interpreted as a
-big-endian number (with the most significant byte being the first byte
-of the string), \var{K} must be relatively prime to \code{self.p-1}; any
-size will do, but brute force searches would probably start with small
-primes, so it's probably good to choose fairly large numbers.  It might be
-simplest to generate a prime number of a suitable length using the
-\module{Crypto.Util.number} module.
-
-
-\subsection{Security Notes for Public-key Algorithms}
-Any of these algorithms can be trivially broken; for example, RSA can be
-broken by factoring the modulus \emph{n} into its two prime factors.
-This is easily done by the following code:
-
-\begin{verbatim}
-for i in range(2, n): 
-    if (n%i)==0: 
-        print i, 'is a factor' 
-        break
-\end{verbatim}
-
-However, \emph{n} is usually a few hundred bits long, so this simple
-program wouldn't find a solution before the universe comes to an end.
-Smarter algorithms can factor numbers more quickly, but it's still
-possible to choose keys so large that they can't be broken in a
-reasonable amount of time.  For ElGamal and DSA, discrete logarithms are
-used instead of factoring, but the principle is the same.
-
-Safe key sizes depend on the current state of number theory and
-computer technology.  At the moment, one can roughly define three
-levels of security: low-security commercial, high-security commercial,
-and military-grade.  For RSA, these three levels correspond roughly to
-768, 1024, and 2048-bit keys.
-
-
-%======================================================================
-\section{Crypto.Util: Odds and Ends}
-This chapter contains all the modules that don't fit into any of the
-other chapters.  
-
-\subsection{Crypto.Util.number}
-
-This module contains various number-theoretic functions.  
-
-\begin{funcdesc}{GCD}{x,y}
-Return the greatest common divisor of \var{x} and \var{y}.
-\end{funcdesc}
-
-\begin{funcdesc}{getPrime}{N, randfunc}
-Return an \var{N}-bit random prime number, using random data obtained
-from the function \var{randfunc}.  \var{randfunc} must take a single
-integer argument, and return a string of random data of the
-corresponding length; the \method{get_bytes()} method of a
-\class{RandomPool} object will serve the purpose nicely, as will the
-\method{read()} method of an opened file such as \file{/dev/random}.
-\end{funcdesc}
-
-\begin{funcdesc}{getRandomNumber}{N, randfunc}
-Return an \var{N}-bit random number, using random data obtained from the
-function \var{randfunc}.  As usual, \var{randfunc} must take a single
-integer argument and return a string of random data of the
-corresponding length.
-\end{funcdesc}
-
-\begin{funcdesc}{inverse}{u, v}
-Return the inverse of \var{u} modulo \var{v}.
-\end{funcdesc}
-
-\begin{funcdesc}{isPrime}{N}
-Returns true if the number \var{N} is prime, as determined by a
-Rabin-Miller test.
-\end{funcdesc}
-
-
-\subsection{Crypto.Util.randpool}
-
-For cryptographic purposes, ordinary random number generators are
-frequently insufficient, because if some of their output is known, it
-is frequently possible to derive the generator's future (or past)
-output.  Given the generator's state at some point in time, someone
-could try to derive any keys generated using it.  The solution is to
-use strong encryption or hashing algorithms to generate successive
-data; this makes breaking the generator as difficult as breaking the
-algorithms used.
-
-Understanding the concept of \dfn{entropy} is important for using the
-random number generator properly.  In the sense we'll be using it,
-entropy measures the amount of randomness; the usual unit is in bits.
-So, a single random bit has an entropy of 1 bit; a random byte has an
-entropy of 8 bits.  Now consider a one-byte field in a database containing a
-person's sex, represented as a single character \samp{M} or \samp{F}.
-What's the entropy of this field?  Since there are only two possible
-values, it's not 8 bits, but one; if you were trying to guess the value,
-you wouldn't have to bother trying \samp{Q} or \samp{@}.  
-
-Now imagine running that single byte field through a hash function that
-produces 128 bits of output.  Is the entropy of the resulting hash value
-128 bits?  No, it's still just 1 bit.  The entropy is a measure of how many
-possible states of the data exist.  For English
-text, the entropy of a five-character string is not 40 bits; it's
-somewhat less, because not all combinations would be seen.  \samp{Guido}
-is a possible string, as is \samp{In th}; \samp{zJwvb} is not.
-
-The relevance to random number generation?  We want enough bits of
-entropy to avoid making an attack on our generator possible.  An
-example: One computer system had a mechanism which generated nonsense
-passwords for its users.  This is a good idea, since it would prevent
-people from choosing their own name or some other easily guessed string.
-Unfortunately, the random number generator used only had 65536 states,
-which meant only 65536 different passwords would ever be generated, and
-it was easy to compute all the possible passwords and try them.  The
-entropy of the random passwords was far too low.  By the same token, if
-you generate an RSA key with only 32 bits of entropy available, there
-are only about 4.2 billion keys you could have generated, and an
-adversary could compute them all to find your private key.  See \rfc{1750},
-"Randomness Recommendations for Security", for an interesting discussion
-of the issues related to random number generation.
-
-The \module{randpool} module implements a strong random number generator
-in the \class{RandomPool} class.  The internal state consists of a string
-of random data, which is returned as callers request it.  The class
-keeps track of the number of bits of entropy left, and provides a function to
-add new random data; this data can be obtained in various ways, such as
-by using the variance in a user's keystroke timings.  
-
-\begin{classdesc}{RandomPool}{\optional{numbytes, cipher, hash} }
-An object of the \code{RandomPool} class can be created without
-parameters if desired.  \var{numbytes} sets the number of bytes of
-random data in the pool, and defaults to 160 (1280 bits). \var{hash}
-can be a string containing the module name of the hash function to use
-in stirring the random data, or a module object supporting the hashing
-interface.  The default action is to use SHA.
-
-The \var{cipher} argument is vestigial; it was removed from version
-1.1 so RandomPool would work even in the limited exportable subset of
-the code.  I recommend passing \var{hash} using a keyword argument so
-that someday I can safely delete the \var{cipher} argument
-
-\end{classdesc}
-
-\class{RandomPool} objects define the following variables and methods:
-
-\begin{methoddesc}{add_event}{time\optional{, string}}
-Adds an event to the random pool.  \var{time} should be set to the
-current system time, measured at the highest resolution available.
-\var{string} can be a string of data that will be XORed into the pool,
-and can be used to increase the entropy of the pool.  For example, if
-you're encrypting a document, you might use the hash value of the
-document; an adversary presumably won't have the plaintext of the
-document, and thus won't be able to use this information to break the
-generator.
-\end{methoddesc}
-
-The return value is the value of \member{self.entropy} after the data has
-been added.  The function works in the following manner: the time
-between successive calls to the \method{add_event()} method is determined,
-and the entropy of the data is guessed; the larger the time between
-calls, the better.  The system time is then read and added to the pool,
-along with the \var{string} parameter, if present.  The hope is that the
-low-order bits of the time are effectively random.  In an application,
-it is recommended that \method{add_event()} be called as frequently as
-possible, with whatever random data can be found.
-
-\begin{memberdesc}{bits}
-A constant integer value containing the number of bits of data in
-the pool, equal to the \member{bytes} attribute multiplied by 8.
-\end{memberdesc}
-
-\begin{memberdesc}{bytes}
-A constant integer value containing the number of bytes of data in
-the pool.
-\end{memberdesc}
-
-\begin{memberdesc}{entropy}
-An integer value containing the number of bits of entropy currently in
-the pool.  The value is incremented by the \method{add_event()} method,
-and decreased by the \method{get_bytes()} method.
-\end{memberdesc}
-
-\begin{methoddesc}{get_bytes}{num}
-Returns a string containing \var{num} bytes of random data, and
-decrements the amount of entropy available.  It is not an error to
-reduce the entropy to zero, or to call this function when the entropy
-is zero.  This simply means that, in theory, enough random information has been
-extracted to derive the state of the generator.  It is the caller's
-responsibility to monitor the amount of entropy remaining and decide
-whether it is sufficent for secure operation.
-\end{methoddesc}
-
-\begin{methoddesc}{stir}{}
-Scrambles the random pool using the previously chosen encryption and
-hash function.  An adversary may attempt to learn or alter the state
-of the pool in order to affect its future output; this function
-destroys the existing state of the pool in a non-reversible way.  It
-is recommended that \method{stir()} be called before and after using
-the \class{RandomPool} object.  Even better, several calls to
-\method{stir()} can be interleaved with calls to \method{add_event()}.
-\end{methoddesc}
-
-The \class{PersistentRandomPool} class is a subclass of \class{RandomPool} 
-that adds the capability to save and load the pool from a disk file.
-
-\begin{classdesc}{PersistentRandomPool}{filename, \optional{numbytes, cipher, hash}}
-The path given in \var{filename} will be automatically opened, and an
-existing random pool read; if no such file exists, the pool will be
-initialized as usual.  If omitted, the filename defaults to the empty
-string, which will prevent it from being saved to a file.  These
-arguments are identical to those for the \class{RandomPool}
-constructor.
-\end{classdesc}
-
-\begin{methoddesc}{save}{}
-Opens the file named by the \member{filename} attribute, and saves the
-random data into the file using the \module{pickle} module.
-\end{methoddesc}
-
-The \class{KeyboardRandomPool} class is a subclass of
-\class{PersistentRandomPool} that provides a method to obtain random
-data from the keyboard:
-
-\begin{methoddesc}{randomize}{}
-(Unix systems only)  Obtain random data from the keyboard.  This works
-by prompting the
-user to hit keys at random, and then using the keystroke timings (and
-also the actual keys pressed) to add entropy to the pool.  This works
-similarly to PGP's random pool mechanism.
-\end{methoddesc}
-
-
-\subsection{Crypto.Util.RFC1751}
-The keys for private-key algorithms should be arbitrary binary data.
-Many systems err by asking the user to enter a password, and then
-using the password as the key.  This limits the space of possible
-keys, as each key byte is constrained within the range of possible
-ASCII characters, 32-127, instead of the whole 0-255 range possible
-with ASCII.  Unfortunately, it's difficult for humans to remember 16
-or 32 hex digits.
-
-One solution is to request a lengthy passphrase from the user, and
-then run it through a hash function such as SHA or MD5.  Another
-solution is discussed in RFC 1751, "A Convention for Human-Readable
-128-bit Keys", by Daniel L. McDonald.  Binary keys are transformed
-into a list of short English words that should be easier to remember.
-For example, the hex key EB33F77EE73D4053 is transformed to "TIDE ITCH
-SLOW REIN RULE MOT".
-
-\begin{funcdesc}{key_to_english}{key}
-Accepts a string of arbitrary data \var{key}, and returns a string
-containing uppercase English words separated by spaces.  \var{key}'s
-length must be a multiple of 8.
-\end{funcdesc}
-
-\begin{funcdesc}{english_to_key}{string}
-Accepts \var{string} containing English words, and returns a string of
-binary data representing the key.  Words must be separated by
-whitespace, and can be any mixture of uppercase and lowercase
-characters.  6 words are required for 8 bytes of key data, so
-the number of words in \var{string} must be a multiple of 6.
-\end{funcdesc}
-
-
-%======================================================================
-\section{Extending the Toolkit}
-
-Preserving the a common interface for cryptographic routines is a good
-idea.  This chapter explains how to write new modules for the Toolkit.
-
-The basic process is as follows:
-\begin{enumerate}
-
-\item Add a new \file{.c} file containing an implementation of the new
-algorithm.  
-This file must define 3 or 4 standard functions,
-a few constants, and a C \code{struct} encapsulating the state variables required by the algorithm.
-
-\item  Add the new algorithm to \file{setup.py}.
-
-\item  Send a copy of the code to me, if you like; code for new
-algorithms will be gratefully accepted.
-\end{enumerate}
-
-
-\subsection{Adding Hash Algorithms}
-
-The required constant definitions are as follows:
-
-\begin{verbatim}
-#define MODULE_NAME MD2		/* Name of algorithm */
-#define DIGEST_SIZE 16          /* Size of resulting digest in bytes */
-\end{verbatim}
-
-The C structure must be named \ctype{hash_state}:
-
-\begin{verbatim}
-typedef struct {
-     ... whatever state variables you need ...
-} hash_state;
-\end{verbatim}
-
-There are four functions that need to be written: to initialize the
-algorithm's state, to hash a string into the algorithm's state, to get
-a digest from the current state, and to copy a state.
-
-\begin{itemize}
-  \item \code{void hash_init(hash_state *self);}
-  \item \code{void hash_update(hash_state *self, unsigned char *buffer, int length);}
-  \item \code{PyObject *hash_digest(hash_state *self);}
-  \item \code{void hash_copy(hash_state *source, hash_state *dest);}
-\end{itemize}
-
-Put \code{\#include "hash_template.c"} at the end of the file to
-include the actual implementation of the module.
-
-
-\subsection{Adding Block Encryption Algorithms}
-
-The required constant definitions are as follows:
-
-\begin{verbatim}
-#define MODULE_NAME AES	       /* Name of algorithm */
-#define BLOCK_SIZE 16          /* Size of encryption block */
-#define KEY_SIZE 0             /* Size of key in bytes (0 if not fixed size) */
-\end{verbatim}
-
-The C structure must be named \ctype{block_state}:
-
-\begin{verbatim}
-typedef struct {
-     ... whatever state variables you need ...
-} block_state;
-\end{verbatim}
-
-There are three functions that need to be written: to initialize the
-algorithm's state, and to encrypt and decrypt a single block.
-
-\begin{itemize}
-  \item \code{void block_init(block_state *self, unsigned char *key,
-                int keylen);}
-  \item \code{void block_encrypt(block_state *self, unsigned char *in, 
-               unsigned char *out);}
-  \item \code{void block_decrypt(block_state *self, unsigned char *in, 
-               unsigned char *out);}
-\end{itemize}
-
-Put \code{\#include "block_template.c"} at the end of the file to
-include the actual implementation of the module.
-
-
-\subsection{Adding Stream Encryption Algorithms}
-
-The required constant definitions are as follows:
-
-\begin{verbatim}
-#define MODULE_NAME ARC4       /* Name of algorithm */
-#define BLOCK_SIZE 1           /* Will always be 1 for a stream cipher */
-#define KEY_SIZE 0             /* Size of key in bytes (0 if not fixed size) */
-\end{verbatim}
-
-The C structure must be named \ctype{stream_state}:
-
-\begin{verbatim}
-typedef struct {
-     ... whatever state variables you need ...
-} stream_state;
-\end{verbatim}
-
-There are three functions that need to be written: to initialize the
-algorithm's state, and to encrypt and decrypt a single block.
-
-\begin{itemize}
-  \item \code{void stream_init(stream_state *self, unsigned char *key,
-                int keylen);}
-  \item \code{void stream_encrypt(stream_state *self, unsigned char *block, 
-               int length);}
-  \item \code{void stream_decrypt(stream_state *self, unsigned char *block, 
-               int length);}
-\end{itemize}
-
-Put \code{\#include "stream_template.c"} at the end of the file to
-include the actual implementation of the module.
-
-
-\end{document}

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py
deleted file mode 100644
index eeb5782..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py
+++ /dev/null
@@ -1,108 +0,0 @@
-"""HMAC (Keyed-Hashing for Message Authentication) Python module.
-
-Implements the HMAC algorithm as described by RFC 2104.
-
-This is just a copy of the Python 2.2 HMAC module, modified to work when
-used on versions of Python before 2.2.
-"""
-
-__revision__ = "$Id: HMAC.py,v 1.5 2002/07/25 17:19:02 z3p Exp $"
-
-import string
-
-def _strxor(s1, s2):
-    """Utility method. XOR the two strings s1 and s2 (must have same length).
-    """
-    return "".join(map(lambda x, y: chr(ord(x) ^ ord(y)), s1, s2))
-
-# The size of the digests returned by HMAC depends on the underlying
-# hashing module used.
-digest_size = None
-
-class HMAC:
-    """RFC2104 HMAC class.
-
-    This supports the API for Cryptographic Hash Functions (PEP 247).
-    """
-
-    def __init__(self, key, msg = None, digestmod = None):
-        """Create a new HMAC object.
-
-        key:       key for the keyed hash object.
-        msg:       Initial input for the hash, if provided.
-        digestmod: A module supporting PEP 247. Defaults to the md5 module.
-        """
-        if digestmod == None:
-            import md5
-            digestmod = md5
-
-        self.digestmod = digestmod
-        self.outer = digestmod.new()
-        self.inner = digestmod.new()
-        try:
-            self.digest_size = digestmod.digest_size
-        except AttributeError:
-            self.digest_size = len(self.outer.digest())
-
-        blocksize = 64
-        ipad = "\x36" * blocksize
-        opad = "\x5C" * blocksize
-
-        if len(key) > blocksize:
-            key = digestmod.new(key).digest()
-
-        key = key + chr(0) * (blocksize - len(key))
-        self.outer.update(_strxor(key, opad))
-        self.inner.update(_strxor(key, ipad))
-        if (msg):
-            self.update(msg)
-
-##    def clear(self):
-##        raise NotImplementedError, "clear() method not available in HMAC."
-
-    def update(self, msg):
-        """Update this hashing object with the string msg.
-        """
-        self.inner.update(msg)
-
-    def copy(self):
-        """Return a separate copy of this hashing object.
-
-        An update to this copy won't affect the original object.
-        """
-        other = HMAC("")
-        other.digestmod = self.digestmod
-        other.inner = self.inner.copy()
-        other.outer = self.outer.copy()
-        return other
-
-    def digest(self):
-        """Return the hash value of this hashing object.
-
-        This returns 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.
-        """
-        h = self.outer.copy()
-        h.update(self.inner.digest())
-        return h.digest()
-
-    def hexdigest(self):
-        """Like digest(), but returns a string of hexadecimal digits instead.
-        """
-        return "".join([string.zfill(hex(ord(x))[2:], 2)
-                        for x in tuple(self.digest())])
-
-def new(key, msg = None, digestmod = None):
-    """Create a new hashing object and return it.
-
-    key: The starting key for the hash.
-    msg: if available, will immediately be hashed into the object's starting
-    state.
-
-    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.
-    """
-    return HMAC(key, msg, digestmod)
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py
deleted file mode 100644
index b0eba39..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py
+++ /dev/null
@@ -1,13 +0,0 @@
-
-# Just use the MD5 module from the Python standard library
-
-__revision__ = "$Id: MD5.py,v 1.4 2002/07/11 14:31:19 akuchling Exp $"
-
-from md5 import *
-
-import md5
-if hasattr(md5, 'digestsize'):
-    digest_size = digestsize
-    del digestsize
-del md5
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py
deleted file mode 100644
index ea3c6a3..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py
+++ /dev/null
@@ -1,11 +0,0 @@
-
-# Just use the SHA module from the Python standard library
-
-__revision__ = "$Id: SHA.py,v 1.4 2002/07/11 14:31:19 akuchling Exp $"
-
-from sha import *
-import sha
-if hasattr(sha, 'digestsize'):
-    digest_size = digestsize
-    del digestsize
-del sha

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/__init__.py
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/__init__.py b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/__init__.py
deleted file mode 100644
index 920fe74..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/__init__.py
+++ /dev/null
@@ -1,24 +0,0 @@
-"""Hashing algorithms
-
-Hash functions take arbitrary strings as input, and produce an output
-of fixed size that is dependent on the input; it should never be
-possible to derive the input data given only the hash function's
-output.  Hash functions can be used simply as a checksum, or, in
-association with a public-key algorithm, can be used to implement
-digital signatures.
-
-The hashing modules here all support the interface described in PEP
-247, "API for Cryptographic Hash Functions".
-
-Submodules:
-Crypto.Hash.HMAC          RFC 2104: Keyed-Hashing for Message Authentication
-Crypto.Hash.MD2
-Crypto.Hash.MD4
-Crypto.Hash.MD5
-Crypto.Hash.RIPEMD
-Crypto.Hash.SHA
-"""
-
-__all__ = ['HMAC', 'MD2', 'MD4', 'MD5', 'RIPEMD', 'SHA', 'SHA256']
-__revision__ = "$Id: __init__.py,v 1.6 2003/12/19 14:24:25 akuchling Exp $"
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE b/tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE
deleted file mode 100644
index ad3ae41..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE
+++ /dev/null
@@ -1,15 +0,0 @@
-===================================================================
-Distribute and use freely; there are no restrictions on further
-dissemination and usage except those imposed by the laws of your
-country of residence.  This software is provided "as is" without
-warranty of fitness for use or suitability for any purpose, express
-or implied. Use at your own risk or not at all.
-===================================================================
-
-Incorporating the code into commercial products is permitted; you do
-not have to make source available or contribute your changes back
-(though that would be nice).
-
---amk                                                             (www.amk.ca)
-
-

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST b/tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST
deleted file mode 100644
index d19134e..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST
+++ /dev/null
@@ -1,63 +0,0 @@
-ACKS
-ChangeLog
-Cipher/__init__.py
-Doc/pycrypt.tex
-Hash/HMAC.py
-Hash/MD5.py
-Hash/SHA.py
-Hash/__init__.py
-LICENSE
-MANIFEST
-Protocol/AllOrNothing.py
-Protocol/Chaffing.py
-Protocol/__init__.py
-PublicKey/DSA.py
-PublicKey/ElGamal.py
-PublicKey/RSA.py
-PublicKey/__init__.py
-PublicKey/pubkey.py
-PublicKey/qNEW.py
-PublicKey/test/rsa_speed.py
-README
-TODO
-Util/RFC1751.py
-Util/__init__.py
-Util/number.py
-Util/randpool.py
-Util/test.py
-Util/test/prime_speed.py
-__init__.py
-setup.py
-src/AES.c
-src/ARC2.c
-src/ARC4.c
-src/Blowfish.c
-src/CAST.c
-src/DES.c
-src/DES3.c
-src/IDEA.c
-src/MD2.c
-src/MD4.c
-src/RC5.c
-src/RIPEMD.c
-src/SHA256.c
-src/XOR.c
-src/block_template.c
-src/cast5.c
-src/hash_template.c
-src/stream_template.c
-src/winrand.c
-src/_dsa.c
-src/_fastmath.c
-src/_rsa.c
-test.py
-test/template
-test/test_allornothing.py
-test/test_chaffing.py
-test/test_hashes.py
-test/test_hmac.py
-test/test_number.py
-test/test_publickey.py
-test/test_randpool.py
-test/test_rfc1751.py
-test/testdata.py

http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/ac031357/tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO
----------------------------------------------------------------------
diff --git a/tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO b/tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO
deleted file mode 100644
index 764da08..0000000
--- a/tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO
+++ /dev/null
@@ -1,18 +0,0 @@
-Metadata-Version: 1.0
-Name: pycrypto
-Version: 2.0.1
-Summary: Cryptographic modules for Python.
-Home-page: http://www.amk.ca/python/code/crypto
-Author: A.M. Kuchling
-Author-email: amk@amk.ca
-License: UNKNOWN
-Download-URL: http://www.amk.ca/files/python/crypto/pycrypto-2.0.1.tar.gz
-Description: UNKNOWN
-Platform: UNKNOWN
-Classifier: Development Status :: 4 - Beta
-Classifier: License :: Public Domain
-Classifier: Intended Audience :: Developers
-Classifier: Operating System :: Unix
-Classifier: Operating System :: Microsoft :: Windows
-Classifier: Operating System :: MacOS :: MacOS X
-Classifier: Topic :: Security :: Cryptography


Mime
View raw message