Re: [viff-devel] Which operations for HSM (Hardware Crypto)
Brian Graversen [EMAIL PROTECTED] writes: I have talked to IBM, and we are currently waiting for a license for the tool required to load application code into the IBM 4758 cards. We should get such a license at the beginning of august. The code is just basic C-code, so we can start writing the applications right now. The RSA encryption is available i the box, so it is just the secret share code that we need for now. Okay -- that code should be simple, see viff.shamir for a straight forward implementation of Shamir's secret sharing scheme. If we let the 4758 do all the secret sharing, it can keep the shares stored encrypted on disk, using an internal 3DES key, and the encryption of the shares would then be an internal part of the secret share mechanism in the 4758. I think that is a very nice interface: you give an input in clear text and you get encrypted shares back. I think I would start by making a subclass of viff.runtime.Runtime, and in this subclass you can override the shamir_share and _recombine methods. That should make the shamir-share-open.py example work. Overriding the add and mul methods should take care of most of the other examples! I would love to see this code online, and if you want we can setup a repository at hg.viff.dk where you can push to. I know that it is only you who can test the code, but I'm still curious :-) If we do this, then the code flow (time flows left to right) would look like this: viff --- o --- o --- o --- o --- o ... \ \ \ \ \ \ hsm --- o --- o --- o --- o --- o --- o ... which is meant to say that you can develop in your own pace in the hsm repository and then once in a while you can pull in new stuff from the viff repository. The hsm repository will then mostly be a superset of the viff repository. When we are happy with the hsm stuff we can then do a pull in the other direction. If you find a bug in the main viff code, then the change should be applied to the viff repository and then pulled into the hsm repository. But if we forget about this, then don't worry -- there is a transplant extension to Mercurial that allows us to recover. I would of course be happy to setup repositories for all of you guys! -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Which operations for HSM (Hardware Crypto)
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
Re: [viff-devel] Which operations for HSM (Hardware Crypto)
D. J. Bernstein [EMAIL PROTECTED] writes: Let me emphasize that this is just the cryptographic part of NaCl, and just an initial prototype. We're much more feature-complete than was scheduled for this point but there's also quite a lot more to do. Right now the prototype is in internal review within CACE; we'll publish it in a few weeks, and of course we would be very happy to receive feedback from potential users! Super, I'm sure we can provide some of that. What immediately struck me as very nice about the API is that it tries to make things simple and just do the right thing -- that is an excellent design goal! -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Which operations for HSM (Hardware Crypto)
Ivan Bjerre Damgaard [EMAIL PROTECTED] writes: Quoting D. J. Bernstein [EMAIL PROTECTED]: Martin Geisler writes: I would love to build a set of Python bindings for it and see it running in VIFF... :-) Python NaCl is on our essential-items todo list. It'd be great if you have time to help out. Since this is CACE work I'd suggest the WP2 mailing list as the central place to discuss the API. It's great to see some activity about this interface issue. I hope also Thomas from Alexandra will take part in this - I post this on the VIFF list, since then he'll see it. Thomas, if you are not on the WP2 list, you can get the Technikon guys to put you there.. I hate it when things disappear into closed mailinglists such as the CACE WP2 list. So I would prefer the design to be done in the open on this list. A while ago I invited everybody from CACE to join, but I think it was only Dan and Tanja who reacted on that :-( I would also like the discussion here since I believe VIFF will be the first user of the interface and so the discussion seems relevant here. -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Which operations for HSM (Hardware Crypto)
Let me emphasize that this is just the cryptographic part of NaCl, and just an initial prototype. We're much more feature-complete than was scheduled for this point but there's also quite a lot more to do. Right now the prototype is in internal review within CACE; we'll publish it in a few weeks, and of course we would be very happy to receive feedback from potential users! Martin Geisler writes: I would love to build a set of Python bindings for it and see it running in VIFF... :-) Python NaCl is on our essential-items todo list. It'd be great if you have time to help out. Since this is CACE work I'd suggest the WP2 mailing list as the central place to discuss the API. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Which operations for HSM (Hardware Crypto)
Brian Graversen [EMAIL PROTECTED] writes: Hi Brian Attached is the first sample implementation (can we attach files?) Sure -- messages above 1 MiB will be held for moderation, though. If you have larger stuff (up to 4 MiB) you are welcome to send it to [EMAIL PROTECTED] or attach it at the issue tracker: http://tracker.viff.dk/ (DAIMI seems to be messing around with my office computer, so it is down right now...) By the way, see http://lists.viff.dk/ (that page is always a bit slow to load) for links to all three VIFF mailing lists. In this case it would have been slightly more convenient to just attach the two source files and the jpeg image as-is so that we don't have to decompress the zip file. of getRandomBytes(int), and a screenshot of the module being called from Python. There is a build-script as well. Wow, you're quick! This looks really good -- much easier than I had expected. And the bytes in the screenshot sure do look very random :-) It is not really possible to build it without having the IBM software installed, nor is it possible to run it without the IBM hardware, so the code is more for those interested at looking at it. It is very simple... Thanks for posting it anyway, it's really cool to get a glimpse of how such a gadget works. I'm more interested in hearing how this will be configurable in the client software. Since some clients will run using software, and at least one will run using the IBM hardware, I'm guessing some configuration will have to be handled in the python code, so it knows which crypto-library to use (hardware or software). Definitely. If you look at BasicRuntime.add_options you will see that there is already a simple system in place for configuring the VIFF runtime classes. I was going to send you this link: http://viff.dk/doc/0.6/runtime.html#viff.runtime.BasicRuntime.add_options but then I saw that it was undocumented :-( *Everybody*: If you would like to get going with VIFF development, then please find such undocumented functions and send us patches with documentation. You can follow along in the development by subscribing to here: http://lists.viff.dk/listinfo.cgi/viff-commits-viff.dk Then check out the newly commited code and add documentation. This is a great and much appreciated way to help development! Just thinking Martin will fix it is not going to scale since I can only do so much, and I also forget things... :-) Ehmm, back to the point: The idea is that a program calls this static method like this (see apps/millionaires.py for a nice example): from optparse import OptionParser from viff.runtime import Runtime parser = OptionParser() Runtime.add_options(parser) options, args = parser.parse_args() So one could add a new command line flag (maybe --hardware-crypto, --ibm4758, or something similar) in add_options and then all correctly written client programs should pick it up. In the runtime class self.options holds the command line options and can act accourdingly. Here that would probably mean trying to load the ibm4758 Python module and error out if that fails. Try taking a look at how the code deals with PyOpenSSL right now. This is also in add_options, by the way. To use the random bytes you will want to fiddle with viff.util.rand. This is a Random instance which is used by all VIFF code to access random data. Replacing that with your own subclass of SystemRandom in which you override random() and getrandombits() should work beautifully! See http://docs.python.org/dev/library/random.html and the source of random.py (maybe in /usr/lib/python2.4/random.py). A final thing: if you use IRC, then I'm in #viff on freenode.net. -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
