User:Casascius/Base58Check-encoded objects proposal - Revision history

Casascius: /* Proposed encoding for a passphrase-protected private key */

2012-11-11T18:23:36Z

Proposed encoding for a passphrase-protected private key

@@ Line 83: / Line 83: @@
 ** Highest possible value: 5PeX7NoBdjbffU8PkwJtx1YSxwg5AFPi5jH6xd7SDqsoeMcxpoG
 * Note: By using 0x82 instead of 0x81 we ensure the second character always visually divulges the compressed status.  If we used 0x81, then the prefix '5K' could belong to either, and would be ambiguous.
 ==Proposed specification for a multi-part key using EC multiplication==

Casascius: /* Example/Test Vector */

2012-08-13T03:15:11Z

Example/Test Vector

← Older revision		Revision as of 03:15, 13 August 2012
Line 127:		Line 127:
	===Example/Test Vector===		===Example/Test Vector===
	* Passphrase: "VIRES IN NUMERIS"		* Passphrase: "VIRES IN NUMERIS"
	* Sample Bitcoin private key: 5Ki8KQ65ihzzoex9BjarbMjUATaFYMmWZ4eLmBnjj9fdhKqm3VR / F967E2BEEFCEC703A4737E42124D7BB3 34A34CC345446B9B163576B7C7A36266		* Sample Bitcoin private key to be encrypted: 5Ki8KQ65ihzzoex9BjarbMjUATaFYMmWZ4eLmBnjj9fdhKqm3VR / F967E2BEEFCEC703A4737E42124D7BB3 34A34CC345446B9B163576B7C7A36266

	* SHA256("VIRES IN NUMERIS"): 8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD		* SHA256("VIRES IN NUMERIS"): 8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD
	* AES256Encrypt(F967E2BEEFCEC703A4737E42124D7BB3,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = b5dde5769a8b031139cdcc54f2f5f98b		* AES256Encrypt(F967E2BEEFCEC703A4737E42124D7BB3,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = b5dde5769a8b031139cdcc54f2f5f98b
Line 134:		Line 135:
	* First 16 bits of SHA256("VIRES IN NUMERIS?"): B2C4, and 0x7ffe = 0x32c4		* First 16 bits of SHA256("VIRES IN NUMERIS?"): B2C4, and 0x7ffe = 0x32c4
	* What to [[Base58Check]] encode: 0205 32C4 b5dde5769a8b031139cdcc54f2f5f98b 8b899125ebf86b82a54fb898077188f6		* What to [[Base58Check]] encode: 0205 32C4 b5dde5769a8b031139cdcc54f2f5f98b 8b899125ebf86b82a54fb898077188f6
	* ~~End result~~: 6ph7B7aqL4aBkQY2sJs8MZdJ1MwjEJSgLDiRoBrqAXsAbjmdQecEi3		* Resulting encrypted private key: 6ph7B7aqL4aBkQY2sJs8MZdJ1MwjEJSgLDiRoBrqAXsAbjmdQecEi3

	==Proposed specification for a multi-part key using EC multiplication==		==Proposed specification for a multi-part key using EC multiplication==

Casascius: /* Example/Test Vector */

2012-08-13T02:52:27Z

Example/Test Vector

← Older revision		Revision as of 02:52, 13 August 2012
Line 127:		Line 127:
	===Example/Test Vector===		===Example/Test Vector===
	* Passphrase: "VIRES IN NUMERIS"		* Passphrase: "VIRES IN NUMERIS"
	* Sample Bitcoin private key: 5Ki8KQ65ihzzoex9BjarbMjUATaFYMmWZ4eLmBnjj9fdhKqm3VR / ~~F967E2BEEFCEC703A4737E42124D7BB334A34CC345446B9B163576B7C7A36266~~		* Sample Bitcoin private key: 5Ki8KQ65ihzzoex9BjarbMjUATaFYMmWZ4eLmBnjj9fdhKqm3VR / F967E2BEEFCEC703A4737E42124D7BB3 34A34CC345446B9B163576B7C7A36266
	* SHA256("VIRES IN NUMERIS"): 8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD		* SHA256("VIRES IN NUMERIS"): 8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD
	* AES256Encrypt(F967E2BEEFCEC703A4737E42124D7BB3,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = b5dde5769a8b031139cdcc54f2f5f98b		* AES256Encrypt(F967E2BEEFCEC703A4737E42124D7BB3,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = b5dde5769a8b031139cdcc54f2f5f98b
Line 133:		Line 133:
	* AES256Encrypt(817EA9B5DFCF688A2FF8BAE335569BED,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = 8b899125ebf86b82a54fb898077188f6		* AES256Encrypt(817EA9B5DFCF688A2FF8BAE335569BED,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = 8b899125ebf86b82a54fb898077188f6
	* First 16 bits of SHA256("VIRES IN NUMERIS?"): B2C4, and 0x7ffe = 0x32c4		* First 16 bits of SHA256("VIRES IN NUMERIS?"): B2C4, and 0x7ffe = 0x32c4
	* What to Base58Check encode: 0205 32C4 b5dde5769a8b031139cdcc54f2f5f98b 8b899125ebf86b82a54fb898077188f6		* What to [[Base58Check]] encode: 0205 32C4 b5dde5769a8b031139cdcc54f2f5f98b 8b899125ebf86b82a54fb898077188f6
	* End result: 6ph7B7aqL4aBkQY2sJs8MZdJ1MwjEJSgLDiRoBrqAXsAbjmdQecEi3		* End result: 6ph7B7aqL4aBkQY2sJs8MZdJ1MwjEJSgLDiRoBrqAXsAbjmdQecEi3

Casascius: /* Proposed specification */

2012-08-13T02:51:04Z

Proposed specification

← Older revision		Revision as of 02:51, 13 August 2012
Line 124:		Line 124:

	The valid range of the passphrase typo resistance bytes are 0x0000 thru 0x8001. Values above 0x8001 are excluded from the definition of keys valid for this proposal. Note that if the value were to be above 0xabb9, the prefix "6p" is lost and becomes "6q".		The valid range of the passphrase typo resistance bytes are 0x0000 thru 0x8001. Values above 0x8001 are excluded from the definition of keys valid for this proposal. Note that if the value were to be above 0xabb9, the prefix "6p" is lost and becomes "6q".

			===Example/Test Vector===
			* Passphrase: "VIRES IN NUMERIS"
			* Sample Bitcoin private key: 5Ki8KQ65ihzzoex9BjarbMjUATaFYMmWZ4eLmBnjj9fdhKqm3VR / F967E2BEEFCEC703A4737E42124D7BB334A34CC345446B9B163576B7C7A36266
			* SHA256("VIRES IN NUMERIS"): 8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD
			* AES256Encrypt(F967E2BEEFCEC703A4737E42124D7BB3,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = b5dde5769a8b031139cdcc54f2f5f98b
			* 34A34CC345446B9B163576B7C7A36266 xor b5dde5769a8b031139cdcc54f2f5f98b = 817EA9B5DFCF688A2FF8BAE335569BED
			* AES256Encrypt(817EA9B5DFCF688A2FF8BAE335569BED,8967A8562255672471ACB316E705593454040FA41E3883AD5A8C3576E5DC03DD) = 8b899125ebf86b82a54fb898077188f6
			* First 16 bits of SHA256("VIRES IN NUMERIS?"): B2C4, and 0x7ffe = 0x32c4
			* What to Base58Check encode: 0205 32C4 b5dde5769a8b031139cdcc54f2f5f98b 8b899125ebf86b82a54fb898077188f6
			* End result: 6ph7B7aqL4aBkQY2sJs8MZdJ1MwjEJSgLDiRoBrqAXsAbjmdQecEi3

	==Proposed specification for a multi-part key using EC multiplication==		==Proposed specification for a multi-part key using EC multiplication==

Casascius: /* Proposed encoding for a passphrase-protected private key */

2012-08-12T23:47:53Z

Proposed encoding for a passphrase-protected private key

← Older revision		Revision as of 23:47, 12 August 2012
Line 95:		Line 95:
	The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.		The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.

	To encrypt the key requires the AES256Encrypt function, which takes a 16-byte input and a 32-byte key and yields a 16-byte output. Encryption is: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase)) + AES256Encrypt(bitcoinprivkey[16...31], SHA256(passphrase)). Decryption is the ~~same~~, ~~except using~~ AES256Decrypt ~~instead~~. ~~No block chaining or~~ initialization vectors are used.		To encrypt the key requires the AES256Encrypt function, which takes a 16-byte input and a 32-byte key and yields a 16-byte output. The SHA256 hash of the passphrase is used as the 32-bit key given to the AES functions.

			Encryption is:
			* firsthalf: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase))
			* lasthalf: AES256Encrypt(bitcoinprivkey[16...31] xor firsthalf[0...15], SHA256(passphrase))

			Decryption is the reverse:
			* firsthalf: AES256Decrypt(ciphertext[0...15], SHA256(passphrase))
			* lasthalf: AES256Decrypt(ciphertext[16...31], SHA256(passphrase)) xor firsthalf[0...15]

			To keep the size of the encrypted key down, no initialization vectors are used.

	===Proposed specification===		===Proposed specification===
Line 103:		Line 113:
	* Count of payload bytes (beyond prefix): 34		* Count of payload bytes (beyond prefix): 34
	** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)		** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)
	**32 bytes: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase)) + AES256Encrypt(bitcoinprivkey[16...31], SHA256(passphrase))		**16 bytes: firsthalf: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase))
			**16 bytes: lasthalf: AES256Encrypt(bitcoinprivkey[16...31] xor firsthalf, SHA256(passphrase))
	* Range in base58check encoding:		* Range in base58check encoding:
	** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp		** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp

