Brian Graversen <[EMAIL PROTECTED]> writes: Hi Brian
>> 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. Yes, but I was thinking of keeping the GFElement in normal memory and then let its associated integer reside in the crypto hardware. So I wont delete the GFElement from memory, only its value field. > 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? I imagine a system where I take my input and give it to the HSM. It would then secret share the input using its own secure randomness and encrypt each share using the recepients public key. The encrypted shares are then output form the HSM and sent over the network. When receiving an encrypted share it is stored on disk until needed. When "a + b" is to be calculated and when we have encrypted shares of a and b, then the shares are loaded into the HSM, decrypted and added inside the HSM. The sum is encrypted before being output from the HSM and stored on disk. Doing these things requires the HSM can do public key crypto (which should be no problem) and can run simple programs. If you can get a Shamir secret sharing running inside the HSM, then the rest is trivial. Shamir secret sharing itself is simple: it requires random numbers and arithmetic modulo a given prime -- see viff.shamir. >> 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). Ah, okay -- I only read some of the IBM pages which described the 4758 unit as a something close to a general purpose computer: The IBM 4758 PCI Cryptographic Coprocessor encapsulates a 486-class processing subsystem within a tamper-sensing and tamper-responding environment where you can run security-sensitive processes. [...] (http://www.ibm.com/security/cryptocards/pcicc/overview.shtml) > 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. Yeah that's also what I think, but lets see what the Cryptomatic guys says is possible and what is not. Also, as Ivan notes, the IBM 4758 will work well as a tool for keeping shares secure when stored on disk waiting to be processed -- which is another problem we have talked about... -- Martin Geisler _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
