Menu
▾
▴
pycrypto-checkins — CVS checkins, and bug/patch notifications
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(106) |
May
(84) |
Jun
(29) |
Jul
(31) |
Aug
(1) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(6) |
| 2003 |
Jan
(1) |
Feb
(25) |
Mar
(17) |
Apr
(48) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2004 |
Jan
(5) |
Feb
|
Mar
(13) |
Apr
(1) |
May
(9) |
Jun
|
Jul
(1) |
Aug
(10) |
Sep
(4) |
Oct
(23) |
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(6) |
May
(10) |
Jun
(18) |
Jul
(5) |
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(13) |
Dec
(4) |
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(5) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2008-08-24 01:03:37
|
Bugs item #2070522, was opened at 2008-08-24 00:56 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2070522&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Encryption modes not functioning properly Initial Comment: Modes of encryption/decryption other than 1 and 4 do not seem to function properly for any of the various ciphers in the toolkit. It seems to be the first block which comes out incorrect but mode 5 does not function at all. Example: plain = 'Block001Block002Block003Block004Block005 Block006Block007Block008Block009Block010' for x in range(1,6): ... AESobj = AES.new('1234567812345678',x) ... ciph = AESobj.encrypt(plain) ... AESobj.decrypt(ciph) print "" ... 'Block001Block002Block003Block004Block005 Block006Block007Block008Block009Block010' '\xf6\x8c5n\xcc\xc2\x12\x840p\xd3,\xe2\xac{\xe5Block003Block004Block005 Block006Block007Block008Block009Block010' '( -\xd7\xa6\n\x0f\xaa\x14]\xa203b\x9eBlock003 Block004Block005Block006Block007Block008 Block009Block010' 'L\x17\xd0\x93\x9b\x8ad\xe7Block002Block003Block004 Block005Block006Block007Block008Block009Block010' '\x06\x83\xd1KwZ\xd0\x0bn\x88\x1cc\xcd\x99yV\xc4\x15\xdc\x8b\xf8\xd3\x7f8\xd8 \xdaj\xa8\x05\xb2\x86_UG\xe0#\xad\xc8d\xe5E\xb3\xa2io\x00B&\xab\x85\xac\xbdT\xb5m\xa2S#\xbb7\x8c\xad\xe4\xe6D\xbd<\x83C|V\xd4D[\xdd\xf3\x82' Also, I get memory errors when setting RC5 rounds to higher than 49. Example 1: >>> RC5obj = RC5.new('123456781234567812345678',1,rounds=100) Segmentation fault Example 2: >>> RC5obj = RC5.new('123456781234567812345678',3,rounds=255) *** glibc detected *** python: malloc(): memory corruption: 0x000000000080c050 *** Also, AllOrNothing protocol produces some list entries that are only 7 bytes instead of 8 and so the undigest operation always fails. Sorry if this is some error in implementation on my part I'm new to programming/cryptography/Linux. Also just to note the example usages at www.amk.ca use a different format to specify the mode than the toolkit demanded of me in practice (accepting only an integer). I have tried installations both through the Adept Package manager and as installed by the scripts available at amk.ca with the same results. Thanks, Edward John Carscallen ej_...@ho... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-24 01:03 Message: Logged In: NO Perhaps I should have mentioned I am using Kubuntu and python 2.5.2 with an AMD64 system if this could be the cause of my errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2070522&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-08-24 00:55:56
|
Bugs item #2070522, was opened at 2008-08-24 00:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2070522&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Encryption modes not functioning properly Initial Comment: Modes of encryption/decryption other than 1 and 4 do not seem to function properly for any of the various ciphers in the toolkit. It seems to be the first block which comes out incorrect but mode 5 does not function at all. Example: plain = 'Block001Block002Block003Block004Block005 Block006Block007Block008Block009Block010' for x in range(1,6): ... AESobj = AES.new('1234567812345678',x) ... ciph = AESobj.encrypt(plain) ... AESobj.decrypt(ciph) print "" ... 'Block001Block002Block003Block004Block005 Block006Block007Block008Block009Block010' '\xf6\x8c5n\xcc\xc2\x12\x840p\xd3,\xe2\xac{\xe5Block003Block004Block005 Block006Block007Block008Block009Block010' '( -\xd7\xa6\n\x0f\xaa\x14]\xa203b\x9eBlock003 Block004Block005Block006Block007Block008 Block009Block010' 'L\x17\xd0\x93\x9b\x8ad\xe7Block002Block003Block004 Block005Block006Block007Block008Block009Block010' '\x06\x83\xd1KwZ\xd0\x0bn\x88\x1cc\xcd\x99yV\xc4\x15\xdc\x8b\xf8\xd3\x7f8\xd8 \xdaj\xa8\x05\xb2\x86_UG\xe0#\xad\xc8d\xe5E\xb3\xa2io\x00B&\xab\x85\xac\xbdT\xb5m\xa2S#\xbb7\x8c\xad\xe4\xe6D\xbd<\x83C|V\xd4D[\xdd\xf3\x82' Also, I get memory errors when setting RC5 rounds to higher than 49. Example 1: >>> RC5obj = RC5.new('123456781234567812345678',1,rounds=100) Segmentation fault Example 2: >>> RC5obj = RC5.new('123456781234567812345678',3,rounds=255) *** glibc detected *** python: malloc(): memory corruption: 0x000000000080c050 *** Also, AllOrNothing protocol produces some list entries that are only 7 bytes instead of 8 and so the undigest operation always fails. Sorry if this is some error in implementation on my part I'm new to programming/cryptography/Linux. Also just to note the example usages at www.amk.ca use a different format to specify the mode than the toolkit demanded of me in practice (accepting only an integer). I have tried installations both through the Adept Package manager and as installed by the scripts available at amk.ca with the same results. Thanks, Edward John Carscallen ej_...@ho... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2070522&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-08-16 12:43:33
|
Patches item #2054677, was opened at 2008-08-16 12:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=2054677&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for Camellia block cipher Initial Comment: I would like to post a patch to add support for Camellia block cipher to pycrypto. Camellia is one of the selected block cipher by New European Schemes for Signature, Integrity, and Encryption (NESSIE) and specified in several RFCs. It is also included in some open source softwares, such as FreeBSD, Linux, OpenSSL, Firefox 3, GnuPG and so on. You can get detailed information for Camellia from: http://info.isl.ntt.co.jp/crypt/eng/camellia/index.html Will you review and test it? I hope my patch will be imported into pycrypto. Thank you in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=2054677&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-07-06 20:01:26
|
Bugs item #2011961, was opened at 2008-07-06 20:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2011961&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: It doesn't compile without warnings on Ubuntu 8.04 for amd64 Initial Comment: I am running Ubuntu 8.04 Hardy Heron on amd64 (core2 duo). I have python 2.5 and development package installed. PyCrypto compliles, installs and tests runned ok, although there were many compilation warnings. I guess that it shoudn't take place and is caused by not testing compilation on 64 bit architecture. che...@gm... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=2011961&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-06-27 05:44:49
|
Bugs item #1343753, was opened at 2005-10-31 23:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: winrand.c in CryptAcquireContext raises NTE_BAD_KEYSET Initial Comment: pycrypto acquires context of container that is unique to each user, but inproperly handles error when required key set isn't aviable. Better way (recomended in MSDN): if (!CryptAcquireContext(&hProv, "Container", NULL, PROV_RSA_FULL, 0)) { if (GetLastError() == NTE_BAD_KEYSET) { if (!CryptAcquireContext(&hProv, "Container", NULL, PROV_RSA_FULL, CRYPT_NEWKEYSET)) { // Error ... } } } ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-06-27 15:44 Message: Logged In: YES user_id=14198 Originator: NO I've uploaded a patch at http://sourceforge.net/tracker/index.php?func=detail&aid=2003762&group_id=20937&atid=320937 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-11-30 06:51 Message: Logged In: YES user_id=11375 Please provide a patch; I can't figure out what fix you're actually suggesting. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-03 23:09 Message: Logged In: NO I had the exact same problem, and the exact same fix solved it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1343753&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-06-27 05:44:29
|
Patches item #2003762, was opened at 2008-06-27 15:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=2003762&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent CryptAcquireContext raising NTE_BAD_KEYSET Initial Comment: This is a patch for http://sourceforge.net/tracker/index.php?func=detail&aid=1343753&group_id=20937&atid=120937 - it includes a reference to the specific msdn article in question, and at that article's suggestion, retries the operation with a different flag in the case of NTE_BAD_KEYSET. The patch also includes a fix for setup.py - without that change, setup.py doesn't attempt to build the winrand module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=2003762&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-05-20 10:52:05
|
Bugs item #1967068, was opened at 2008-05-19 06:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Blowfish differs from others Initial Comment: Blowfish in pycrypto produces different results that many other implementations, e.g. Java's JCE, Bruce Schneier's reference implementation, crypto etc. Reproduce by doing the following encryption in different languages: binascii.hexlify(Blowfish.new("1234567890123456").encrypt("12345678")) PyCrypto outputs: 61d2570dc6e09632 Java, Schneier's C implementation, openssl output: e00723bbb58234aa In both cases it was same little-endian machine. st...@ya... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-20 03:52 Message: Logged In: NO I wish PyCrypto can pass Bruce Shneier's Blowfish test suite! Get it from his website http://www.schneier.com/code/vectors.txt E.g. the following print binascii.hexlify(Blowfish.new(binascii.unhexlify( 'FFFFFFFFFFFFFFFF' ), Blowfish.MODE_ECB).encrypt(binascii.unhexlify( 'FFFFFFFFFFFFFFFF' ))) must output 51866FD5B85ECB8A, not 63c6e3f875f553b3 like 2.0.1 does. That will make the library interoperable with other standard implementations. In current state (2.0.1) blowfish is mostly useless, you can't write a Python client to network server which uses Blowfish for traffic encryption etc. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-20 00:27 Message: Logged In: NO Looks like problem is in private function used PyCrypto's: #define bf_round(l,r,n) \ l ^= P[n]; \ r ^= ( (sub(S[0],l>>22 & 0x3fc) + sub(S[1],l>>14 & 0x3fc)) \ ^ sub(S[2],l>>6 & 0x3fc) ) +S[3][l & 0xff] Schneier's is different: #define S(x,i) (SBoxes[i][x.w.byte##i]) #define bf_F(x) (((S(x,0) + S(x,1)) ^ S(x,2)) + S(x,3)) #define ROUND(a,b,n) (a.dword ^= bf_F(b) ^ PArray[n]) Java's is the same different: private int func(int x) { return (((S0[(x >>> 24)] + S1[(x >>> 16) & 0xff]) ^ S2[(x >>> 8) & 0xff]) + S3[x & 0xff]); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-05-20 07:27:12
|
Bugs item #1967068, was opened at 2008-05-19 06:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Blowfish differs from others Initial Comment: Blowfish in pycrypto produces different results that many other implementations, e.g. Java's JCE, Bruce Schneier's reference implementation, crypto etc. Reproduce by doing the following encryption in different languages: binascii.hexlify(Blowfish.new("1234567890123456").encrypt("12345678")) PyCrypto outputs: 61d2570dc6e09632 Java, Schneier's C implementation, openssl output: e00723bbb58234aa In both cases it was same little-endian machine. st...@ya... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-20 00:27 Message: Logged In: NO Looks like problem is in private function used PyCrypto's: #define bf_round(l,r,n) \ l ^= P[n]; \ r ^= ( (sub(S[0],l>>22 & 0x3fc) + sub(S[1],l>>14 & 0x3fc)) \ ^ sub(S[2],l>>6 & 0x3fc) ) +S[3][l & 0xff] Schneier's is different: #define S(x,i) (SBoxes[i][x.w.byte##i]) #define bf_F(x) (((S(x,0) + S(x,1)) ^ S(x,2)) + S(x,3)) #define ROUND(a,b,n) (a.dword ^= bf_F(b) ^ PArray[n]) Java's is the same different: private int func(int x) { return (((S0[(x >>> 24)] + S1[(x >>> 16) & 0xff]) ^ S2[(x >>> 8) & 0xff]) + S3[x & 0xff]); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-05-19 13:03:00
|
Bugs item #1967068, was opened at 2008-05-19 06:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Blowfish differs from others Initial Comment: Blowfish in pycrypto produces different results that many other implementations, e.g. Java's JCE, Bruce Schneier's reference implementation, crypto etc. Reproduce by doing the following encryption in different languages: binascii.hexlify(Blowfish.new("1234567890123456").encrypt("12345678")) PyCrypto outputs: 61d2570dc6e09632 Java, Schneier's C implementation, openssl output: e00723bbb58234aa In both cases it was same little-endian machine. st...@ya... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1967068&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2008-01-10 16:55:26
|
Bugs item #1835426, was opened at 2007-11-20 16:35 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1835426&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create new AES cipher with 32-byte IV Initial Comment: class MyCipher: def __init__(self): self.key = '01234567890123456789012345678901' self.iv = '01234567890123456789012345678901' self.cipher = AES.new(self.key, AES.MODE_CBC, self.iv) def encrypt(self,id): return cipher.encrypt(id) cipher = MyCipher() cipher.encrypt('foo'); Gives me the error: ValueError: IV must be 16 bytes long ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-01-10 11:55 Message: Logged In: YES user_id=11375 Originator: NO The block size of AES is always 16 bytes, so the IV must also always be 16 bytes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1835426&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 15:00:40
|
Patches item #1849383, was opened at 2007-12-12 16:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1849383&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Haubenwallner (mhaubi) Assigned to: Nobody/Anonymous (nobody) Summary: pycrypto and case-insensitive file systems Initial Comment: Using pycrypto-2.0.1 on case-insensitive file system (like Windows - encountered problem with python-2.4.2 on Interix) does not work, because Hash/MD5.py does 'import md5'. Now python starts the search for 'md5' in same directory as the 'import' statement resides, and because of case-insensitive filesystem, it finds MD5.py again. Same is for SHA.py, which does 'import sha', resulting in importing SHA.py again. What does help here is to do the actual 'import md5' in a different directory, not containing MD5.py. Attached patch creates subdir Hash/extmd5/__init__.py, doing the actual 'import md5', which lets python find the right 'md5' module, while Hash/MD5.py does 'import extmd5'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1849383&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-11-20 21:35:10
|
Bugs item #1835426, was opened at 2007-11-20 13:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1835426&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create new AES cipher with 32-byte IV Initial Comment: class MyCipher: def __init__(self): self.key = '01234567890123456789012345678901' self.iv = '01234567890123456789012345678901' self.cipher = AES.new(self.key, AES.MODE_CBC, self.iv) def encrypt(self,id): return cipher.encrypt(id) cipher = MyCipher() cipher.encrypt('foo'); Gives me the error: ValueError: IV must be 16 bytes long ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1835426&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-10-29 20:18:58
|
Bugs item #1740198, was opened at 2007-06-20 08:43 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurent_Bondavalli (lbondavalli) Assigned to: Nobody/Anonymous (nobody) Summary: SHA256 computation error Initial Comment: SHA256 computation is false each time the message length is equal to 55 mod 64 (in bytes) because of a boundary error on padding. Patch has been written and tested on NIST vectors. For example, here is a NIST test vector for Sha256 (length is given in bits) Len = 440 Msg = 9eabfcd3603337df3dcd119d6287a9bc8bb94d650ef29bcf1b32e60d425adc2a35e06577d0c7ce2456cf260efee9e8d8aeeddb3d068f37 MD = 83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687 pycrytpo 2.0.1 >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '9a433bd916f41c09d90a4922ef648bbd34aa7d80258b7520ca663779beeb4b3a' HERE IS THE PATCH --- SHA256.c 2005-06-14 00:14:57.000000000 +0000 +++ SHA256.c 2007-06-20 08:00:53.000000000 +0000 @@ -140,7 +140,7 @@ * then compress. Then we can fall back to padding zeros and length * encoding like normal. */ - if (md->curlen >= 56) { + if (md->curlen > 56) { for (; md->curlen < 64;) md->buf[md->curlen++] = 0; sha_compress(md); pycrypto 2.0.1 + patch >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687' ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2007-10-29 20:19 Message: Logged In: YES user_id=52562 Originator: NO I see that AMK applied the fix in: http://pycrypto.cvs.sourceforge.net/pycrypto/crypto/src/SHA256.c?r1=1.3&r2=1.4 Now we just need to release it. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2007-10-29 19:35 Message: Logged In: YES user_id=52562 Originator: NO I think that this is an important bug and that the patch should be accepted and a new version of pycrypto released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-10-29 19:35:32
|
Bugs item #1740198, was opened at 2007-06-20 08:43 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurent_Bondavalli (lbondavalli) Assigned to: Nobody/Anonymous (nobody) Summary: SHA256 computation error Initial Comment: SHA256 computation is false each time the message length is equal to 55 mod 64 (in bytes) because of a boundary error on padding. Patch has been written and tested on NIST vectors. For example, here is a NIST test vector for Sha256 (length is given in bits) Len = 440 Msg = 9eabfcd3603337df3dcd119d6287a9bc8bb94d650ef29bcf1b32e60d425adc2a35e06577d0c7ce2456cf260efee9e8d8aeeddb3d068f37 MD = 83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687 pycrytpo 2.0.1 >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '9a433bd916f41c09d90a4922ef648bbd34aa7d80258b7520ca663779beeb4b3a' HERE IS THE PATCH --- SHA256.c 2005-06-14 00:14:57.000000000 +0000 +++ SHA256.c 2007-06-20 08:00:53.000000000 +0000 @@ -140,7 +140,7 @@ * then compress. Then we can fall back to padding zeros and length * encoding like normal. */ - if (md->curlen >= 56) { + if (md->curlen > 56) { for (; md->curlen < 64;) md->buf[md->curlen++] = 0; sha_compress(md); pycrypto 2.0.1 + patch >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687' ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2007-10-29 19:35 Message: Logged In: YES user_id=52562 Originator: NO I think that this is an important bug and that the patch should be accepted and a new version of pycrypto released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-07-13 20:23:03
|
Bugs item #1753779, was opened at 2007-07-13 16:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1753779&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rick Hull (nwallins) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect pad calculation in AllOrNothing.py Initial Comment: # Pad the text so that its length is a multiple of the cipher's # block_size. Pad with trailing spaces, which will be eliminated in # the undigest() step. block_size = self.__ciphermodule.block_size padbytes = block_size - (len(text) % block_size) text = text + ' ' * padbytes the line: padbytes = block_size - (len(text) % block_size) will add a full block_size worth of padding when it is not needed: block_size = 8 text = '12345678' padbytes would therefore be calculated as 8 instead of 0 the line should read: padbytes = block_size - (((len(text) - 1) % block_size) + 1)) using values from above: padbytes = 8 - (((8 - 1) % 8) + 1) = 8 - (7%8 + 1) = 0 enjoy! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1753779&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-06-20 08:43:31
|
Bugs item #1740198, was opened at 2007-06-20 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurent_Bondavalli (lbondavalli) Assigned to: Nobody/Anonymous (nobody) Summary: SHA256 computation error Initial Comment: SHA256 computation is false each time the message length is equal to 55 mod 64 (in bytes) because of a boundary error on padding. Patch has been written and tested on NIST vectors. For example, here is a NIST test vector for Sha256 (length is given in bits) Len = 440 Msg = 9eabfcd3603337df3dcd119d6287a9bc8bb94d650ef29bcf1b32e60d425adc2a35e06577d0c7ce2456cf260efee9e8d8aeeddb3d068f37 MD = 83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687 pycrytpo 2.0.1 >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '9a433bd916f41c09d90a4922ef648bbd34aa7d80258b7520ca663779beeb4b3a' HERE IS THE PATCH --- SHA256.c 2005-06-14 00:14:57.000000000 +0000 +++ SHA256.c 2007-06-20 08:00:53.000000000 +0000 @@ -140,7 +140,7 @@ * then compress. Then we can fall back to padding zeros and length * encoding like normal. */ - if (md->curlen >= 56) { + if (md->curlen > 56) { for (; md->curlen < 64;) md->buf[md->curlen++] = 0; sha_compress(md); pycrypto 2.0.1 + patch >>> from Crypto.Hash import SHA256 >>> a = SHA256.new('\x9e\xab\xfc\xd3`37\xdf=\xcd\x11\x9db\x87\xa9\xbc\x8b\xb9Me\x0e\xf2\x9b\xcf\x1b2\xe6\rBZ\xdc*5\xe0ew\xd0\xc7\xce$V\xcf&\x0e\xfe\xe9\xe8\xd8\xae\ xed\xdb=\x06\x8f7') >>> a.hexdigest() '83eeed2dfeb8d2604ab5ec1ac9b5dcab8cc2222518468bc5c24c16ce72e70687' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1740198&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-06-08 09:12:43
|
Bugs item #1559789, was opened at 2006-09-16 08:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AES MODE_CBC require multiple of 16 bytes to work? Initial Comment: It seems to me that the CBC algorithm is implemented a little odd... When using the CBC mode it should be possible to pass data with lengths not a multiple of 16? The following code produces the error: from Crypto.Cipher import AES a = AES.new('abcdefghabcdefgh', AES.MODE_CBC) a.encrypt('This is a test ') ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-06-08 02:12 Message: Logged In: NO You're right, this is not a bug. I was not thinking about CFB, I was thinking about CTS. I was still wrong though. ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2007-05-01 14:56 Message: Logged In: YES user_id=400635 Originator: NO For CBC, there's no standard padding scheme and the algorithm requires that you encrypt an even block in length. ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2007-01-12 13:06 Message: Logged In: YES user_id=400635 Originator: NO Actually, no. With CBC each block is XOR'ed with the next, one complete block at a time. You're probably thinking of CFB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-06-08 09:06:49
|
Bugs item #1212602, was opened at 2005-06-01 02:59 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1212602&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong RSA encryption Initial Comment: A big file is split up in chunks smaller than ((size()+1)/8 - 11). The modules contains 64 bytes so a chunk is 53 bytes. In front I add 0x00 0x02 PS 0x00 (the PKCS1 standard?). PS is pseudo non zero random padding of at least 8 bytes. Sometimes (seems irregular) encrypt() returns 63 bytes. 64 bytes are expected. Then I call encrypt() again for the same data. This second time the correct 64 bytes are returned. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-06-08 02:06 Message: Logged In: NO Test script to prove problem above: from Crypto.PublicKey import RSA from Crypt.Util import randpool import binascii r = randpool.RandomPool() k = RSA.generate(1024, r.get_bytes) pt = "0002010101010101010100" + ''.join(["FF"] * 117) print len(pt) ct = k.encrypt(binascii.unheclify(pt), r.get_bytes(100)) ptnew = k.decrypt(ct[0]) print len(ptnew) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-10 12:38 Message: Logged In: YES user_id=11375 Please provide a small test script that demonstrates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1212602&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-05-30 21:39:09
|
Bugs item #1728610, was opened at 2007-05-30 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1728610&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Check result of can_sign() for public keys Initial Comment: In the case of calling can_sign() applied to a PUBLIC key: publicKey.can_sign() its result is True, even though signatures can be performed by private key only. I've noticed this behaviour for DSA and qNEW algorithms. However, if I try to sign a message using sign() and the PUBLIC key, the expected error message is issued. So sign() function seems to be fine. Mail: mga...@ya... Thank you ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1728610&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-05-30 21:22:10
|
Bugs item #1728601, was opened at 2007-05-30 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1728601&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Check number of arguments in semantic error message Initial Comment: Test case: RSAkey.verify(hash) #only one argument PyCrypto behaviour: TypeError: verify() takes exactly 3 arguments (2 given) Comment: I believe the number of arguments is artificially incremented by one, as the test has only one argument. My mail: mga...@ya... Thank you ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1728601&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-05-28 12:33:36
|
Patches item #1726872, was opened at 2007-05-28 14:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1726872&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Francesco Sacchi (batt6) Assigned to: Nobody/Anonymous (nobody) Summary: Support for TEA Initial Comment: Hi, the patches attached add to pycrypto support for TEA (Tiny Encryption Algorithm) cipher block algorithm. To apply use: patch -p1 < tea_patch Into your pycryto 2.0.1 directory. Bye! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1726872&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-05-01 21:58:00
|
Bugs item #1710840, was opened at 2007-05-01 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1710840&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: CTR mode should not require an even block length input Initial Comment: CTR mode doesn't require an even block length input; the generated pad can be XORed with the input incrementally, to give a ciphertext whose length exactly matches the plaintext. This should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1710840&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-05-01 21:56:38
|
Bugs item #1559789, was opened at 2006-09-16 15:11 Message generated for change (Comment added) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AES MODE_CBC require multiple of 16 bytes to work? Initial Comment: It seems to me that the CBC algorithm is implemented a little odd... When using the CBC mode it should be possible to pass data with lengths not a multiple of 16? The following code produces the error: from Crypto.Cipher import AES a = AES.new('abcdefghabcdefgh', AES.MODE_CBC) a.encrypt('This is a test ') ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2007-05-01 21:56 Message: Logged In: YES user_id=400635 Originator: NO For CBC, there's no standard padding scheme and the algorithm requires that you encrypt an even block in length. ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2007-01-12 21:06 Message: Logged In: YES user_id=400635 Originator: NO Actually, no. With CBC each block is XOR'ed with the next, one complete block at a time. You're probably thinking of CFB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-04-27 19:11:15
|
Bugs item #1634358, was opened at 2007-01-12 21:05 Message generated for change (Settings changed) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1634358&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) >Summary: docs: Cipher encryption sample uses DES.ECB Initial Comment: It seems to be called DES.MODE_ECB in reality. Please update the example! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1634358&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2007-01-12 21:06:45
|
Bugs item #1559789, was opened at 2006-09-16 15:11 Message generated for change (Comment added) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AES MODE_CBC require multiple of 16 bytes to work? Initial Comment: It seems to me that the CBC algorithm is implemented a little odd... When using the CBC mode it should be possible to pass data with lengths not a multiple of 16? The following code produces the error: from Crypto.Cipher import AES a = AES.new('abcdefghabcdefgh', AES.MODE_CBC) a.encrypt('This is a test ') ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2007-01-12 21:06 Message: Logged In: YES user_id=400635 Originator: NO Actually, no. With CBC each block is XOR'ed with the next, one complete block at a time. You're probably thinking of CFB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 |
1 message has been excluded from this view by a project administrator.
