Physical device to generate public/private key pairs

[runeks]

I've put up the code on GitHub, in case you want to take a stab at it casascius

https://github.com/runeksvendsen/sbag

The file grows to 2.0 MB when I statically link it.

I'm pretty sure we have a half-dozen or so credit card machines in stock. Love to find you some dev equipment....

Thank you very much for the offer! I would have no idea what to do with one of those machines though, so we're probably better off leaving the building and transferring of the binaries to either yourself or casascius.

[hashman]

Watching development here in the keypair generation space.
I want these things to be disposable after use for maximum security. 

[Remember remember the 5th of November]

Haha! Doh! I was using the Debug build. The Release build is 1.1 MB.

EDIT: Hmm. I see references to .so files when I check the executable via strings:

Code:

rune@rune-desktop:~/.workspace/sbag/Release$ strings sbag|grep "\.so"
/lib64/ld-linux-x86-64.so.2
libc.so.6

ld-linux.so is the dynamic linker and libc.so is the Standard C Library. All of these are specific to that ABI and therefore wont work on anything else.

[bg002h]

Watching development here in the keypair generation space.
I want these things to be disposable after use for maximum security. 

maximum security would be open code...not necessarily your being able to trash the device

[runeks]

Haha! Doh! I was using the Debug build. The Release build is 1.1 MB.

EDIT: Hmm. I see references to .so files when I check the executable via strings:

Code:

rune@rune-desktop:~/.workspace/sbag/Release$ strings sbag|grep "\.so"
/lib64/ld-linux-x86-64.so.2
libc.so.6

ld-linux.so is the dynamic linker and libc.so is the Standard C Library. All of these are specific to that ABI and therefore wont work on anything else.

The above output is from where I forgot to pass -static to the linker. With that option the file is 2.0 MB and this is the output of strings:

Code:

rune@rune-desktop:~/.workspace/sbag/Release$ strings sbag|grep "\.so"
/etc/ld.so.cache
ld.so-1.7.0
glibc-ld.so.cache1.1
/etc/ld.so.nohwcap

But I'm not sure this is relevant, as it's not me who will be building the code. It should be built with the SDK for whichever machine is to be used. casascius mentioned that the SDK he has used includes headers like stdio.h, string.h, stdlib.h and math.h, so I presume this would work as a replacement for glibc, and the dynamic linker that my build depends on.

[hashman]

Watching development here in the keypair generation space.
I want these things to be disposable after use for maximum security. 

maximum security would be open code...not necessarily your being able to trash the device

I am worried about electronic traces of previous key generation being detectable.
Hardware backdoors could save the keys in memory.
Keyloggers, etc., could keep some trace of the keys.
If the device could be made cheaply enough and destroyed, it would provide that much more peace of mind. 

For this reason I don't even like to use an external printer for paper wallets, but write keys down by hand.
Obviously, this is not a scalable solution.

I'm wondering, has anybody destroyed any items for security? 

I would imagine that Casascius' trash might have some people going through it...   

[casascius]

I am worried about electronic traces of previous key generation being detectable.
Hardware backdoors could save the keys in memory.
Keyloggers, etc., could keep some trace of the keys.
If the device could be made cheaply enough and destroyed, it would provide that much more peace of mind.  

For this reason I don't even like to use an external printer for paper wallets, but write keys down by hand.
Obviously, this is not a scalable solution.

If the device is yours and never connects to a network, it's not going to be a big deal.  Even if it had a backdoor, if it never goes online, how is it ever going to snitch to command central?  Same goes for your printer if its only connection is USB.

I would imagine that Casascius' trash might have some people going through it...  

They'd find a lot of dirty diapers, but that's about it.  Maybe soon it will have chocolate bitcoins.  When I produced private keys, I made sure to produce exactly one copy.  Each sheet was hand-inspected to insure uniqueness and conformity with the planned sequence.  There were overprints, naturally, because those buggers are hard to line up in the printer on the first try, but they were overzealously destroyed and won't be found in the trash.

Most of them I destroyed by pulping with water in a commercial blender.  My other thought was to torch them in the outdoor barbecue, but I didn't want people coming and digging through the ashes of my barbecue looking for private keys!

[Realpra]

Well:
1. You don't know whats in the driver connected to that USB port, for all you know it sends info online for "updating purposes".
2. Its all made in China, so both PC, printer AND whatever other devices (usb) you use may come with one hardware backdoor after the other.
3. I really like my wireless network printer *sob*.

For perfect security you really need an offline printer and PC in a Faraday's cage that you are both willing to toast after whatever amount of years used and with only power cords coming in/out that cage.

For an operation your size I would say its a must.. but of course anything is better than Bitcoinica's email reset for admin passwords......