Issue 1385: hmac module violates RFC for some hash functions, e.g. sha512 (original) (raw)

Issue1385

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/45726

classification

Title: hmac module violates RFC for some hash functions, e.g. sha512
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0

process

Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: gregory.p.smith, jcea, jowagner
Priority: normal Keywords:

Created on 2007-11-04 18:52 by jowagner, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
hmac_1.patch jowagner,2007-11-04 18:51
Messages (5)
msg57106 - (view) Author: Joachim Wagner (jowagner) Date: 2007-11-04 18:51
(First time submitting a patch to this system.) The hmac module uses a fixed blocksize of 64 bytes. This is fine for many hash functions like md5, sha1 and sha256, but not for sha512 or in the general case. The RFC referenced in the python documentation specifies that the blocksize has to match the hash function. The attached patch is the first of three proposed solutions: 1. use the undocumented block_size attribute of the hashing objects provided in the hashlib modules and fallback to 64 bytes if the attribute is missing (maybe a depreciated warning would be better); in this case it would be a good idea to document to block_size attribute (not included in the patch attached); performance could be improved by making block_size a class attribute 2. document that the blocksize is 64 and that the RFC is only correctly implemented if the hash function also has a blocksize of 64 bytes; optionally include the workaround to subclass hmac.HMAC and overwrite the blocksize (this is documented in the source code, but unfortunately not in the python docu) 3. make the blocksize a keyword argument to the constructor and document that it has to match the hash function's blocksize for full RFC compliance Regards, Joachim
msg57142 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2007-11-05 22:12
option 1 sounds best. i'll take care of this. thanks for noticing this and providing suggestions and a patch.
msg57148 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2007-11-06 00:21
Fixed in trunk (2.6) svn revision 58868 with rfc 4231 unit tests and tests for the new warnings. The fix parts of that diff should be backported to 2.5. I'm leaving the Python 2.5 flag on the bug until that happens. I'm leaving Python 3.0 and py3k tags on this bug for now until someone merges it into that tree.
msg57149 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2007-11-06 00:32
Fixed in release25-maint branch in svn r58870.
msg57157 - (view) Author: Joachim Wagner (jowagner) Date: 2007-11-06 11:17
Thanks. Looks great! Also thanks for the hint to rfc 4321. This answers the questions how my application can identify whether the right python version is running. JJ
History
Date User Action Args
2022-04-11 14:56:27 admin set github: 45726
2010-09-23 21:04:33 jcea set nosy: + jcea
2008-01-06 22:29:45 admin set keywords: - py3kversions: Python 3.0
2007-11-06 11:17:10 jowagner set messages: +
2007-11-06 07:32:12 georg.brandl set status: open -> closedresolution: fixed
2007-11-06 00:32:41 gregory.p.smith set messages: + versions: - Python 2.5
2007-11-06 00:21:40 gregory.p.smith set keywords: + py3k, - patchmessages: + versions: - Python 2.6
2007-11-05 22:14:20 gregory.p.smith set components: + Library (Lib), - Noneversions: + Python 2.6, Python 2.5
2007-11-05 22:12:58 gregory.p.smith set messages: +
2007-11-05 21:37:06 gvanrossum set assignee: gregory.p.smithnosy: + gregory.p.smith
2007-11-04 19:44:10 loewis set keywords: + patch
2007-11-04 18:52:00 jowagner create