You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hawq.apache.org by cj...@apache.org on 2016/06/29 01:21:22 UTC
[64/80] [abbrv] incubator-hawq git commit: HAWQ-863. Add python
module pycrypto
HAWQ-863. Add python module pycrypto
Project: http://git-wip-us.apache.org/repos/asf/incubator-hawq/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-hawq/commit/2c87cdcb
Tree: http://git-wip-us.apache.org/repos/asf/incubator-hawq/tree/2c87cdcb
Diff: http://git-wip-us.apache.org/repos/asf/incubator-hawq/diff/2c87cdcb
Branch: refs/heads/HAWQ-537
Commit: 2c87cdcbdde5cf349083e3254a65b6c619388491
Parents: 74401eb
Author: rlei <rl...@pivotal.io>
Authored: Thu Jun 23 10:06:34 2016 +0800
Committer: rlei <rl...@pivotal.io>
Committed: Thu Jun 23 10:12:59 2016 +0800
----------------------------------------------------------------------
tools/bin/Makefile | 2 +-
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 ++++++++
63 files changed, 15377 insertions(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/2c87cdcb/tools/bin/Makefile
----------------------------------------------------------------------
diff --git a/tools/bin/Makefile b/tools/bin/Makefile
index 46a2df6..3102537 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
+all: lockfile pygresql stream pychecker psi unittest2 pycrypto
#
# Python Libraries
http://git-wip-us.apache.org/repos/asf/incubator-hawq/blob/2c87cdcb/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
new file mode 100644
index 0000000..2acfc30
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/ACKS
@@ -0,0 +1,34 @@
+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/2c87cdcb/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
new file mode 100644
index 0000000..30e325c
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/ChangeLog
@@ -0,0 +1,316 @@
+
+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 <wi...@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/2c87cdcb/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
new file mode 100644
index 0000000..3b2f855
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Cipher/__init__.py
@@ -0,0 +1,33 @@
+"""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/2c87cdcb/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
new file mode 100644
index 0000000..d9c9bf6
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Doc/pycrypt.tex
@@ -0,0 +1,1188 @@
+\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/2c87cdcb/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
new file mode 100644
index 0000000..eeb5782
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/HMAC.py
@@ -0,0 +1,108 @@
+"""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/2c87cdcb/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
new file mode 100644
index 0000000..b0eba39
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/MD5.py
@@ -0,0 +1,13 @@
+
+# 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/2c87cdcb/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
new file mode 100644
index 0000000..ea3c6a3
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/SHA.py
@@ -0,0 +1,11 @@
+
+# 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/2c87cdcb/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
new file mode 100644
index 0000000..920fe74
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/Hash/__init__.py
@@ -0,0 +1,24 @@
+"""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/2c87cdcb/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
new file mode 100644
index 0000000..ad3ae41
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/LICENSE
@@ -0,0 +1,15 @@
+===================================================================
+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/2c87cdcb/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
new file mode 100644
index 0000000..d19134e
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/MANIFEST
@@ -0,0 +1,63 @@
+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/2c87cdcb/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
new file mode 100644
index 0000000..764da08
--- /dev/null
+++ b/tools/bin/pythonSrc/pycrypto-2.0.1/PKG-INFO
@@ -0,0 +1,18 @@
+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