Topic: Using alphabet/number beads for private keys (Read 3628 times)
Here's a sample one I made. The mini key is just a bunch of random characters. I just used put uppercase letters. The lower case letters is done with a slightly smaller bead with a darker shade.
There is no reason beads on a metal string wouldn't last a millennium through fire, flood, locusts, revolution, and solar storm. But would bitcoin last through all that? Paper packs the most bang for the buck.
The numbers on beads would scare me...if the chain breaks and the letters fall to the floor, the bitcoins evaporate.
A piece of paper wouldn't bother me much. Sure, paper fades, but I believe that means that whites turn yellow and color fidelity is lost, not that perfectly good documents turn into blank paper again.
I released an open-source utility (Casascius Bitcoin Utility) that allows you to compute the Bitcoin address that corresponds to any phrase in SHA256. It's for Windows. You must use a complex phrase for it to be secure. You can print it on paper, engrave it on metal, or whatever else you want. I sell a gold bar object (as OP knows), you could use a hand engraver to engrave a passphrase onto the back of it, then it would be clear that the object is bitcoins.
A piece of paper wouldn't bother me much. Sure, paper fades, but I believe that means that whites turn yellow and color fidelity is lost, not that perfectly good documents turn into blank paper again.
I released an open-source utility (Casascius Bitcoin Utility) that allows you to compute the Bitcoin address that corresponds to any phrase in SHA256. It's for Windows. You must use a complex phrase for it to be secure. You can print it on paper, engrave it on metal, or whatever else you want. I sell a gold bar object (as OP knows), you could use a hand engraver to engrave a passphrase onto the back of it, then it would be clear that the object is bitcoins.
This. Paper still seems more reliable than beads on a string. I can read perfectly fine some 50-year old notebooks. As for engraving, I'd never share my private keys with any engraving business. I don't need anything fancy, but I do need something functional and robust. As in a sheet of metal, and some sharp, hardened tool.
Finally, you could just store bitcoins in your head. That's the last thing you would lose anyway.
was completely unaware that a private key gives away the public address
That is not a feature of public key cryptography in general, but a feature of elliptic keys specifically. Elliptic keys have some remarkable properties, some of which might be considered negative side effects depending on your requirements, but one of the best features is their compact size to strength.
the key is not just a key in real life terms it's also full access to the safe where the valuables are stored so perhaps key is a confusing term - it's basically open sesame to the vault
You could think of the private elliptic key as a master locking and unlocking key, while the public keys are locking only. But analogies aside, if you plan to play with the private keys, it's best to just know that the public key is easily obtained from the private key. Maybe you could imagine the private key contains the public key.
EDIT: Actually, come to think of it, while the discussion has been poetically correct thus far, I think the analogies should shift gears. We're really not 'locking' anything (well...), we're really 'signing'. It's based on the same technologies, with a few simple intermediate steps, but the analogies require some re-work.
if you send some Btc out from [from an address in a local wallet] the rest [change] don't just sit there but do some relocation which means you may end up loosing them unless you have [backed up your keys frequently]
I have certain philosophical issues with the local reference 'Satoshi' client, but rest assured you are already well ahead of the learning curve. The Satoshi client doesn't really let you do very much. It doesn't expose the guts of cryptography, so you're not likely to learn how bitcoin works by using the client, but on the other hand, you can't screw up too badly. I don't think much if any user testing has been performed, so the default user experience is something akin to a straight jacket.
When you send bitcoins, the client will collect one or more addresses that contain coins and send the total to one or two addresses. If the total coins in the set of sending addresses is exactly equal to the number of coins you want to send, then voila the total is sent to your destination. However, if the total sending coins is larger, the difference (spare change) is sent to a new address in your local wallet. If you did not have any spare addresses, the address, public, and private keys will be generated automatically.
This is supposed to increase security/anonymity, but I agree, all it really manages to do is confuse new users and increases the possibility of loss. On the bright side, your wallet generally always has a buffer pool of 100 extra pre-generated addresses. So, if you backed up last week and you have not made 100 transactions in the meantime, then your backup from last week is still good. If on the other hand, you sent 102 transactions since your last backup and your harddrive catches on fire and falls into a soup of acid, you'll likely lose the entirety of the change of your last few transactions.
There are some working experiments with a 'deterministic wallet', which can generate an infinite series of private keys from a single seed. I understand this works well, with different, but respected security implications. I expect we'll see smaller, safer, deterministic wallets in the near future. In the mean time, back up often. But I don't think you should be worried about using the Satoshi client. Your questions indicate that you're more advanced than the average user.
I'm not trying to brute force a key. Just the order of the 21 beads. So factorial is correct.
That makes sense. And hopefully in such a case, one or more of the characters gets repeated, which would cut it down a bit more.
Print on paper ... then laminate. It will last a lifetime.
just get a tattoo.
I'd assumed they were like a lock (public address) & a key (private key)
Yeah. Here's a magical analogy for public key cryptography: I generate a private key and numerous public unlocked treasure chests. I give these open treasure chests to all of my friends (it's easy to copy them). Whenever a friend wants to send me a message, they just put the message in my public treasure chest and close the lid. Now even they can not open it again. Only I, with my unique private key, can open the chest.
After I generated the public keys, I don't really need them any more, unless I want to send messages to myself. But no one needs the private key to lock a message. The private key is only required to open a message.
OK I think I get that, but I still don't follow exactly how bitcoins works in practice, I can send them to various bit coin addresses easily via the exchanges that hold them & so they use their private keys to do this but never having risked my own wallet I don't have experience in doing this & was completely unaware that a private key gives away the public address, i.e. the key is not just a key in real life terms it's also full access to the safe where the valuables are stored so perhaps key is a confusing term - it's basically open sesame to the vault
Another reason, apart from this one that I didn't even know about, for not starting a wallet yet is that I haven't been able to master the weirdness of if you send some Btc out from it the rest don't just sit there but do some relocation which means you may end up loosing them unless you have looked very deeply in to how this all works & realise that your backed up wallet is now obsolete as it gets reinvented ever time you do a transaction - I'm prob wrong on this exactly but it's my general impression of how it may work & reflects maybe the confusion of other new adapters to Bitcoin world
I've managed to master very fast how to loose vast amounts on Bitcoinica though - go me!
wow I am shocked that I've never come across this, private key is all you need to access any funds linked to it, for a non techy this is not at all intuitive, thank goodness my intuition has kept me away from managing my own wallet as yet because this is such a fatal flaw in my understanding
edit: haven't read the last 2 replys here yet as my keyboard is playing up & makes things slow atm...
edit: haven't read the last 2 replys here yet as my keyboard is playing up & makes things slow atm...
If you used a 22 chars mini private key and that happens, how long would it take to brute force the right key. Since it starts with S, you have 21 characters to try. So 21! or 5.1 × 10^19. How long would that take?
Factorial is the wrong operation. A base58 mini private key of 22 characters would be more like 58^21, or 1.08 x 10^37.
I'm not trying to brute force a key. Just the order of the 21 beads. So factorial is correct.
One solution to the bead string breaking and leaving you a mess is to just include a piece of paper with the mini key on it. Put both together in a bank safe. If the bead string breaks somehow, you still have the paper backup. And if the paper/ink fades, you will have the beads backup.
I'd assumed they were like a lock (public address) & a key (private key)
Yeah. Here's a magical analogy for public key cryptography: I generate a private key and numerous public unlocked treasure chests. I give these open treasure chests to all of my friends (it's easy to copy them). Whenever a friend wants to send me a message, they just put the message in my public treasure chest and close the lid. Now even they can not open it again. Only I, with my unique private key, can open the chest.
After I generated the public keys, I don't really need them any more, unless I want to send messages to myself. But no one needs the private key to lock a message. The private key is only required to open a message.
Factorial is the wrong operation. A base58 mini private key of 22 characters would be more like 58^21, or 1.08 x 10^37.
Factorial is correct if using a non-repeating permutation, such as the shuffled deck of cards or beads.
If you used a 22 chars mini private key and that happens, how long would it take to brute force the right key. Since it starts with S, you have 21 characters to try. So 21! or 5.1 × 10^19. How long would that take?
Factorial is the wrong operation. A base58 mini private key of 22 characters would be more like 58^21, or 1.08 x 10^37.
ah thanks for explaining I never even suspected it's like looking in to the rabbit hole I guess, also I'm not sure if I've got this bit yet:
that the public key (&/or?) address can be found (derived) from any private key, I'd assumed they were like a lock (public address) & a key (private key), that you needed to know both & which went together in order to send funds but now am seem to hear that if you have a private key you also own the public address even if itit hasn't been given.
that the public key (&/or?) address can be found (derived) from any private key, I'd assumed they were like a lock (public address) & a key (private key), that you needed to know both & which went together in order to send funds but now am seem to hear that if you have a private key you also own the public address even if itit hasn't been given.
Correct.
Computing public key from a private key is trivially easy (as in millionths of a second). Computing private key from public key can't currently be brute forced.
In cryptography we call that a trapdoor functions.
Private Key -> Public Key = trivial
Public Key -> Private Key = computationally infeasible.
In Bitcoin you actually have an intermediate step but it follows the same logic.
Private Key -> Public Key = trivial
Public Key -> Public Address = trivial
thus
Private Key -> Public Address = trivial
Public Key -> Private Key = computationally infeasible.
Public Address -> Public Key = also computationally infeasible.
If you used a 22 chars mini private key and that happens, how long would it take to brute force the right key. Since it starts with S, you have 21 characters to try. So 21! or 5.1 × 10^19. How long would that take?
About 317 years with a single processor running at a billion checks per second.
But of course, machines will get faster and faster throughout that time, so I don't know, you could probably retrieve your bitcoins before you die.
The good news is if you had funds linked to a 22 digit private key as computers get faster you could move them when the timeframe to compromise became measured in years instead of centuries. Moving to a 30 digit private key would increase the timeframe by a factor of 256x (i.e. if a 22 digit mini-private key could be broken on average in 10 years it would take 2560 years to break a 30 digit one).
.. it hasn't been given to you
keyboard batteries seem about to give up may have to post later though seems just got some juice left...
keyboard batteries seem about to give up may have to post later though seems just got some juice left...
ah thanks for explaining I never even suspected it's like looking in to the rabbit hole I guess, also I'm not sure if I've got this bit yet:
that the public key (&/or?) address can be found (derived) from any private key, I'd assumed they were like a lock (public address) & a key (private key), that you needed to know both & which went together in order to send funds but now am seem to hear that if you have a private key you also own the public address even if
that the public key (&/or?) address can be found (derived) from any private key, I'd assumed they were like a lock (public address) & a key (private key), that you needed to know both & which went together in order to send funds but now am seem to hear that if you have a private key you also own the public address even if
...the reason the public key is not used directly is so that the algorithm can be changed in the future...
that, and the public key is ridiculously long, over three times the length of a bitcoin address.
I'm hoping the firstbits becomes the 'standard' address... thus I've wondered if the hash is really a necessary middle-abstraction. We can convert the public key to base36 and refer to the firstbits (or ~10 character prefix before confirmation). Of course, that's probably too late now.
There are three good reasons for not using public key directly.
1) Since public key of a previously unused private key is unknown to an attacker it is IMMUNE to Quantum Cryptography and Shor's algorithm. Shor's algorithm can vastly speed up attacks on public keys but it requires knowledge of public key. Either Satoshi was very lucky or he was a genious because the method he uses provides significant resistance to even quantum computing attacks.
2) If ECC became compromised having addresses decoupled from private key allows a seemless transistion to new encryption methods while still allowing legacy addresses to exist. For example address begins w/ 1 = based on ECC public key. Address begins with 2 = based on alternate private key system. As long as client understands both 1 & 2 it can seamlessly deal w/ dual encryption algorithms.
3) Sending funds directly to public address would be error prone. Leave one digit off the end (or reverse a digit) = oops you sent funds to nowhere. Being irreversable they are lost forever. The bitcoin public addresss has a 32bit checksum in it. That makes the odds of accidentally typing a valid but wrong address roughly 1 in 4 billion. If you left one digit off end of a Bitcoin address you have a 4 billion to once chance that the client will simply say "invalid address" rather than send your funds to "nowhere".
If you used a 22 chars mini private key and that happens, how long would it take to brute force the right key. Since it starts with S, you have 21 characters to try. So 21! or 5.1 × 10^19. How long would that take?
About 317 years with a single processor running at a billion checks per second.
But of course, machines will get faster and faster throughout that time, so I don't know, you could probably retrieve your bitcoins before you die.
The numbers on beads would scare me...if the chain breaks and the letters fall to the floor, the bitcoins evaporate.
If you used a 22 chars mini private key and that happens, how long would it take to brute force the right key. Since it starts with S, you have 21 characters to try. So 21! or 5.1 × 10^19. How long would that take?
sry - I'm getting lost trying to get my head round this, I assumed that the public key was the btc address
No problem it is confusing the first time for everyone.
You start with a private key. It is simply a random number (an integer) that is between 0 and 2^256 (two raised to the 256th) in other words a 256 bit number. 2^256 ~= 1.15792E77 (1 with 77 zeroes behind it).
Now since private key as a number is long, difficulty to copy, easy to make errors, etc we take that number and convert it into wallet import format which is in base-58 begins and has a checksum.
From the raw PRIVAE KEY we use Elliptical Curve Cryptography to generate a PUBLIC KEY. Now the PUBLIC KEY is also long, easy to make errors, difficulty to copy so we take a hash of it, add a checksum, and prefix a 1. That is the address.
So simplified
PRIVATE KEY = 256bit random number
PRIVATE KEY -> ECC = PUBLIC KEY
PRIVATE KEY -> Base 58 formatting w/ checksum = Wallet Import Format
PUBLIC KEY -> hash w/ checksum in base 58 formatting = PUBLIC ADDRESS
Jump to: