"Adam Langley" <[EMAIL PROTECTED]> writes:
Hi Adam
> djb suggested I email this list and solicit any suggestions for
> Python bindings for NaCl.
>
> I sent an RFC patch to djb last week containing a suggested set of
> bindings which worked like this:
>
> Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
> [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import nacl
> >>> nacl.hash('test')
>
> '\xee&\xb0\xddJ\xf7\xe7I\xaa\x1a\x8e\xe3\xc1\n\xe9\x92?a\x89\x80w.G?\x88\x19\xa5\xd4\x94\x0e\r\xb2z\xc1\x85\xf8\xa0\xe1\xd5\xf8O\x88\xbc\x88\x7f\xd6{\x1472\xc3\x04\xcc_\xa9\xad\x8eoW\xf5\x00(\xa8\xff'
> >>> nacl.hash_md5('test')
> "\t\x8fk\xcdF!\xd3s\xca\xdeN\x83&'\xb4\xf6"
> >>> dir(nacl)
> ['__doc__', '__file__', '__name__', 'auth', 'auth_hmacmd5',
> 'auth_hmacsha256', 'auth_hmacsha512', 'hash', 'hash_md5',
> 'hash_sha256', 'hash_sha512', 'secretbox_salsa20hmacsha512',
> 'streamxor', 'streamxor_salsa20', 'streamxor_salsa2012',
> 'streamxor_salsa208', 'verify16', 'verify32']
>
> Thus the bindings match the C interface very closely. There's a
> default function (i.e. 'hash') and a series of specific functions
> (i.e. 'hash_sha256'), again like the C interface. The arguments to the
> functions match the C interface where:
> * outputs are returned, rather than passing a pointer in
Nice! :-)
> * 'string' inputs can be unicode and will be serialised using the
> default codec
I think I would have used plain bytestrings here too and require that
the application takes care of encoding the Unicode string in a
suitable way (UTF-8 or whatever works for the application).
The default encoding is still ASCII as far as I know, so it will
probably not work anyway when the bindings try to convert the Unicode
strings.
> * 'key' inputs must be plain strings
Good, makes sense.
> This is for Python 2.x. For 3.0 the the two types of strings are
> more distinct.
>
> Milestones on the path:
> * Getting NaCl to build as a shared library. I've already managed
> this with a hack but it needs to be done properly
> * Getting the ELF DSO visibility correct for all the symbols. Fiddly.
>
> I don't have the current patch on this box, but it's available on
> request.
Okay. If you want to, you can get all the repository- and web-space
you want on viff.dk. Or maybe you could put up the bindings on pypi?
I think it would look great if NaCL and pyNaCL (if that is the right
name?) would be put out there as small open source projects. Then we
would actually have produced something concrete for others to use in
the CACE project.
There's also bitbucket.org which provides Mercurial repository
hosting, an issue tracker, and a wiki. In combination with pypi I
think this would provide a nice setup for a small project.
> Comment away. Or just email me Python code that you wished worked
> and I'll see if I can make it so.
>From the sample above it looks exactly like I imagined: simple,
straight forward, and with minimum fuzz! I had not expected Python
bindings so soon, so this is just like an early Christmas present :-)
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
