~ubuntu-branches/ubuntu/saucy/python-crypto/saucy-proposed

« back to all changes in this revision

Viewing changes to lib/Crypto/Hash/__init__.py

  • Committer: Package Import Robot
  • Author(s): Sebastian Ramacher
  • Date: 2012-05-24 20:16:34 UTC
  • mfrom: (1.1.7)
  • Revision ID: package-import@ubuntu.com-20120524201634-de6vxznjsdgekuwp
Tags: 2.6-1
* New upstream release.
  - Fixes CVE-2012-2417: insecure ElGamal key generation.
* Set urgency to high since this fixes a security issue.
* debian/copyright:
  - Fix formatting.
  - Update Format URL.
* debian/control:
  - Bump Standards-Version to 3.9.3 (no changes required).
  - Drop qNEW from Description since qNEW has been removed.
* debian/patches: Remove posixread.patch (not needed anymore).

Show diffs side-by-side

added added

removed removed

Lines of Context:
20
20
 
21
21
"""Hashing algorithms
22
22
 
23
 
Hash functions take arbitrary strings as input, and produce an output
24
 
of fixed size that is dependent on the input; it should never be
25
 
possible to derive the input data given only the hash function's
26
 
output.  Hash functions can be used simply as a checksum, or, in
 
23
Hash functions take arbitrary binary strings as input, and produce a random-like output
 
24
of fixed size that is dependent on the input; it should be practically infeasible 
 
25
to derive the original input data given only the hash function's
 
26
output. In other words, the hash function is *one-way*.
 
27
 
 
28
It should also not be practically feasible to find a second piece of data
 
29
(a *second pre-image*) whose hash is the same as the original message
 
30
(*weak collision resistance*).
 
31
 
 
32
Finally, it should not be feasible to find two arbitrary messages with the
 
33
same hash (*strong collision resistance*).
 
34
 
 
35
The output of the hash function is called the *digest* of the input message.
 
36
In general, the security of a hash function is related to the length of the
 
37
digest. If the digest is *n* bits long, its security level is roughly comparable
 
38
to the the one offered by an *n/2* bit encryption algorithm.
 
39
 
 
40
Hash functions can be used simply as a integrity check, or, in
27
41
association with a public-key algorithm, can be used to implement
28
42
digital signatures.
29
43
 
30
 
The hashing modules here all support the interface described in PEP
31
 
247, "API for Cryptographic Hash Functions".
32
 
 
33
 
Submodules:
34
 
 
35
 
Crypto.Hash.HMAC
36
 
 RFC 2104. Keyed-Hashing for Message Authentication.
37
 
Crypto.Hash.MD2
38
 
 RFC1319. Rivest's Message Digest algorithm, with a 128 bit digest. This algorithm is both slow and insecure.
39
 
Crypto.Hash.MD4
40
 
 RFC1320. Rivest's Message Digest algorithm, with a 128 bit digest. This algorithm is insecure.
41
 
Crypto.Hash.MD5
42
 
 RFC1321. Rivest's Message Digest algorithm, with a 128 bit digest. This algorithm is insecure.
43
 
Crypto.Hash.RIPEMD
44
 
 RACE Integrity Primitives Evaluation Message Digest algorithm, with a 160 bit digest.
45
 
Crypto.Hash.SHA
46
 
 Secure Hash Algorithm 1 (SHA-1), with a 160 bit digest. Published in FIPS PUB 180-1/2/3.
47
 
Crypto.Hash.SHA224
48
 
 Secure Hash Algorithm 2 (SHA-2 family), with a 224 bit digest. Published in FIPS PUB 180-2/3.
49
 
Crypto.Hash.SHA256
50
 
 Secure Hash Algorithm 2 (SHA-2 family), with a 256 bit digest. Published in FIPS PUB 180-2/3.
51
 
Crypto.Hash.SHA384
52
 
 Secure Hash Algorithm 2 (SHA-2 family), with a 384 bit digest. Published in FIPS PUB 180-2/3.
53
 
Crypto.Hash.SHA512
54
 
 Secure Hash Algorithm 2 (SHA-2 family), with a 512 bit digest. Published in FIPS PUB 180-2/3.
55
 
 
 
44
The hashing modules here all support the interface described in `PEP
 
45
247`_ , "API for Cryptographic Hash Functions". 
 
46
 
 
47
.. _`PEP 247` : http://www.python.org/dev/peps/pep-0247/
 
48
 
 
49
:undocumented: _MD2, _MD4, _RIPEMD160, _SHA224, _SHA256, _SHA384, _SHA512
56
50
"""
57
51
 
58
52
__all__ = ['HMAC', 'MD2', 'MD4', 'MD5', 'RIPEMD', 'SHA',