kjj
Legendary
 Offline
Activity: 1302
Merit: 1024
|
 |
June 26, 2011, 06:03:37 PM |
|
If the device does all of the wallet stuff itself, you can take it on the road.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
If I remember correctly, ArtForz is already working on a secure key storage and signing device. I'll see if I can find a chat log. Found it: http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/05/05/20#l485685Sounds like he and I came to the same conclusions, he just beat me by a month or two. I really need to start hanging out on IRC. |
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
|
|
|
|
|
|
|
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Mashuri
|
|
January 14, 2014, 08:05:13 PM |
|
Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct? So I've been thinking a lot about wallet security; Matt's password patch is a good first step, but maybe we can at least build in some infrastructure for a better solution. We really need a solution where transactions are generated on one device and then verified on a second device, so malware must compromise both devices (e.g. computer and mobile phone, or web wallet and mobile phone) to steal coins. gmaxwell from IRC thinks it can be done without multiple signatures (just with the standard transaction we have now), and staring at the ECDSA math on this wikipedia page I think he's right. I believe he was inspired by ByteCoin's observation that you can create a vanity public key generating service that is secure-- the service can generate the public key but not know the private key. I'm mostly writing this to convince myself it could work and to give ByteCoin and Hal and gmaxwell and anybody else who knows a whole lot more crypto than me a chance to poke holes in it. And then point me to a FIPS standard that has it all figured out already... So: generating an ECDSA keypair means choosing a private key d A, then calculating the public key Q A = d AG (where G is a fixed point on the elliptic curve). The key generation can be split; have device 1 choose d A1 and device 2 choose d A2. Device 1 then sends Q A1 to Device 2, and it can calculate Q A1d A2 = Q A1*A2. Or in english, Device 1 finds a public key on the curve. Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key. So great, neither Device 1 or 2 needs to ever have both parts of the private key on them to generate the shared public key. Now lets say Device 1 wants to spend a TxOut that is one of these split keys. The key bit of the signature generation algorithm (see the Wikipedia page: http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm ) is: ... 4. Calculate s = k -1(z+rd A)(mod n) ... That can be rewritten as: Calculate s = k -1(z+rd A1d A2)(mod n) And now I'm stuck. Can that equation be refactored so that Device 1 can compute part of the signature, send its partial result to Device 2, and have Device 2 complete the signature (without Device 2 being able to figure out 1's part of the private key?)? |
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
January 14, 2014, 09:50:28 PM |
|
Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct?
Um, no not quite. What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works. Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being. But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own. Actually, that's not quite right. What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device. Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone. When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone. This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen. 'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree. This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time. But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS. Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped. Either device could be backed up as well. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
|
Mashuri
|
|
January 14, 2014, 10:37:21 PM |
|
Yes, but my intent is different, so I just wanted to verify this specific part of the equation. Can Computer A and Computer B generate a shared public key with their respective private keys, without compromising the shared private key? Is the main security problem only when the shared private key actually needs to be used? Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct?
Um, no not quite. What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works. Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being. But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own. Actually, that's not quite right. What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device. Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone. When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone. This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen. 'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree. This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time. But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS. Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped. Either device could be backed up as well. |
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
January 14, 2014, 10:53:09 PM |
|
Yes, but my intent is different, so I just wanted to verify this specific part of the equation. Can Computer A and Computer B generate a shared public key with their respective private keys, without compromising the shared private key? Is the main security problem only when the shared private key actually needs to be used?
You're obviously already beyond my skill level. I'm sorry, but I can't help more. But I don't believe that this particular idea ever got much traction. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
|
Mashuri
|
|
January 15, 2014, 11:27:56 PM |
|
Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key. This is the part I'm fixating on right now. I assume this is done by Device 2 in order to obfuscate it's private key from Device 1. Can someone provide an example of an equation that would do this? EDIT: Gavin, I also assume you made a typo at the end of your sentence and meant Device 1's private key instead of public key. |
|
|
|
|