Casascius: /* Proposed encoding for a passphrase-protected private key */

2012-08-12T23:18:07Z

Proposed encoding for a passphrase-protected private key

← Older revision		Revision as of 23:18, 12 August 2012
Line 95:		Line 95:
	The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.		The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.

	To encrypt the key requires the AES256Encrypt function, which takes a 32-byte input and a 32-byte key and yields a 32-byte output. Encryption is: AES256Encrypt(bitcoinprivkey, SHA256(passphrase)). Decryption is the same, except using AES256Decrypt instead.		To encrypt the key requires the AES256Encrypt function, which takes a 16-byte input and a 32-byte key and yields a 16-byte output. Encryption is: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase)) + AES256Encrypt(bitcoinprivkey[16...31], SHA256(passphrase)). Decryption is the same, except using AES256Decrypt instead. No block chaining or initialization vectors are used.

	===Proposed specification===		===Proposed specification===
Line 103:		Line 103:
	* Count of payload bytes (beyond prefix): 34		* Count of payload bytes (beyond prefix): 34
	** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)		** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)
	**32 bytes: AES256Encrypt(bitcoinprivkey, SHA256(passphrase))		**32 bytes: AES256Encrypt(bitcoinprivkey[0...15], SHA256(passphrase)) + AES256Encrypt(bitcoinprivkey[16...31], SHA256(passphrase))
	* Range in base58check encoding:		* Range in base58check encoding:
	** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp		** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp

Casascius: /* Proposed encoding for a passphrase-protected private key */

2012-08-12T21:43:32Z

Proposed encoding for a passphrase-protected private key

← Older revision		Revision as of 21:43, 12 August 2012
Line 89:		Line 89:
	This proposal contemplates existence of a private key that requires a decryption passphrase before it can be used.		This proposal contemplates existence of a private key that requires a decryption passphrase before it can be used.

	I propose having the Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could include keys participating in multisig transactions. The second character ought to give a hint as to what is needed, and for ~~a simple SHA256~~-based ~~password~~, I propose the lowercase letter p.		I propose having the Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could include keys participating in multisig transactions. The second character ought to give a hint as to what is needed, and for an AES256-encoded key based on the SHA256 hash of a passphrase, I propose the lowercase letter p.

	I propose the string having an optional 14 bits of password typo resistance. That is, a 14-bit checksum of the password may be added so that the vast majority of password typos can be detected and reported to the user, rather than inadvertently accepted as correct, which will simply yield the wrong private key and frustrate the user. This checksum is optional, and a bit flag is defined for the purpose of disabling it.		I propose the string having an optional 14 bits of password typo resistance. That is, a 14-bit checksum of the password may be added so that the vast majority of password typos can be detected and reported to the user, rather than inadvertently accepted as correct, which will simply yield the wrong private key and frustrate the user. This checksum is optional, and a bit flag is defined for the purpose of disabling it.
Line 95:		Line 95:
	The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.		The choice of a low-bitcount checksum is intended to reduce its usefulness to someone attempting to crack the password.

	To ~~decrypt~~ the key is ~~to simply XOR it with the~~ SHA256 ~~hash of~~ the ~~valid passphrase~~.		To encrypt the key requires the AES256Encrypt function, which takes a 32-byte input and a 32-byte key and yields a 32-byte output. Encryption is: AES256Encrypt(bitcoinprivkey, SHA256(passphrase)). Decryption is the same, except using AES256Decrypt instead.

	===Proposed specification===		===Proposed specification===
Line 103:		Line 103:
	* Count of payload bytes (beyond prefix): 34		* Count of payload bytes (beyond prefix): 34
	** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)		** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)
	**32 bytes: ~~Private key xor~~ SHA256(passphrase)		**32 bytes: AES256Encrypt(bitcoinprivkey, SHA256(passphrase))
	* Range in base58check encoding:		* Range in base58check encoding:
	** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp		** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp

Casascius: /* Proposed specification */

2012-08-03T05:44:28Z

Proposed specification

← Older revision		Revision as of 05:44, 3 August 2012
Line 100:		Line 100:

	* Object identifier prefix: 0x0205		* Object identifier prefix: 0x0205
	* ~~Payload~~ bytes (beyond prefix): 34		* How the user sees it: 54 characters always starting with '6p'
			* Count of payload bytes (beyond prefix): 34
	** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)		** 2 bytes: compressed flag and passphrase typo resistance (1 bit: passphrase enable/disable, 14 bits: passphrase checksum, 1 bit: compressed flag)
	**32 bytes: Private key xor passphrase		**32 bytes: Private key xor SHA256(passphrase)
	* How the user sees it: 54 characters always starting with '6p'
	* Range in base58check encoding:		* Range in base58check encoding:
	** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp		** Minimum value: 6pZbbCzeNu7567y9swhRL8zC4yXioQc6oaUmwPMof6zvChFcMrTmMp

Casascius: /* Abstract */

2012-08-03T05:42:14Z

Abstract

← Older revision		Revision as of 05:42, 3 August 2012
Line 13:		Line 13:
	With the increasing popularity of the use of paper wallets as offline Bitcoin storage, there is a growing demand for ways to make that offline storage more secure, for various reasons of the user's choice. Currently, there exists no straightforward way to encrypt a paper Bitcoin wallet.		With the increasing popularity of the use of paper wallets as offline Bitcoin storage, there is a growing demand for ways to make that offline storage more secure, for various reasons of the user's choice. Currently, there exists no straightforward way to encrypt a paper Bitcoin wallet.

	There is also growing demand for paper wallets that can be split and saved in redundant geographical locations or with different trusted parties. This proposal introduces a standard based on elliptic curve multiplication where Base58Check-encoded strings and/or QR codes can be used to represent parts of a multi-part key. This proposal also introduces a simple standard format for denoting a RAID-like recovery record, so that a multi-part key can be distributed and redeemed in a fashion that tolerates the loss of any one part of the key.		There is also growing demand for paper wallets that can be split and saved in redundant geographical locations or with different trusted parties, or which are generated in individual parts by multiple machines so that no single machine ever has access to the entire private key prior to redemption. This proposal introduces a standard based on elliptic curve multiplication where Base58Check-encoded strings and/or QR codes can be used to represent parts of a multi-part key. This proposal also introduces a simple standard format for denoting a RAID-like recovery record, so that a multi-part key can be distributed and redeemed in a fashion that tolerates the loss of any one part of the key.

	This proposal also seeks to define unique prefixes on Base58Check-encoded strings so that they convey useful visual information to a user, and requests that other developers maintain awareness of the string prefixes and maximize their usefulness to the user.		This proposal also seeks to define unique prefixes on Base58Check-encoded strings so that they convey useful visual information to a user, and requests that other developers maintain awareness of the string prefixes and maximize their usefulness to the user.

Casascius: /* Proposed specification for a RAID-like recovery record for a multi-part key */

2012-08-03T05:33:01Z

Proposed specification for a RAID-like recovery record for a multi-part key

← Older revision		Revision as of 05:33, 3 August 2012
Line 139:		Line 139:
	:'''''User story:''' As a Bitcoin user who uses paper wallets or who imports/exports private keys in parts, I would like the ability to secure my multi-part keys against the potential loss or destruction of one of the parts.''		:'''''User story:''' As a Bitcoin user who uses paper wallets or who imports/exports private keys in parts, I would like the ability to secure my multi-part keys against the potential loss or destruction of one of the parts.''

	I propose a format that isn't ~~actually~~ a key or key part: it is~~, rather,~~ a simple ~~RAID-5-like~~ parity-based recovery record for a multi-part private key, that can be used in place of any one missing part.		I propose a format that isn't itself a key or key part: rather, it is a simple parity-based recovery record for a multi-part private key, that can be used in place of any one missing part. It functions similar to RAID-5 as used in disk technology.

	This format looks similar to a single part of a multi-part key, including the bitmapped fields denoting the number of parts and the checksum of the Bitcoin address, except for a different object identifier prefix. The data payload is a simple XOR sum of the payloads in all of the parts being protected. With that sum, any one missing part can be completely recalculated using standard parity math.		This format looks similar to a single part of a multi-part key, including the bitmapped fields denoting the number of parts and the checksum of the Bitcoin address, except for a different object identifier prefix. The data payload is a simple XOR sum of the payloads in all of the parts being protected. With that sum, any one missing part can be completely recalculated using standard parity math.
Line 149:		Line 149:
	===Proposed specification===		===Proposed specification===
	* Object identifier prefix: 0x0208		* Object identifier prefix: 0x0208
			* How the user sees it: 54 characters always starting with the prefix '6r'
	* Count of payload bytes (beyond the prefix): 34		* Count of payload bytes (beyond the prefix): 34
	* 2 bytes: bit-mapped field, which must be identical to the corresponding 2-byte field in the partial keys to which the recovery record belongs (range of valid values: 0...0x8001)		* 2 bytes: bit-mapped field, which must be identical to the corresponding 2-byte field in the partial keys to which the recovery record belongs (range of valid values: 0...0x8001)
	* 32 bytes: result of XORing the 32 bytes of all of the partial keys		* 32 bytes: result of XORing the 32 bytes of all of the partial keys
	* How the user sees it: 54 characters always starting with the prefix '6r'