Talk:Mini private key format
I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. Willphase 14:15, 25 September 2011 (GMT)
- The original private key has 256bits of entropy, not 160, hasn't it? (I don't know why the current wiki page compares it with 160 bits) --T X 20:03, 27 November 2011 (GMT)
Application
When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.
Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.
In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?
Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --T X 00:44, 10 November 2011 (GMT)
- The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.
- Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. Casascius 03:32, 10 November 2011 (GMT)
Purpose of appending the '?' for determining algorithm?
At first I was wondering why this should be appended, why not just checking the first byte of SHA256 of the minikey as is. The reason I now could think of is that you don't want someone to be able to tell whether a bitcoin private key was generated from a minikey. Is that a good or a bad thing? Is that the main reason? Are there any other reasons? Maybe such reasons should be explained on the wiki page? --T X 16:32, 26 November 2011 (GMT)
Terminology
For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --T X 00:44, 10 November 2011 (GMT)
- I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. Casascius 03:32, 10 November 2011 (GMT)
- True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?
- But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?
- --T X 04:19, 25 November 2011 (GMT)
- Hm, after some more thoughts, I think I might be able to partially answer this to myself: If I were receiving a minikey from an untrusted/unknown party, the minikey is pretty much worthless anyway due to not being able to verify that it is a valid minikey until getting access to a computer. As you said before, if it is a known, public party then I can usually get information probably somewhere online about the used algorithm at any time. If it is a trusted but non-public party I want to get a minikey from then the my trusting that the other party chose a good minikey algorithm is marginal compared to my already given trust in the other party that they have generated a valid minikey in general.
- Now there's just one scenario left I can come up with: I might have obtained lots of minikeys from trusted, non-public parties which I had all put in my piggy bank at home. Now, five years later some issues came up with certain minikey algorithms which suggests anyone having such minikeys to redeem the value as soon as possible. If only about 5% of the minikeys in my piggy bank were using the broken minikey algorithm, I'd still have to copy and check all of them on my computer.
- Maybe the conclusion could be that you shouldn't save 'anonymous' minikeys (if any due to the lower entropy). Don't know. --T X 15:25, 26 November 2011 (GMT)
Adding a Reserved Minikey Version Character?
What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).
Advantages:
- Selected algorithm visibility / minikey 'strength' visibility
- Easy Extensibility
For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --T X 04:18, 25 November 2011 (GMT)
Entropy Considerations
The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?
"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --T X 00:44, 10 November 2011 (GMT)
- Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. Casascius 03:32, 10 November 2011 (GMT)
PBKDF2
HMAC-SHA1 or HMAC-SHA256?
Is HMAC−SHA1 or HMAC−SHA256 being used? --T X 01:01, 10 November 2011 (GMT)
- I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. Casascius 03:32, 10 November 2011 (GMT)
- Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of Ian Grigg's hypotheses. --T X 04:18, 25 November 2011 (GMT)
Use exponential rounds encoding
With the values from 0x0128 to 0x01FF being reserved about another 7.75 Bits (log2 (0xFF - 0x27)) of entropy would be lost. I don't think that for instance very similar number of rounds are needed. Instead the number of rounds could be encoded exponentially and reserved in less bits. For instance:
- (SHA256 & 0xFF03) == 0x0100 -> 4096 rounds
- (SHA256 & 0xFF03) == 0x0101 -> 8192
- (SHA256 & 0xFF03) == 0x0102 -> 16384
- (SHA256 & 0xFF03) == 0x0103 -> 32768
This would only remove about 2 instead of the 7.75Bits of entropy. --T X 16:11, 26 November 2011 (GMT)
Tagging Stable Versions
Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --T X 04:18, 25 November 2011 (GMT)
More specific applications for simple SHA256 minikeys
"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"
Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?
If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.
I saw that you, Casascius, were playing with POS systems: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --T X 04:18, 25 November 2011 (GMT)
(Probably) Finished Discussions
Python Code
What was the "additionalSecurity" flag supposed to do? It seems unused. --T X 00:44, 10 November 2011 (GMT)
- It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. Casascius 03:32, 10 November 2011 (GMT)
- Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --T X 22:31, 20 November 2011 (GMT)
717 round SHA256
Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --T X 00:44, 10 November 2011 (GMT)