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...> - 2007-01-12 21:05:38
|
Bugs item #1634358, was opened at 2007-01-12 21:05 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=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 encrypteion 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...> - 2006-12-18 13:48:54
|
Patches item #1618042, was opened at 2006-12-18 13:48 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=1618042&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: Frederic Roudaut (fredericroudaut) Assigned to: Nobody/Anonymous (nobody) Summary: XCBC-PRF with different ciphers Initial Comment: XCBCPRF.py implements the XCBC-PRF algorithm as described by RFC 4434. It tries to respect PEP 247 (API for Cryptographic Hash Functions) also. RFC 4434 describes the algorithm named AES-XCBC-PRF-128. It involves the use of AES in CBC mode with a set of extensions (XCBC) to overcome this limitation. In fact is the same algorithm as RFC 3664 (XCBC-MAC) except that the restriction on keys length (ie exactly the cipher block size, 128 bits from AES-XCBC-MAC) is removed. Nevertheless since the key length used is adapted to the cipher block size, all ciphers may be used with XCBC-PRF ie we could have with any key length (digest length): - TripleDES-XCBC-PRF (8) - AES-XCBC-PRF (16) - DES-XCBC-PRF (8) - BLOWFISH-XCBC-PRF (8) - CAST-XCBC-PRF (8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1618042&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-12-18 13:39:19
|
Patches item #1618032, was opened at 2006-12-18 05:39 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=1618032&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: XCBC-MAC and XCBC-PRF with different ciphers Initial Comment: XCBCMAC.py implements the XCBC-MAC algorithm as described by RFC 3566. It tries to respect PEP 247 (API for Cryptographic Hash Functions) RFC 3566 describe the algorithm named AES-XCBC-MAC-96. It involves the use of AES in CBC mode with a set of extensions (XCBC) to overcome this limitation. Nevertheless since the key used is as long as the block size all ciphers may be used with XCBC ie we could have (with key length in bytes): - TripleDES-XCBC-MAC (8) - AES-XCBC-MAC (16) - DES-XCBC-MAC (8) - BLOWFISH-XCBC-MAC (8) - CAST-XCBC-MAC (8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1618032&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-10-30 09:53:38
|
Patches item #1587069, was opened at 2006-10-30 10:53 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=1587069&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: phil9r (phil9r) Assigned to: Nobody/Anonymous (nobody) Summary: Twofish support Initial Comment: This patch adds Twofish support to PyCrypto. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1587069&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-09-16 15:11:11
|
Bugs item #1559789, was opened at 2006-09-16 08:11 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=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 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 ') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1559789&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-09-13 23:54:48
|
Bugs item #1558284, was opened at 2006-09-13 16:54 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=1558284&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: _fastmath blows up during build (gcc3.3) Initial Comment: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc/ -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_fastmath.c -o build/temp.darwin-8.7.0-Power_Macintosh-2.4/src/_fastmath.o src/_fastmath.c:18:17: gmp.h: No such file or directory src/_fastmath.c:21: error: parse error before "m" src/_fastmath.c:22: warning: function declaration isn't a prototype src/_fastmath.c: In function `longObjToMPZ': src/_fastmath.c:24: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:24: error: (Each undeclared identifier is reported only once src/_fastmath.c:24: error: for each function it appears in.) src/_fastmath.c:24: error: parse error before "temp" src/_fastmath.c:25: warning: implicit declaration of function `mpz_init' src/_fastmath.c:25: error: `temp' undeclared (first use in this function) src/_fastmath.c:26: error: `temp2' undeclared (first use in this function) src/_fastmath.c:27: error: `p' undeclared (first use in this function) src/_fastmath.c:33: warning: implicit declaration of function `mpz_set_ui' src/_fastmath.c:34: warning: implicit declaration of function `mpz_mul_2exp' src/_fastmath.c:35: warning: implicit declaration of function `mpz_add' src/_fastmath.c:35: error: `m' undeclared (first use in this function) src/_fastmath.c:37: warning: implicit declaration of function `mpz_clear' src/_fastmath.c: At top level: src/_fastmath.c:42: error: parse error before "m" src/_fastmath.c:43: warning: function declaration isn't a prototype src/_fastmath.c: In function `mpzToLongObj': src/_fastmath.c:45: warning: implicit declaration of function `mpz_sizeinbase' src/_fastmath.c:45: error: `m' undeclared (first use in this function) src/_fastmath.c:47: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:47: error: parse error before "temp" src/_fastmath.c:51: warning: implicit declaration of function `mpz_init_set' src/_fastmath.c:51: error: `temp' undeclared (first use in this function) src/_fastmath.c:54: warning: implicit declaration of function `mpz_get_ui' src/_fastmath.c:55: warning: implicit declaration of function `mpz_fdiv_q_2exp' src/_fastmath.c: At top level: src/_fastmath.c:67: error: parse error before "mpz_t" src/_fastmath.c:67: warning: no semicolon at end of struct or union src/_fastmath.c:68: warning: type defaults to `int' in declaration of `g' src/_fastmath.c:68: warning: data definition has no type or storage class src/_fastmath.c:69: error: parse error before "p" src/_fastmath.c:69: warning: type defaults to `int' in declaration of `p' src/_fastmath.c:69: error: `p' used prior to declaration src/_fastmath.c:69: warning: data definition has no type or storage class src/_fastmath.c:70: error: parse error before "q" src/_fastmath.c:70: warning: type defaults to `int' in declaration of `q' src/_fastmath.c:70: warning: data definition has no type or storage class src/_fastmath.c:71: error: parse error before "x" src/_fastmath.c:71: warning: type defaults to `int' in declaration of `x' src/_fastmath.c:71: warning: data definition has no type or storage class src/_fastmath.c:73: warning: type defaults to `int' in declaration of `dsaKey' src/_fastmath.c:73: warning: data definition has no type or storage class src/_fastmath.c:77: error: parse error before "mpz_t" src/_fastmath.c:77: warning: no semicolon at end of struct or union src/_fastmath.c:78: warning: type defaults to `int' in declaration of `e' src/_fastmath.c:78: warning: data definition has no type or storage class src/_fastmath.c:79: error: parse error before "d" src/_fastmath.c:79: warning: type defaults to `int' in declaration of `d' src/_fastmath.c:79: warning: data definition has no type or storage class src/_fastmath.c:80: error: parse error before "p" src/_fastmath.c:80: warning: type defaults to `int' in declaration of `p' src/_fastmath.c:80: warning: data definition has no type or storage class src/_fastmath.c:81: error: parse error before "q" src/_fastmath.c:81: warning: type defaults to `int' in declaration of `q' src/_fastmath.c:81: warning: data definition has no type or storage class src/_fastmath.c:82: error: parse error before "u" src/_fastmath.c:82: warning: type defaults to `int' in declaration of `u' src/_fastmath.c:82: warning: data definition has no type or storage class src/_fastmath.c:84: warning: type defaults to `int' in declaration of `rsaKey' src/_fastmath.c:84: warning: data definition has no type or storage class src/_fastmath.c:89: error: parse error before '*' token src/_fastmath.c:89: warning: function declaration isn't a prototype src/_fastmath.c:90: error: parse error before '*' token src/_fastmath.c:90: warning: function declaration isn't a prototype src/_fastmath.c:91: error: parse error before '*' token src/_fastmath.c:91: warning: function declaration isn't a prototype src/_fastmath.c:92: error: parse error before '*' token src/_fastmath.c:92: warning: function declaration isn't a prototype src/_fastmath.c:93: error: parse error before '*' token src/_fastmath.c:93: warning: function declaration isn't a prototype src/_fastmath.c:94: error: parse error before '*' token src/_fastmath.c:94: warning: function declaration isn't a prototype src/_fastmath.c:96: error: parse error before '*' token src/_fastmath.c:96: warning: function declaration isn't a prototype src/_fastmath.c:97: error: parse error before '*' token src/_fastmath.c:97: warning: function declaration isn't a prototype src/_fastmath.c:98: error: parse error before '*' token src/_fastmath.c:98: warning: function declaration isn't a prototype src/_fastmath.c:99: error: parse error before '*' token src/_fastmath.c:99: warning: function declaration isn't a prototype src/_fastmath.c:100: error: parse error before '*' token src/_fastmath.c:100: warning: function declaration isn't a prototype src/_fastmath.c:101: error: parse error before '*' token src/_fastmath.c:101: warning: function declaration isn't a prototype src/_fastmath.c:102: error: parse error before '*' token src/_fastmath.c:102: warning: function declaration isn't a prototype src/_fastmath.c:103: error: parse error before '*' token src/_fastmath.c:103: warning: function declaration isn't a prototype src/_fastmath.c:104: error: parse error before '*' token src/_fastmath.c:104: warning: function declaration isn't a prototype src/_fastmath.c:107: error: parse error before '*' token src/_fastmath.c:108: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaSign': src/_fastmath.c:109: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:109: error: parse error before "temp" src/_fastmath.c:110: warning: implicit declaration of function `mpz_cmp_ui' src/_fastmath.c:110: error: `k' undeclared (first use in this function) src/_fastmath.c:110: warning: implicit declaration of function `mpz_cmp' src/_fastmath.c:110: error: `key' undeclared (first use in this function) src/_fastmath.c:114: error: `temp' undeclared (first use in this function) src/_fastmath.c:115: warning: implicit declaration of function `mpz_powm' src/_fastmath.c:115: error: `r' undeclared (first use in this function) src/_fastmath.c:116: warning: implicit declaration of function `mpz_mod' src/_fastmath.c:117: warning: implicit declaration of function `mpz_invert' src/_fastmath.c:117: error: `s' undeclared (first use in this function) src/_fastmath.c:118: warning: implicit declaration of function `mpz_mul' src/_fastmath.c:119: error: `m' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:127: error: parse error before '*' token src/_fastmath.c:128: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaVerify': src/_fastmath.c:130: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:130: error: parse error before "u1" src/_fastmath.c:131: error: `r' undeclared (first use in this function) src/_fastmath.c:131: error: `key' undeclared (first use in this function) src/_fastmath.c:132: error: `s' undeclared (first use in this function) src/_fastmath.c:134: error: `u1' undeclared (first use in this function) src/_fastmath.c:135: error: `u2' undeclared (first use in this function) src/_fastmath.c:136: error: `v1' undeclared (first use in this function) src/_fastmath.c:137: error: `v2' undeclared (first use in this function) src/_fastmath.c:138: error: `w' undeclared (first use in this function) src/_fastmath.c:140: error: `m' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:163: error: parse error before '*' token src/_fastmath.c:164: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaEncrypt': src/_fastmath.c:165: error: `v' undeclared (first use in this function) src/_fastmath.c:165: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:174: error: parse error before '*' token src/_fastmath.c:175: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaDecrypt': src/_fastmath.c:176: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:176: error: parse error before "m1" src/_fastmath.c:177: error: `v' undeclared (first use in this function) src/_fastmath.c:177: error: `key' undeclared (first use in this function) src/_fastmath.c:181: warning: implicit declaration of function `mpz_size' src/_fastmath.c:190: error: `m1' undeclared (first use in this function) src/_fastmath.c:191: error: `m2' undeclared (first use in this function) src/_fastmath.c:192: error: `h' undeclared (first use in this function) src/_fastmath.c:195: warning: implicit declaration of function `mpz_sub_ui' src/_fastmath.c:196: warning: implicit declaration of function `mpz_fdiv_r' src/_fastmath.c:203: warning: implicit declaration of function `mpz_sub' src/_fastmath.c:204: warning: implicit declaration of function `mpz_sgn' src/_fastmath.c: At top level: src/_fastmath.c:225: error: parse error before '*' token src/_fastmath.c:226: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaBlind': src/_fastmath.c:227: error: `v' undeclared (first use in this function) src/_fastmath.c:227: error: `key' undeclared (first use in this function) src/_fastmath.c:231: error: `b' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:242: error: parse error before '*' token src/_fastmath.c:243: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaUnBlind': src/_fastmath.c:244: error: `v' undeclared (first use in this function) src/_fastmath.c:244: error: `key' undeclared (first use in this function) src/_fastmath.c:248: error: `b' undeclared (first use in this function) src/_fastmath.c: In function `dsaKey_new': src/_fastmath.c:336: error: `key' undeclared (first use in this function) src/_fastmath.c:342: error: parse error before ')' token src/_fastmath.c: At top level: src/_fastmath.c:360: error: parse error before '*' token src/_fastmath.c:361: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey_dealloc': src/_fastmath.c:362: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:371: error: parse error before '*' token src/_fastmath.c:372: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey_getattr': src/_fastmath.c:373: error: `attr' undeclared (first use in this function) src/_fastmath.c:374: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:398: error: parse error before '*' token src/_fastmath.c:399: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey__sign': src/_fastmath.c:401: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:401: error: parse error before "m" src/_fastmath.c:403: error: `args' undeclared (first use in this function) src/_fastmath.c:408: error: `m' undeclared (first use in this function) src/_fastmath.c:409: error: `k' undeclared (first use in this function) src/_fastmath.c:410: error: `r' undeclared (first use in this function) src/_fastmath.c:411: error: `s' undeclared (first use in this function) src/_fastmath.c:414: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:430: error: parse error before '*' token src/_fastmath.c:431: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey__verify': src/_fastmath.c:433: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:433: error: parse error before "m" src/_fastmath.c:435: error: `args' undeclared (first use in this function) src/_fastmath.c:440: error: `m' undeclared (first use in this function) src/_fastmath.c:441: error: `r' undeclared (first use in this function) src/_fastmath.c:442: error: `s' undeclared (first use in this function) src/_fastmath.c:446: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:460: error: parse error before '*' token src/_fastmath.c:461: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey_size': src/_fastmath.c:462: error: `args' undeclared (first use in this function) src/_fastmath.c:464: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:468: error: parse error before '*' token src/_fastmath.c:469: warning: function declaration isn't a prototype src/_fastmath.c: In function `dsaKey_has_private': src/_fastmath.c:470: error: `args' undeclared (first use in this function) src/_fastmath.c:472: error: `key' undeclared (first use in this function) src/_fastmath.c: In function `rsaKey_new': src/_fastmath.c:486: error: `key' undeclared (first use in this function) src/_fastmath.c:494: error: parse error before ')' token src/_fastmath.c: At top level: src/_fastmath.c:522: error: parse error before '*' token src/_fastmath.c:523: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey_dealloc': src/_fastmath.c:524: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:534: error: parse error before '*' token src/_fastmath.c:535: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey_getattr': src/_fastmath.c:536: error: `attr' undeclared (first use in this function) src/_fastmath.c:537: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:588: error: parse error before '*' token src/_fastmath.c:589: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey__encrypt': src/_fastmath.c:591: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:591: error: parse error before "v" src/_fastmath.c:593: error: `args' undeclared (first use in this function) src/_fastmath.c:597: error: `v' undeclared (first use in this function) src/_fastmath.c:599: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:611: error: parse error before '*' token src/_fastmath.c:612: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey__decrypt': src/_fastmath.c:614: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:614: error: parse error before "v" src/_fastmath.c:616: error: `args' undeclared (first use in this function) src/_fastmath.c:620: error: `v' undeclared (first use in this function) src/_fastmath.c:622: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:641: error: parse error before '*' token src/_fastmath.c:642: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey__verify': src/_fastmath.c:644: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:644: error: parse error before "v" src/_fastmath.c:645: error: `args' undeclared (first use in this function) src/_fastmath.c:650: error: `v' undeclared (first use in this function) src/_fastmath.c:651: error: `vsig' undeclared (first use in this function) src/_fastmath.c:654: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:666: error: parse error before '*' token src/_fastmath.c:667: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey__blind': src/_fastmath.c:669: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:669: error: parse error before "v" src/_fastmath.c:671: error: `args' undeclared (first use in this function) src/_fastmath.c:676: error: `v' undeclared (first use in this function) src/_fastmath.c:677: error: `vblind' undeclared (first use in this function) src/_fastmath.c:680: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:698: error: parse error before '*' token src/_fastmath.c:699: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey__unblind': src/_fastmath.c:701: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:701: error: parse error before "v" src/_fastmath.c:703: error: `args' undeclared (first use in this function) src/_fastmath.c:708: error: `v' undeclared (first use in this function) src/_fastmath.c:709: error: `vblind' undeclared (first use in this function) src/_fastmath.c:712: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:735: error: parse error before '*' token src/_fastmath.c:736: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey_size': src/_fastmath.c:737: error: `args' undeclared (first use in this function) src/_fastmath.c:739: error: `key' undeclared (first use in this function) src/_fastmath.c: At top level: src/_fastmath.c:743: error: parse error before '*' token src/_fastmath.c:744: warning: function declaration isn't a prototype src/_fastmath.c: In function `rsaKey_has_private': src/_fastmath.c:745: error: `args' undeclared (first use in this function) src/_fastmath.c:747: error: `key' undeclared (first use in this function) src/_fastmath.c: In function `isPrime': src/_fastmath.c:761: error: `mpz_t' undeclared (first use in this function) src/_fastmath.c:761: error: parse error before "n" src/_fastmath.c:768: error: `n' undeclared (first use in this function) src/_fastmath.c:771: warning: implicit declaration of function `mpz_probab_prime_p' error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1558284&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-20 19:58:19
|
Bugs item #1473773, was opened at 2006-04-20 18:59 Message generated for change (Comment added) made by calzas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473773&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: Rejected Priority: 5 Submitted By: Juan de las Calzas Verdes (calzas) Assigned to: Nobody/Anonymous (nobody) Summary: Every mode except ECB in AES fails? Initial Comment: See a little script and its results -------------------------- import Crypto.Cipher.AES import binascii AES = Crypto.Cipher.AES text = 'abcdefghijklmnop' myIV = '0123456789ABCDEF' mykey = '16 bytes text XX' print 'Original: ', binascii.hexlify(text) for mode in range(1, 6): obj = AES.new(mykey, mode, myIV) dec = obj.decrypt(obj.encrypt(text)) print 'Mode: ', mode, ' Decr(Encr(Original)): ', binascii.hexlify(dec) -------------------------- Output: Original: 6162636465666768696a6b6c6d6e6f70 Mode: 1 Decr(Encr(Original)): 6162636465666768696a6b6c6d6e6f70 Mode: 2 Decr(Encr(Original)): fe8c779f1bf840fc83de99bf8ddca587 Mode: 3 Decr(Encr(Original)): 776978676b3c2d69180143ed54cfd062 Mode: 4 Decr(Encr(Original)): 9ef7106d9d229f2d696a6b6c6d6e6f70 Mode: 5 Decr(Encr(Original)): c2e0fd3ee88477829300f6a77565cbc0 Why doesn't it work? Shouldn't it? It does work if you create different objects for encryption and decryption. ---------------------------------------------------------------------- >Comment By: Juan de las Calzas Verdes (calzas) Date: 2006-04-20 19:58 Message: Logged In: YES user_id=1506211 Forget it. Of course the objects have to "remember" the state of the enciphering process in most of the modes. I am stupid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473773&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-20 19:55:11
|
Bugs item #1473773, was opened at 2006-04-20 18:59 Message generated for change (Settings changed) made by calzas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473773&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: Rejected Priority: 5 Submitted By: Juan de las Calzas Verdes (calzas) Assigned to: Nobody/Anonymous (nobody) Summary: Every mode except ECB in AES fails? Initial Comment: See a little script and its results -------------------------- import Crypto.Cipher.AES import binascii AES = Crypto.Cipher.AES text = 'abcdefghijklmnop' myIV = '0123456789ABCDEF' mykey = '16 bytes text XX' print 'Original: ', binascii.hexlify(text) for mode in range(1, 6): obj = AES.new(mykey, mode, myIV) dec = obj.decrypt(obj.encrypt(text)) print 'Mode: ', mode, ' Decr(Encr(Original)): ', binascii.hexlify(dec) -------------------------- Output: Original: 6162636465666768696a6b6c6d6e6f70 Mode: 1 Decr(Encr(Original)): 6162636465666768696a6b6c6d6e6f70 Mode: 2 Decr(Encr(Original)): fe8c779f1bf840fc83de99bf8ddca587 Mode: 3 Decr(Encr(Original)): 776978676b3c2d69180143ed54cfd062 Mode: 4 Decr(Encr(Original)): 9ef7106d9d229f2d696a6b6c6d6e6f70 Mode: 5 Decr(Encr(Original)): c2e0fd3ee88477829300f6a77565cbc0 Why doesn't it work? Shouldn't it? It does work if you create different objects for encryption and decryption. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473773&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-20 18:59:19
|
Bugs item #1473773, was opened at 2006-04-20 18:59 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=1473773&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 Submitted By: Juan de las Calzas Verdes (calzas) Assigned to: Nobody/Anonymous (nobody) Summary: Every mode except ECB in AES fails? Initial Comment: See a little script and its results -------------------------- import Crypto.Cipher.AES import binascii AES = Crypto.Cipher.AES text = 'abcdefghijklmnop' myIV = '0123456789ABCDEF' mykey = '16 bytes text XX' print 'Original: ', binascii.hexlify(text) for mode in range(1, 6): obj = AES.new(mykey, mode, myIV) dec = obj.decrypt(obj.encrypt(text)) print 'Mode: ', mode, ' Decr(Encr(Original)): ', binascii.hexlify(dec) -------------------------- Output: Original: 6162636465666768696a6b6c6d6e6f70 Mode: 1 Decr(Encr(Original)): 6162636465666768696a6b6c6d6e6f70 Mode: 2 Decr(Encr(Original)): fe8c779f1bf840fc83de99bf8ddca587 Mode: 3 Decr(Encr(Original)): 776978676b3c2d69180143ed54cfd062 Mode: 4 Decr(Encr(Original)): 9ef7106d9d229f2d696a6b6c6d6e6f70 Mode: 5 Decr(Encr(Original)): c2e0fd3ee88477829300f6a77565cbc0 Why doesn't it work? Shouldn't it? It does work if you create different objects for encryption and decryption. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473773&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-20 14:25:44
|
Bugs item #1473572, was opened at 2006-04-20 07:25 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=1473572&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in cfb mode with segment_size Initial Comment: After the following lines you get a 'Floating point exception' and Python interpreter crashes: Python 2.3.5 (#2, Mar 6 2006, 10:12:24) [GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Crypto.Cipher.AES >>> AES= Crypto.Cipher.AES >>> obj = AES.new('0123456789abcdef', AES.MODE_CFB, segment_size=4) >>> obj.encrypt('Anything') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1473572&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-16 17:50:51
|
Bugs item #1471372, was opened at 2006-04-17 03:13 Message generated for change (Comment added) made by eocsor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1471372&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in AllOrNothing transform. Initial Comment: (I think I've got the following right, forgive me if it's a mistake on my part. I'm still new to all this :) In Crypto.Protocol.AllOrNothing the digest method will create blocks of invalid size 0.3-0.4% of the time for random input cases. The reason for this a long_to_bytes() call without the blocksize parameter specified, which defaults to zero. Included is a patch. ---------------------------------------------------------------------- Comment By: Roscoe (eocsor) Date: 2006-04-17 03:20 Message: Logged In: YES user_id=1503309 Opps. Forgot to check I was logged in. ''' --- AllOrNothing.py 2006-04-17 02:25:24.000000000 +0930 +++ fixedAllOrNothing.py 2006-04-17 03:00:40.000000000 +0930 @@ -139,7 +139,7 @@ # we convert the blocks to strings since in Python, byte sequences are # always represented as strings. This is more consistent with the # model that encryption and hash algorithms always operate on strings. - return map(long_to_bytes, blocks) + return [long_to_bytes(i,self.__ciphermodule.block_size) for i in blocks] def undigest(self, blocks): ''' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1471372&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-16 17:43:31
|
Bugs item #1471372, was opened at 2006-04-16 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=1471372&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in AllOrNothing transform. Initial Comment: (I think I've got the following right, forgive me if it's a mistake on my part. I'm still new to all this :) In Crypto.Protocol.AllOrNothing the digest method will create blocks of invalid size 0.3-0.4% of the time for random input cases. The reason for this a long_to_bytes() call without the blocksize parameter specified, which defaults to zero. Included is a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1471372&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-08 14:12:26
|
Bugs item #1402843, was opened at 2006-01-11 13:35 Message generated for change (Comment added) made by idsvandermolen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-08 16:12 Message: Logged In: YES user_id=1390172 I implemented some padding/encryption/signing schemes. For use with RSA and block ciphers. You can find them in the patches section as patch 1466857 (pycrypto padding and support functions) ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 16:37 Message: Logged In: YES user_id=1390172 As far as I understand things (reading bug id 1266515 and PKCS#1 v2.1) it is apparantly not safe to use RSAobj directly for encryption/signing without applying encryption/signing schemes (RSAES-OAEP/RSAES-PKCS1-V1_5 and RSASSA-PSS/RSASSA-PKCS1-V1_5) as mentioned in PKCS#1 standard first. I have found this to be a problem in using pycrypto: it provides just the bare crypto algorithms, no padding algorithms or other PKCS standards. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2006-04-06 15:50 Message: Logged In: YES user_id=1388768 Without entering into the quality of the algorithm (I'm not qualified to know if it is safe enough to use as is) a simple approach to fix the issue is to ensure that the decrypted string is always prepended with enough '\0' so that its size is equal to the blocksize. Of course this suggestion is valid only if the plaintext blocks to be encrypted are validated to be exactly the blocksize as well. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 14:23 Message: Logged In: YES user_id=1390172 Apparrently according to PKCS#1 v2.1 you need to apply padding algorithms first, RSAES-OAEP (rfc3560) with encrypt/decrypt and RSASA-PSS (rfc4056) with sign/verify. Pycrypto bug id 1266515 has a RSAES-OAEP implementation attached (haven't tested it). ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 10:27 Message: Logged In: YES user_id=1390172 The encrypt method of Crypto.PublicKey.pubkey.pubkey converts a string to a long using Crypto.Util.number.bytes_to_long. As a consequence all heading 'zero' bytes within the string are discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are converted to 65L. pubkey.decrypt(pubkey.encrypt(65L)) will return 'A' I think this is a serious problem, for which I haven't got a solution (yet). Tested with pycrypto 2.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-08 14:07:17
|
Patches item #1466857, was opened at 2006-04-08 16:07 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=1466857&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 Submitted By: Ids van der Molen (idsvandermolen) Assigned to: Nobody/Anonymous (nobody) Summary: pycrypto padding and support functions Initial Comment: I had to implement some blockcipher padding algorithms (rfc 1432), some PEM processing and PKCS#1 v1.5 ecryption and signing schemes (which are not as safe as v2.1, but more common). It also includes a partially implemented ASN.1 BER decoder / DER encoder. Implementations are provided without any warranties. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1466857&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 14:37:12
|
Bugs item #1402843, was opened at 2006-01-11 13:35 Message generated for change (Comment added) made by idsvandermolen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 16:37 Message: Logged In: YES user_id=1390172 As far as I understand things (reading bug id 1266515 and PKCS#1 v2.1) it is apparantly not safe to use RSAobj directly for encryption/signing without applying encryption/signing schemes (RSAES-OAEP/RSAES-PKCS1-V1_5 and RSASSA-PSS/RSASSA-PKCS1-V1_5) as mentioned in PKCS#1 standard first. I have found this to be a problem in using pycrypto: it provides just the bare crypto algorithms, no padding algorithms or other PKCS standards. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2006-04-06 15:50 Message: Logged In: YES user_id=1388768 Without entering into the quality of the algorithm (I'm not qualified to know if it is safe enough to use as is) a simple approach to fix the issue is to ensure that the decrypted string is always prepended with enough '\0' so that its size is equal to the blocksize. Of course this suggestion is valid only if the plaintext blocks to be encrypted are validated to be exactly the blocksize as well. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 14:23 Message: Logged In: YES user_id=1390172 Apparrently according to PKCS#1 v2.1 you need to apply padding algorithms first, RSAES-OAEP (rfc3560) with encrypt/decrypt and RSASA-PSS (rfc4056) with sign/verify. Pycrypto bug id 1266515 has a RSAES-OAEP implementation attached (haven't tested it). ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 10:27 Message: Logged In: YES user_id=1390172 The encrypt method of Crypto.PublicKey.pubkey.pubkey converts a string to a long using Crypto.Util.number.bytes_to_long. As a consequence all heading 'zero' bytes within the string are discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are converted to 65L. pubkey.decrypt(pubkey.encrypt(65L)) will return 'A' I think this is a serious problem, for which I haven't got a solution (yet). Tested with pycrypto 2.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 13:51:09
|
Bugs item #1402843, was opened at 2006-01-11 12:35 Message generated for change (Comment added) made by eric_noyau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- >Comment By: Eric Noyau (eric_noyau) Date: 2006-04-06 14:50 Message: Logged In: YES user_id=1388768 Without entering into the quality of the algorithm (I'm not qualified to know if it is safe enough to use as is) a simple approach to fix the issue is to ensure that the decrypted string is always prepended with enough '\0' so that its size is equal to the blocksize. Of course this suggestion is valid only if the plaintext blocks to be encrypted are validated to be exactly the blocksize as well. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 13:23 Message: Logged In: YES user_id=1390172 Apparrently according to PKCS#1 v2.1 you need to apply padding algorithms first, RSAES-OAEP (rfc3560) with encrypt/decrypt and RSASA-PSS (rfc4056) with sign/verify. Pycrypto bug id 1266515 has a RSAES-OAEP implementation attached (haven't tested it). ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 09:27 Message: Logged In: YES user_id=1390172 The encrypt method of Crypto.PublicKey.pubkey.pubkey converts a string to a long using Crypto.Util.number.bytes_to_long. As a consequence all heading 'zero' bytes within the string are discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are converted to 65L. pubkey.decrypt(pubkey.encrypt(65L)) will return 'A' I think this is a serious problem, for which I haven't got a solution (yet). Tested with pycrypto 2.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 12:23:59
|
Bugs item #1402843, was opened at 2006-01-11 13:35 Message generated for change (Comment added) made by idsvandermolen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 14:23 Message: Logged In: YES user_id=1390172 Apparrently according to PKCS#1 v2.1 you need to apply padding algorithms first, RSAES-OAEP (rfc3560) with encrypt/decrypt and RSASA-PSS (rfc4056) with sign/verify. Pycrypto bug id 1266515 has a RSAES-OAEP implementation attached (haven't tested it). ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 10:27 Message: Logged In: YES user_id=1390172 The encrypt method of Crypto.PublicKey.pubkey.pubkey converts a string to a long using Crypto.Util.number.bytes_to_long. As a consequence all heading 'zero' bytes within the string are discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are converted to 65L. pubkey.decrypt(pubkey.encrypt(65L)) will return 'A' I think this is a serious problem, for which I haven't got a solution (yet). Tested with pycrypto 2.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 08:28:05
|
Bugs item #1402843, was opened at 2006-01-11 13:35 Message generated for change (Comment added) made by idsvandermolen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- Comment By: Ids van der Molen (idsvandermolen) Date: 2006-04-06 10:27 Message: Logged In: YES user_id=1390172 The encrypt method of Crypto.PublicKey.pubkey.pubkey converts a string to a long using Crypto.Util.number.bytes_to_long. As a consequence all heading 'zero' bytes within the string are discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are converted to 65L. pubkey.decrypt(pubkey.encrypt(65L)) will return 'A' I think this is a serious problem, for which I haven't got a solution (yet). Tested with pycrypto 2.0.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-02-26 00:14:13
|
Patches item #1438820, was opened at 2006-02-25 16:14 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=1438820&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 Submitted By: Robey Pointer (robey) Assigned to: Nobody/Anonymous (nobody) Summary: dramatically improve HMAC performance Initial Comment: When profiling paramiko (an SSH library), I eventually got to the point where the largest chunk of time was falling in pycrypto's HMAC class. In SSH (and in SSL also, IIRC), every outbound and inbound packet has an HMAC calculated on it. So this is a very high-traffic code path. I played around with different optimizations, including writing all of the HMAC class in pyrex, which gave a 25x performance improvement. However, I found out that improving just a single function (strxor) can give 10-15x improvement by itself. Since I believe there is some advantage in keeping as much of the code in python as possible, I'm submitting a patch which merely moves strxor into native C, and streamlines the HMAC setup a bit. IMHO the roughly 2x faster speed you'd get from making the whole class native C wouldn't be worth losing the readability. With this patch, a pure-python SSH implementation (based on pycrypto) is actually quite competitive with openssh for speed. Please consider this patch (or some variation of it) for the next pycrypto release. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1438820&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2006-01-11 12:35:52
|
Bugs item #1402843, was opened at 2006-01-11 12: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=1402843&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 Submitted By: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: RSA encryption failing. Initial Comment: I'm using RSA encryption to encrypt binary data. I've notice that sometimes the decrypted data do not match the encrypted one. After a lot of searching I narrowed it down to block of data starting with '\0'. See the attached test suite. This bug may be the same as the badly explained bug 1212602. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2005-12-31 18:12:42
|
Patches item #1394487, was opened at 2005-12-31 10:12 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=1394487&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Padding Initial Comment: If it would be possible, please include some array of padding schemes so I wouldn't have to manually pad with \0's insecurely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1394487&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2005-12-05 20:18:18
|
Bugs item #1364920, was opened at 2005-11-23 19:07 Message generated for change (Settings changed) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&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: Fixed Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in Zooko's fast-CTR-mode patch Initial Comment: My patch for fast CTR mode (all in C -- no Python) has a bug in that it isn't "restartable" -- if you encrypt or decrypt some data which is not itself a multiple of the block length, then subsequent calls to encrypt/decrypt will give incorrect results. I'll make fixes for this soon. In the meantime, here's a unit test showing how it doesn't work. https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches Wed Nov 23 15:00:57 AST 2005 zo...@zo... * add unit test that shows that CTR mode is not restartable -- this is a bug diff -rN -u old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py --- old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py 2005-11-23 15:06:39.000000000 -0400 +++ new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py 2005-11-23 15:06:39.000000000 -0400 @@ -146,6 +146,23 @@ print_timing(256, end-start, verbose) del obj1, obj2 + if verbose: print ' CTR mode, variable length, restart:', + strv = str[:-1] + obj1=ciph.new(password, ciph.MODE_CTR, counterstart=long_to_bytes(startctr, ciph.block_size)) + obj2=ciph.new(password, ciph.MODE_CTR, counterstart=long_to_bytes(startctr, ciph.block_size)) + start=time.time() + tempstrv = strv + while tempstrv: + chunksiz = random.randrange(1, len(tempstrv)+1) + ciphertext = obj1.encrypt(tempstrv[:chunksiz]) + tempstrv = tempstrv[chunksiz:] + plaintext=obj2.decrypt(ciphertext) + end=time.time() + if (plaintext!=strv): + die('Error in resulting plaintext from CTR mode, variable length, restart') + print_timing(256, end-start, verbose) + del obj1, obj2 + # Test the IV handling if verbose: print ' Testing IV handling' obj1=ciph.new(password, ciph.MODE_CBC, IV) ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-12-05 20:12 Message: Logged In: YES user_id=52562 The latest version fixes this bug in "restarting" ctr mode usage by preserving the offset-within-the-block between calls to crypt(). https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches https://yumyum.zooko.com:19144/pub/repos/pycrypto-zookopatches/ http://zooko.com/repos/pycrypto/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2005-12-05 20:12:34
|
Bugs item #1364920, was opened at 2005-11-23 19:07 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&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 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in Zooko's fast-CTR-mode patch Initial Comment: My patch for fast CTR mode (all in C -- no Python) has a bug in that it isn't "restartable" -- if you encrypt or decrypt some data which is not itself a multiple of the block length, then subsequent calls to encrypt/decrypt will give incorrect results. I'll make fixes for this soon. In the meantime, here's a unit test showing how it doesn't work. https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches Wed Nov 23 15:00:57 AST 2005 zo...@zo... * add unit test that shows that CTR mode is not restartable -- this is a bug diff -rN -u old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py --- old-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py 2005-11-23 15:06:39.000000000 -0400 +++ new-pycrypto-2.0.1-varlength-cctr/pycrypto-2.0.1/Util/test.py 2005-11-23 15:06:39.000000000 -0400 @@ -146,6 +146,23 @@ print_timing(256, end-start, verbose) del obj1, obj2 + if verbose: print ' CTR mode, variable length, restart:', + strv = str[:-1] + obj1=ciph.new(password, ciph.MODE_CTR, counterstart=long_to_bytes(startctr, ciph.block_size)) + obj2=ciph.new(password, ciph.MODE_CTR, counterstart=long_to_bytes(startctr, ciph.block_size)) + start=time.time() + tempstrv = strv + while tempstrv: + chunksiz = random.randrange(1, len(tempstrv)+1) + ciphertext = obj1.encrypt(tempstrv[:chunksiz]) + tempstrv = tempstrv[chunksiz:] + plaintext=obj2.decrypt(ciphertext) + end=time.time() + if (plaintext!=strv): + die('Error in resulting plaintext from CTR mode, variable length, restart') + print_timing(256, end-start, verbose) + del obj1, obj2 + # Test the IV handling if verbose: print ' Testing IV handling' obj1=ciph.new(password, ciph.MODE_CBC, IV) ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2005-12-05 20:12 Message: Logged In: YES user_id=52562 The latest version fixes this bug in "restarting" ctr mode usage by preserving the offset-within-the-block between calls to crypt(). https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches https://yumyum.zooko.com:19144/pub/repos/pycrypto-zookopatches/ http://zooko.com/repos/pycrypto/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1364920&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2005-12-05 20:11:35
|
Patches item #1255031, was opened at 2005-08-09 15:16 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&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 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: do CTR mode in pure C Initial Comment: The design in which CTR mode calls a Python callable for each block is very flexible, but suffers an obvious performance cost. After these patches, one can optionally pass either a callable *or* a string of block length. If one passes a callable, then it functions as before. If one passes a string of length block length, then it makes a copy of the contents of the strings in an internal buffer, and increments that value in C for each block. This results in a nice speed-up, for example: AES: ECB mode: 90841.10 K/sec CFB mode: 2380.59 K/sec CBC mode: 68653.57 K/sec PGP mode: 70991.19 K/sec OFB mode: 69941.49 K/sec CTR mode: 1251.37 K/sec CTR mode, variable length: 1728.07 K/sec CTR mode, fast increment: 68122.18 K/sec CTR mode, fast increment (slow decrypt): 2367.85 K/sec That last line there is where it encrypts with the fast incrementer and decrypts with the Python callback incrementer to verify that the ctr increment is computed the same way. You can also browse and download these patches via my web view: https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches There are three patches in the attached file. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2005-12-05 20:11 Message: Logged In: YES user_id=52562 Be sure and get the latest version from https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches or http://zooko.com/repos/pycrypto or https://yumyum.zooko.com:19144/pub/repos/pycrypto-zookopatches/ since earlier versions of this patch had a bug so that it generated bad results if you crypted something that was not a multiple of block length and then crypted something else using the same cryptor object. See the unit tests or the patches for details. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-08-17 15:27 Message: Logged In: YES user_id=52562 Okay, if you browse this patch server cgi script you can get the fix: https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pycrypto-zookopatches/?c=patches Or just use HTTP to fetch the files from https://yumyum.zooko.com:19144/pub/repos/pycrypto-zookopatches As you can see there are a few other patches for testing and benchmarking in there. The benchmarking requires the pyutil library. The benchmarking shows that this backwards-incompatible change of eliminating the python callback and simplifying the code gives a speedup of somewhere between 0 and 4% depending on the exact usage. (You could also keep the speedup and keep the optional backwards-compatible Python callback support, but you can't keep all three of the speedup, the optional-backwards-compatible Python callback support, and the simpler code.) ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2005-08-17 12:07 Message: Logged In: YES user_id=52562 There's an issue in this patch -- it increments the counter before encrypting, so if you initialize the counter with 0 then the first block will be encrypted with 1. I'm fixing this issue, but my new patch is going to get rid of the optional Python callback entirely. (Maintaining both ways to do it is complicating things.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=320937&aid=1255031&group_id=20937 |
|
From: SourceForge.net <no...@so...> - 2005-11-29 19:51:49
|
Bugs item #1343753, was opened at 2005-10-31 07:34 Message generated for change (Comment added) made by akuchling 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 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: A.M. Kuchling (akuchling) Date: 2005-11-29 14: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 07: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 |
1 message has been excluded from this view by a project administrator.
