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)
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)
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, were a fault in 22-char sha256 keys be found. Casascius 03:32, 10 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
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)
(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)