Physical device to generate public/private key pairs
runeks:
If you're interested in learning ECC, Certicom has a lot of information that is reasonably easy to understand. It isn't really as complex as it may sound. Just a lot of equations.
http://www.certicom.com/images/pdfs/WP-ECCprimer.pdf
http://www.certicom.com/index.php/10-introduction
Quote from: casascius on October 07, 2012, 09:59:33 PM
If you can come up with a console app that will run under Linux, perhaps takes some entropy or a 32-byte private key and prints a single bitcoin address to the console, I can convert it to run on the credit card machine. I can also provide the part that sends QR codes to the printer, given just the string to encode.
How would one get entropy on such a device? Creating a standalone console app that can create an address from a private key is relatively simple. It might be something I would be up to.
It would require a standalone implementation of SHA256, RIPEMD160, EC math and BIGNUMs.
EDIT: Looking at OpenSSL's BIGNUM implementation, this depends on things as stdio.h and assert.h. What is actually available on this credit card machine?
Stephen Gornick:
Quote from: bg002h on October 07, 2012, 08:33:49 PM
How hard would it be to build an electronic device that could generate and display a Bitcoin public / private key pair? It would be nice to have a physical device that could, without connecting to anything, give you a new safe address to dump your coins to at the press of a button.
For additional discussion on that:
Air gapped wallet printer
- http://bitcointalk.org/index.php?topic=77930.0
Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices
- http://bitcointalk.org/index.php?topic=78614.60
Offline Paper Wallet Creator - Raspberry Pi?
- http://bitcointalk.org/index.php?topic=74615.0
Casascius Bitcoin POS system
- http://bitcointalk.org/index.php?topic=46366.20
So obviously ... there is demand for such an item if it were to exist and be commercially available.
casascius:
Quote from: runeks on October 08, 2012, 01:26:06 AM
If you're interested in learning ECC, Certicom has a lot of information that is reasonably easy to understand. It isn't really as complex as it may sound. Just a lot of equations.
http://www.certicom.com/images/pdfs/WP-ECCprimer.pdf
http://www.certicom.com/index.php/10-introduction
Quote from: casascius on October 07, 2012, 09:59:33 PM
If you can come up with a console app that will run under Linux, perhaps takes some entropy or a 32-byte private key and prints a single bitcoin address to the console, I can convert it to run on the credit card machine. I can also provide the part that sends QR codes to the printer, given just the string to encode.
How would one get entropy on such a device? Creating a standalone console app that can create an address from a private key is relatively simple. It might be something I would be up to.
It would require a standalone implementation of SHA256, RIPEMD160, EC math and BIGNUMs.
EDIT: Looking at OpenSSL's BIGNUM implementation, this depends on things as stdio.h and assert.h. What is actually available on this credit card machine?
stdio.h, string.h, stdlib.h, math.h should all be available.
Entropy has to come from a combination of the keypad and timer. In addition to scraping system-specific data, during initialization we have the user mash the keyboard to initialize the entropy pool. Using the key scan codes of the key strokes as well as the precise timing between them (system tick counter with resolution in the millisecond range) as well as the system clock, we get enough entropy to start generating keys. Each keypress is used to add entropy to the pool, and we persist the entropy to the file system (which is saved as battery-backed RAM).
It is a whole lot like what bitaddress.org does to acquire entropy when you first load it, other than we can a) do it for longer because b) given persistent storage, we only have to exhaustively do it once.
Finally, as you might notice in my bitcoin address utility: I prefer to generate private keys by using the SHA256 hash of a string that is partly system generated, and partly provided by the user. The system generates a long random string (80+ characters) and then the user is invited to insert keyboard mash into the middle of it. SHA256 is done on the resulting string plus n, where n is an incrementing number. This provides simple auditability that the RNG isn't rigged (or if it somehow is, it won't be harmful), and allows the user a decent chance to "cut the deck", without too much worry that the user's gibberish won't have enough entropy.
runeks:
^ How much storage space and memory is available on the device? Perhaps one could compile libcrypto and libssl and statically link them with the program. libcrypto.a and libssl.a are 5.1 MB in total.
casascius:
A device like this on the lowest end typically has 1-2 MB RAM and 1-2 MB Flash.
It's not constructed like a typical computer though. The CPU can execute programs directly from flash without copying them into RAM, and the RAM is battery-backed and is the main file system.
Navigation
[0] Message Index
[#] Next page
[*] Previous page