Quote from: ben-abuya on June 24, 2011, 06:13:06 PM

Quote from: kjj on June 24, 2011, 05:41:17 PM

Quote from: ben-abuya on June 24, 2011, 05:10:45 PM

getPublicKeyTransactions -- why do we need that?

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later. It would use this request to ask for them. As an aside, the secure device should only make this request upon a command from the user. That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.

But if you're getting the unsigned transaction, that will include the proper inputs. I'm not sure why you'd need all the previous transactions. The idea is that we don't assume anybody is honest. The secure device makes sure we're never doing anything except sending the displayed amount to the displayed address. It's impossible to do anything else with that signed transaction no matter what you feed the secure device.

Your real wallet is in the device. The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it. When you want to pay, it sends the destination address and the amount, only. The device then creates the transaction all by itself, using transaction records it already knows.

Quote from: ben-abuya on June 24, 2011, 06:13:06 PM

Quote from: kjj on June 24, 2011, 05:41:17 PM

Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below. Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.

I'm probably missing something here. If we know the secure computer or device's public key and encrypt the whole JSON response with that key, what else do we have to worry about? In any case, all information being sent here is in the public block chain anyway so I'm not sure if there's a point encrypting it.

Encrypting the whole thing would certainly work, but it is probably overkill. You can't just encrypt the data using the keys themselves, or you provide the attacker with a whole lot of known plaintext to degrade your key with. Most encrypted streams exchange session keys and do a whole lot of crap behind the scenes, and we would have to do all of that ourselves, all to protect stuff that doesn't really need to be protected.

Simple hashing seems sufficient. At least for now. Eventually, sure, we'll probably want the serial communication to be encrypted. But for the first step, I'd like to be able to debug the thing with a 'scope.