Brian Graversen <[EMAIL PROTECTED]> writes: Hi Brian
> We now have a working PC running with the IBM 4758 PCI-Crypto card, > and a few test programs running. > int getRandomBytes(int count, unsigned char **randomBytes); That sounds good. > int setShare(int id, unsigned char *shareValue); > int getShare(int id, unsigned char **shareValue); The way a secret shared number is currently represented in Python is as a Share object. This object in turn holds a GFElement object, which holds the actual Python integer. It is this inner integer that we want to keep secret, right? Then I guess we could identify it by the ID of the GFElement object holding it. GFElements are immutable. By ID I mean the output of id(e) where e is a GFElement -- I don't know what that maps to on the C side of things, but the id() Python function returns a unique integer for each Python object. What kind of arithmetic can you do on values stored inside the IBM 4758 and can you do it fast? About making it fast, the we have talked about switching to GMPY (the Python bindings of GMP) instead of plain Python integers since GMPY is faster for big numbers: http://code.google.com/p/gmpy/ I'm not sure how this will play together with a crypto box... Another thing: Tanja Lange and Dan Bernstein has just made a wonderful crypto library for the NaCl part of the CACE project. NaCl is mentioned here: http://www.cace-project.eu/index.php?Itemid=12 and those of you who are part of the CACE project can see the announcement here http://lists.cace-project.eu/pipermail/wp2/2008-July/000026.html The library promises to be very fast and very secure. Maybe it could run on an IBM 4758? Tanja, Dan: is it okay to post the code here? I saw that it is in the public domain, but so far it is only to be found in the secret CACE data dump (also know as the SVN repository). I would love to build a set of Python bindings for it and see it running in VIFF... :-) > 1. Memory allocation > How is memory to be handled? One way would be to have the caller > (the Python code) allocate enough memory to store return values (fx. > from getRandomBytes), or perhaps it would be better to let the C > code allocate the memoery? How is this usually handled with > Python/C? Anyone? I think you answered that with the code you posted: the Python code knows nothing about the memory, it is the C extension which manages this. > Regarding free'ing the memory when done, can Python do this on its > own, or will we need to expose some cleanup-handles in the C-module, > for free'ing memory allocated earlier in the C code? The Python side of the code is not expected to free memory, there is a garbage collector which takes care of that. It uses reference counters and I have seen that C extensions do a lots of PyINCREF and PyDECREF calls to maintain these counters: http://docs.python.org/api/countingRefs.html http://docs.python.org/api/refcounts.html There must then be some way of hooking up a cleanup function which will be called when the count becomes zero. -- Martin Geisler _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
