Hi Martin. > 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.
I guess it depends on what you want when you store the share in the HSM. If you afterwards delete it from local memory, you will still need a way to get it back later (the id), so using the python id function on the share object (GFElement) would be counter to this, since you would need to keep the share in memory to recreate the id. Let us think a bit about that. Do we even want to store the shares in the HSM? What would be the benefits? Security/performance? > What kind of arithmetic can you do on values stored inside the IBM > 4758 and can you do it fast? First the shares are not actually physically stored inside the HSM, they are simply encrypted with a key from the HSM, and stored elsewhere (disk, memory, database, whatever we like). Second, I'm not sure what is possible yet. Ivan said he know some guy that could do tricks with the HSM, so it would be possible to do all kinds of stuff, but I think we need to look at the performance side of it, perhaps a software implementation would be faster, and if we cannot store the shares inside the HSM, and make the operations without the data leaving the HSM, then the security benifits would be minimal. > > 1. Memory allocation > > 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. Yes, I came to the same conclusion after playing a bit with the stuff. All memory allocated locally using malloc will have to be free'd in C before returning, and then the return value is build using the python supplied function. It makes sure that refcount is incremented, and python then free's that python object when the last reference goes away, so all is well as I see it. Kind regards Brian Graversen _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
