Author

Topic: Security of password based transactions (Read 919 times)

newbie
Activity: 20
Merit: 1
January 08, 2013, 09:55:12 AM
#9
My bad. That isn't strictly necessary. I just wanted to know if there was a way to make some information public and send the coins to the discoverer.
Sure. Just have them be searching for the private key that controls the funds. There have been a couple contests similar to that on these boards, though I don't have the time to dig them all up right now.

That's an option, but I wanted that no one could get the coins without making the solution public. But then we get back to the problem of the nodes capturing the transmission. I see there would be double-spend-like conflicts unless you add some protection...
newbie
Activity: 20
Merit: 1
January 08, 2013, 09:39:45 AM
#8
Script is probably too limited to express a program that can check solutions to interesting computational problems, but you may be interested in this:

https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

That's a nice addition. My original idea was minimizing trust in anything that is not the Bitcoin network, but, for certain things, access to an external arbiter might be necessary.


legendary
Activity: 1526
Merit: 1134
January 08, 2013, 04:23:15 AM
#7
In some scenarios I had in mind, as long as the correct answer is given, it wouldn't be so important to have brute force attacks. The coins would not be supposed to be for someone in particular, but for anyone who could give the answer and made it public. Anyway, to prevent dictionary attacks I thought you could add some salt, like in password checking in computers.

Alright. If you don't care if somebody finds the coins then no problem. But perhaps "password" is not the right term to use for such a thing.

Salting doesn't help much. Modern GPUs can brute force billions of (salted) password hashes per second. It turns out that most peoples passwords can be found this way, given only a hash. Inhumanly strong passwords can still work, but then what you've got isn't really a word per se, it's a private key!

Quote
I was also thinking in solutions to problems that are hard to compute, but also easy to check (like NP problems). You could offer a reward for a solution which checks right. You wouldn't mind brute force attacks, in fact you would encourage them.

Script is probably too limited to express a program that can check solutions to interesting computational problems, but you may be interested in this:

https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
pc
sr. member
Activity: 253
Merit: 250
January 07, 2013, 12:08:56 PM
#6
My bad. That isn't strictly necessary. I just wanted to know if there was a way to make some information public and send the coins to the discoverer.
Sure. Just have them be searching for the private key that controls the funds. There have been a couple contests similar to that on these boards, though I don't have the time to dig them all up right now.
newbie
Activity: 20
Merit: 1
January 07, 2013, 11:56:26 AM
#5
Your scripts look like you're trying to require both a private key and a password.

My bad. That isn't strictly necessary. I just wanted to know if there was a way to make some information public and send the coins to the discoverer.


Even without the race condition issues (you could give it directly to a trusted miner), such transactions have the problem that if anyone guesses it's a password protected output they can try to brute force it. Many users would select weak passwords that were too short to withstand brute forcing and lose their money. It's not a good idea to encourage such usage patterns.


In some scenarios I had in mind, as long as the correct answer is given, it wouldn't be so important to have brute force attacks. The coins would not be supposed to be for someone in particular, but for anyone who could give the answer and made it public. Anyway, to prevent dictionary attacks I thought you could add some salt, like in password checking in computers.

Take for instance a "computational race" similar to mining. You could give a prize to whomever found first a string with a hash between two values (a given header, like in mining). With script, it seems you could do it.

I was also thinking in solutions to problems that are hard to compute, but also easy to check (like NP problems). You could offer a reward for a solution which checks right. You wouldn't mind brute force attacks, in fact you would encourage them.

Anyway, if nonstandard script is used, I guess you need trusted miners anyway. I was just curious if you could do this kind of thing with minimal trust, using the regular network.

 

 
legendary
Activity: 1526
Merit: 1134
January 07, 2013, 11:40:16 AM
#4
Even without the race condition issues (you could give it directly to a trusted miner), such transactions have the problem that if anyone guesses it's a password protected output they can try to brute force it. Many users would select weak passwords that were too short to withstand brute forcing and lose their money. It's not a good idea to encourage such usage patterns.
pc
sr. member
Activity: 253
Merit: 250
January 07, 2013, 11:30:10 AM
#3
The other approach for a valid-only-after-releasing-some-information is doing some elliptic curve math to calculate a new address based on your public key and the secret. This is the approach used by LBAAT, which provides a service to future-time-lock a transaction assuming that you trust their promise to release their key at the appropriate time.
pc
sr. member
Activity: 253
Merit: 250
January 07, 2013, 11:13:52 AM
#2
Your scripts look like you're trying to require both a private key and a password. As you said, an intermediary or miner could get the password and try to do something with it before the transaction gets in a block, and of course you'd only want to use that "address" once.

But if you're trying to require knowing two things, then you're probably better off just doing a 2-of-2 multisig transaction. And if you want one of the keys to be something short and memorable (to do something similar to a 2-factor auth, I guess) but not intended to be used on its own, just have the second key be the SHA256(password). That is, have a traditional random private key, which is stored on your computer, and use the hash of your password as the second private key, and require both keys to spend the transaction. That way, the password won't be in the clear in transit (since you're just "signing" using it), and it fits a "standard" transaction type so it'll be easier to relay and get into a block.
newbie
Activity: 20
Merit: 1
January 07, 2013, 10:48:30 AM
#1
Using script you could, in principle, use password-based transactions, where only someone who knows a password can spend the coins. A hash would mask the password in the input transaction.

I expect a code like:

Code:
scriptPubKey: OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
scriptSig:

would be enough. I asked if this was possible (http://bitcoin.stackexchange.com/questions/5510/password-based-bitcoin-transactions) and was pointed out that it is not so secure. An intermediate relaying node that sees the transaction could try to outrun the legitimate spender and spend the coins.

Does anyone know how risky this is or if there are any ways to improve the system? My original idea was having a simple "contract" that transfers the coins only if certain information is made public (think for instance about an on-line contest). So the alternative should preserve the public part.

I have recently found a similar problem when discussing quantum computers, or, more generally, what happens if there appears an algorithm that can deduce the private key from the public key of a user.

https://bitcointalksearch.org/topic/quantum-computers-and-bitcoin-133425

If you use addresses, the hashing will reduce the attacks to the equivalent of the password transaction I mention and is also relevant to the robustness of the Bitcoin system as a whole.


Jump to: