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/master Commit: 2c87cdcbdde5cf349083e3254a65b6c619388491 Parents: 74401eb Author: rlei <[email protected]> Authored: Thu Jun 23 10:06:34 2016 +0800 Committer: rlei <[email protected]> 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 <[email protected]>. + + * 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{[email protected]} + +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: [email protected] +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
