diff options
Diffstat (limited to 'pipermail/pycrypto/2011q2/000441.html')
| -rw-r--r-- | pipermail/pycrypto/2011q2/000441.html | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/pipermail/pycrypto/2011q2/000441.html b/pipermail/pycrypto/2011q2/000441.html new file mode 100644 index 0000000..d161e82 --- /dev/null +++ b/pipermail/pycrypto/2011q2/000441.html @@ -0,0 +1,139 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [pycrypto] Initial review of Thorsten's Py3k changes + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20Initial%20review%20of%20Thorsten%27s%20Py3k%20changes&In-Reply-To=20110130014708.GB2551%40rivest.dlitz.net"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000440.html"> + <LINK REL="Next" HREF="000442.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[pycrypto] Initial review of Thorsten's Py3k changes</H1> + <B>Thorsten Behrens</B> + <A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20Initial%20review%20of%20Thorsten%27s%20Py3k%20changes&In-Reply-To=20110130014708.GB2551%40rivest.dlitz.net" + TITLE="[pycrypto] Initial review of Thorsten's Py3k changes">sbehrens at gmx.li + </A><BR> + <I>Sun Apr 17 08:15:57 CST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="000440.html">[pycrypto] AES.Mode_PGP +</A></li> + <LI>Next message: <A HREF="000442.html">[pycrypto] Initial review of Thorsten's Py3k changes +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#441">[ date ]</a> + <a href="thread.html#441">[ thread ]</a> + <a href="subject.html#441">[ subject ]</a> + <a href="author.html#441">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>I am going back into the code to take a peek at your suggestion. + + +On 1/29/2011 8:47 PM, Dwayne C. Litzenberger wrote: +><i> Have a look in the various common.py files. All of the hex test vectors are +</I>><i> being fed through either a2b_hex or b2a_hex. I think it should be possible +</I>><i> to make versions of b2a_hex and a2b_hex that also do bytes->str and +</I>><i> str->bytes conversions, respectively. +</I>><i> +</I>><i> The following code works in both Python 2.1 and Python 3.2b2: +</I>><i> +</I>><i> from binascii import b2a_hex as _b2a_hex, a2b_hex as _a2b_hex +</I>><i> from codecs import ascii_decode as _ascii_decode +</I>><i> def bin2hex(bts): +</I>><i> """Like b2a_hex, but returns a str instead of bytes in Python 3.x""" +</I>><i> return _ascii_decode(_b2a_hex(bts))[0] +</I>><i> def hex2bin(s): +</I>><i> """Like a2b_hex, but expects a str instead of bytes in Python 3.x""" +</I>><i> return _a2b_hex(s.encode('ascii')) +</I> +This would actually make things worse. That it works at all is to be +considered a bug - there's a TODO I have not followed up on yet, and +that TODO is to add type-checking to all functions so that an error is +returned if a parameter is not "an object interpretable as a buffer of +bytes". That is, if encode() is called with a unicode (str) object, that +should raise an error. + +The reason I believe that pycrypto should check type is that the Python +3.x stdlib behaves that way: + + >>> from hashlib import sha1 + >>> h = sha1() + >>> h.update("lorem") +Traceback (most recent call last): + File "<stdin>", line 1, in <module> +TypeError: Unicode-objects must be encoded before hashing + >>> h.update(b"lorem") + >>> print (h.hexdigest()) +b58e92fff5246645f772bfe7a60272f356c0151a + +For consistency, I have both Crypto.Hash and Crypto.Cipher behaving this +way. The changes are in the doc, but in a nutshell: + +Crypto.Hash + +Python 3.x: digest() returns a bytes object +Python 3.x: hexdigest() returns a bytes object +Python 3.x: The passed argument to update() must be an object +interpretable as a buffer of bytes + +Crypto.Cipher + +new() +Python 3.x: ```mode`` is a string object; ```key``` and ```IV``` must be +objects interpretable as a buffer of bytes. + +cipher object +Python 3.x: ```IV``` is a bytes object. + +decrypt() +Python 3.x: ```string``` must be an object interpretable as a buffer of +bytes. +decrypt() will return a bytes object. + +encrypt() +Python 3.x: ```string``` must be an object interpretable as a buffer of +bytes. +encrypt() will return a bytes object. + + +If these new conventions will cause an issue, let's discuss that now, +before I add the type-checking. + + +All that having been said, I still think it should be possible to have +the vectors be Unicode literals and to convert them to a bytes object +when reading them in. It just will need to be done in a different part +of the code. + +Thorsten + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000440.html">[pycrypto] AES.Mode_PGP +</A></li> + <LI>Next message: <A HREF="000442.html">[pycrypto] Initial review of Thorsten's Py3k changes +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#441">[ date ]</a> + <a href="thread.html#441">[ thread ]</a> + <a href="subject.html#441">[ subject ]</a> + <a href="author.html#441">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">More information about the pycrypto +mailing list</a><br> +</body></html> |