Skip to content

S
slips
Unverified Commit 40c88470 authored by Pavol Rusnak's avatar Pavol Rusnak
Browse files
Options

markdown lint using travis

parent 107edf5d
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 313 additions and 276 deletions
.travis.yml 0 → 100644
View file @ 40c88470
language: node_js
node_js:
- "node"
before_script:
- npm install -g markdownlint-cli
script:
- markdownlint -c markdownlint.json *.md
README.md
View file @ 40c88470
#SatoshiLabs Improvement Proposals # SatoshiLabs Improvement Proposals
SatoshiLabs projects need a way how to document their technical decisions and features. SatoshiLabs projects need a way how to document their technical decisions and features.
For some of them Bitcoin Improvement Proposal (BIP) is not a right place because For some of them Bitcoin Improvement Proposal (BIP) is not a right place because
......
markdownlint.json 0 → 100644
View file @ 40c88470
{
"MD004": false,
"MD013": false,
"MD029": false,
"MD033": false,
"MD040": false
}
slip-0000.md
View file @ 40c88470
#SLIP-0000 : SLIP Template # SLIP-0000 : SLIP Template
``` ```
Number: SLIP-0000 Number: SLIP-0000
...@@ -9,20 +9,20 @@ Authors: SatoshiLabs <info@satoshilabs.com> ...@@ -9,20 +9,20 @@ Authors: SatoshiLabs <info@satoshilabs.com>
Created: 2014-06-06 Created: 2014-06-06
``` ```
##Abstract ## Abstract
This is a section for an abstract. This is a section for an abstract.
##Motivation ## Motivation
This is a section for a motivation. This is a section for a motivation.
##Body ## Body
This is a section for a body. The title of the section should be changed This is a section for a body. The title of the section should be changed
and the section can be split into multiple sections and subsections. and the section can be split into multiple sections and subsections.
##References ## References
This is a section for references such as links to other documents (BIP or SLIP) This is a section for references such as links to other documents (BIP or SLIP)
or to reference implementations. or to reference implementations.
slip-0010.md
View file @ 40c88470
This diff is collapsed.
slip-0011.md
View file @ 40c88470
#SLIP-0011 : Symmetric encryption of key-value pairs using deterministic hierarchy # SLIP-0011 : Symmetric encryption of key-value pairs using deterministic hierarchy
``` ```
Number: SLIP-0011 Number: SLIP-0011
...@@ -11,17 +11,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com> ...@@ -11,17 +11,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
Created: 2014-06-12 Created: 2014-06-12
``` ```
##Abstract ## Abstract
This document is explaining symmetric encryption on hardware devices, using deterministic hierarchy. This document is explaining symmetric encryption on hardware devices, using deterministic hierarchy.
##Motivation ## Motivation
We want to provide a symmetric encryption in the hardware wallet, where the key doesn't exit the device, and where the user might be forced to confirm the encryption/decryption on the display. We want to provide a symmetric encryption in the hardware wallet, where the key doesn't exit the device, and where the user might be forced to confirm the encryption/decryption on the display.
##Body ## Body
###Overview ### Overview
The following data are sent to the hardware wallet: The following data are sent to the hardware wallet:
...@@ -41,11 +41,11 @@ IV can be either manually set, or it is computed together with the key. ...@@ -41,11 +41,11 @@ IV can be either manually set, or it is computed together with the key.
The value must be divisible into 16-byte blocks. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7. The value must be divisible into 16-byte blocks. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7.
###Details ### Details
The details are best explained on a slightly simplified code from TREZOR Python emulator. The details are best explained on a slightly simplified code from TREZOR Python emulator.
````python ```python
def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_on_decrypt, iv): def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_on_decrypt, iv):
if len(value) % 16 > 0: if len(value) % 16 > 0:
return Failure(message="Input length must be a multiple of 16") return Failure(message="Input length must be a multiple of 16")
...@@ -61,57 +61,57 @@ def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_o ...@@ -61,57 +61,57 @@ def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_o
else: else:
res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)]) res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)])
return CipheredKeyValue(value=res) return CipheredKeyValue(value=res)
```` ```
````python ```python
if len(value) % 16 > 0: if len(value) % 16 > 0:
return Failure(message="Input length must be a multiple of 16") return Failure(message="Input length must be a multiple of 16")
```` ```
First, the value is checked, if it is divisable into 16-byte blocks, since the symmetric cipher is block cipher. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7. First, the value is checked, if it is divisable into 16-byte blocks, since the symmetric cipher is block cipher. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7.
````python ```python
private_key = BIP32(self.storage.get_node()).get_private_node(list(address_n)).private_key private_key = BIP32(self.storage.get_node()).get_private_node(list(address_n)).private_key
```` ```
Private key of the BIP32 node is derived. Private key of the BIP32 node is derived.
````python ```python
key += "E1" if ask_on_encrypt else "E0" key += "E1" if ask_on_encrypt else "E0"
key += "D1" if ask_on_decrypt else "D0" key += "D1" if ask_on_decrypt else "D0"
```` ```
The key, displayed on the device, is concatenated with either E1 or E0 and either D1 or D0, depending on whether the confirmation is enabled in a given direction. The key, displayed on the device, is concatenated with either E1 or E0 and either D1 or D0, depending on whether the confirmation is enabled in a given direction.
````python ```python
secret = hmac.HMAC(key=private_key, msg=key, digestmod=hashlib.sha512).digest() secret = hmac.HMAC(key=private_key, msg=key, digestmod=hashlib.sha512).digest()
```` ```
The key, with the concatenated E1/E0 or D1/D0, is HMACed, with the private key from HD Node, with SHA512 as a hash function. The key, with the concatenated E1/E0 or D1/D0, is HMACed, with the private key from HD Node, with SHA512 as a hash function.
````python ```python
aes_key = secret[0:32] aes_key = secret[0:32]
aes_iv = iv if iv else secret[32:48] aes_iv = iv if iv else secret[32:48]
```` ```
The AES key is the first 32 bytes of the HMAC; the input vector is the next 16 bytes. The AES key is the first 32 bytes of the HMAC; the input vector is the next 16 bytes.
````python ```python
aes = pyaes.AESModeOfOperationCBC(key=aes_key, iv=aes_iv) aes = pyaes.AESModeOfOperationCBC(key=aes_key, iv=aes_iv)
```` ```
The algorithm is AES, in CBC mode. The algorithm is AES, in CBC mode.
````python ```python
if encrypt: if encrypt:
res = ''.join([aes.encrypt(value[i:i+16]) for i in range(0, len(value), 16)]) res = ''.join([aes.encrypt(value[i:i+16]) for i in range(0, len(value), 16)])
else: else:
res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)]) res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)])
```` ```
The result are the encrypted/decrypted blocks, concatenated together. The result are the encrypted/decrypted blocks, concatenated together.
##References ## References
The algorithm is implemented in [TREZOR firmware](https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c) (function `fsm_msgCipherKeyValue`) and its [emulator](https://github.com/trezor/trezor-emu/blob/master/trezor/machine.py#L781) (function `_cipher_keyvalue`). The algorithm is implemented in [TREZOR firmware](https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c) (function `fsm_msgCipherKeyValue`) and its [emulator](https://github.com/trezor/trezor-emu/blob/master/trezor/machine.py#L781) (function `_cipher_keyvalue`).
......
slip-0012.md
View file @ 40c88470
#SLIP-0012 : Public key encryption using deterministic hierarchy # SLIP-0012 : Public key encryption using deterministic hierarchy
``` ```
Number: SLIP-0012 Number: SLIP-0012
...@@ -10,20 +10,20 @@ Authors: Pavol Rusnak <stick@satoshilabs.com> ...@@ -10,20 +10,20 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
Created: 2014-06-12 Created: 2014-06-12
``` ```
##Abstract ## Abstract
This is a section for an abstract. This is a section for an abstract.
##Motivation ## Motivation
This is a section for a motivation. This is a section for a motivation.
##Body ## Body
This is a section for a body. The title of the section should be changed This is a section for a body. The title of the section should be changed
and the section can be split into multiple sections and subsections. and the section can be split into multiple sections and subsections.
##References ## References
This is a section for references such as links to other documents (BIP or SLIP) This is a section for references such as links to other documents (BIP or SLIP)
or to reference implementations. or to reference implementations.
slip-0013.md
View file @ 40c88470
...@@ -29,9 +29,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]` ...@@ -29,9 +29,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]`
Examples: Examples:
- https://example.com * `https://example.com`
- ftp://public@example.com/pub * `ftp://public@example.com/pub`
- ssh://root@example.com:2222 * `ssh://root@example.com:2222`
b) index (32-bit unsigned integer) b) index (32-bit unsigned integer)
...@@ -52,6 +52,7 @@ The index is used so one can generate more keys corresponding to the same URI. ...@@ -52,6 +52,7 @@ The index is used so one can generate more keys corresponding to the same URI.
6. Derive the HD node `m/13'/A'/B'/C'/D'` according to BIP32. 6. Derive the HD node `m/13'/A'/B'/C'/D'` according to BIP32.
### Worked example ### Worked example
1. `index + uri`=`0` + `https://satoshi@bitcoin.org/login` 1. `index + uri`=`0` + `https://satoshi@bitcoin.org/login`
2. `sha256(index + uri)` = `d0e2389d4c8394a9f3e32de01104bf6e8db2d9e2bb0905d60fffa5a18fd696db` 2. `sha256(index + uri)` = `d0e2389d4c8394a9f3e32de01104bf6e8db2d9e2bb0905d60fffa5a18fd696db`
...@@ -70,15 +71,17 @@ See a [Python example](https://github.com/trezor/python-trezor/blob/ca45019918bc ...@@ -70,15 +71,17 @@ See a [Python example](https://github.com/trezor/python-trezor/blob/ca45019918bc
Service issues the challenge consisting of three parts: Service issues the challenge consisting of three parts:
a) service identity described above (e.g. https://example.com 0) a) service identity described above (e.g. `https://example.com 0`)
b) hidden challenge b) hidden challenge
- random bytes sequence of maximum length 64
- this won't be shown to the user * random bytes sequence of maximum length 64
* this won't be shown to the user
c) visual challenge c) visual challenge
- arbitrary string of text of maximum length 64
- this will be shown to the user and we recommend using timestamp in `YYYY-MM-DD HH:MM:SS` format or similar * arbitrary string of text of maximum length 64
* this will be shown to the user and we recommend using timestamp in `YYYY-MM-DD HH:MM:SS` format or similar
Signer takes this data and computes the private key according to section HD Structure. Signer takes this data and computes the private key according to section HD Structure.
Then it concatenates sha256 hashes of challenge hidden and challenge visual and Then it concatenates sha256 hashes of challenge hidden and challenge visual and
...@@ -93,6 +96,6 @@ It's up to service operator to take this message and react in three possible way ...@@ -93,6 +96,6 @@ It's up to service operator to take this message and react in three possible way
## References ## References
- [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
- [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) * [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)
- [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986) * [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986)
slip-0014.md
View file @ 40c88470
#SLIP-0014 : Stress Test Deterministic Wallet # SLIP-0014 : Stress Test Deterministic Wallet
``` ```
Number: SLIP-0014 Number: SLIP-0014
...@@ -9,19 +9,19 @@ Authors: Pavol Rusnak <stick@satoshilabs.com> ...@@ -9,19 +9,19 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
Created: 2015-01-12 Created: 2015-01-12
``` ```
##Abstract ## Abstract
SLIP-0014 describes a stress test deterministic wallet, which can be used SLIP-0014 describes a stress test deterministic wallet, which can be used
to test various cornercases that such wallet can encounter. to test various cornercases that such wallet can encounter.
##Motivation ## Motivation
During the development of myTREZOR deterministic wallet we realized there During the development of myTREZOR deterministic wallet we realized there
are quite a lot of different types of transactions in the network. In order are quite a lot of different types of transactions in the network. In order
to simplify testing of transaction history we came up with the idea to create to simplify testing of transaction history we came up with the idea to create
a special xpub that will contain these various types of transactions. a special xpub that will contain these various types of transactions.
##xpubs, xprvs, mnemonics, etc. ## mnemonic, xprvs and xpubs
``` ```
mnemonic: all all all all all all all all all all all all mnemonic: all all all all all all all all all all all all
...@@ -37,7 +37,7 @@ xpub6Ex8WCdj1KH5mK9r99QKENUmhpjEPgYm1dJmKY2nxx16tSAiQCVYjHfymFdzfpYDAHGtWYTif7Wk ...@@ -37,7 +37,7 @@ xpub6Ex8WCdj1KH5mK9r99QKENUmhpjEPgYm1dJmKY2nxx16tSAiQCVYjHfymFdzfpYDAHGtWYTif7Wk
[link to blockchain.info](https://blockchain.info/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy) [link to blockchain.info](https://blockchain.info/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy)
##Addresses ## Addresses
index | address | private key index | address | private key
------|------------------------------------|----------------------------------------------------- ------|------------------------------------|-----------------------------------------------------
...@@ -52,7 +52,7 @@ index | address | private key ...@@ -52,7 +52,7 @@ index | address | private key
8 | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM 8 | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM
9 | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs 9 | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs
##Transactions ## Transactions
# | block | transaction id | description # | block | transaction id | description
----|--------|------------------------------------------------------------------|--------------------------------- ----|--------|------------------------------------------------------------------|---------------------------------
...@@ -62,7 +62,7 @@ index | address | private key ...@@ -62,7 +62,7 @@ index | address | private key
4 | 341650 | a831a97917a3ae58a3c0cd700ed7ef08529b8218d3f71ed16152c7898c3d909e | regular outgoing transaction 4 | 341650 | a831a97917a3ae58a3c0cd700ed7ef08529b8218d3f71ed16152c7898c3d909e | regular outgoing transaction
5 | 342246 | f54fae106758ffa17822b0f959f267eb9514b2fd7e15b89a98dad6e319e2af0c | sent to myself (in same account) 5 | 342246 | f54fae106758ffa17822b0f959f267eb9514b2fd7e15b89a98dad6e319e2af0c | sent to myself (in same account)
##References ## References
- [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) - [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
- [BIP-0039: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) - [BIP-0039: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
......
slip-0015.md
View file @ 40c88470
#SLIP-0015 : Format for Bitcoin metadata and its encryption in HD wallets # SLIP-0015 : Format for Bitcoin metadata and its encryption in HD wallets
``` ```
Number: SLIP-0015 Number: SLIP-0015
...@@ -9,12 +9,12 @@ Authors: Karel Bilek <kb@karelbilek.com> ...@@ -9,12 +9,12 @@ Authors: Karel Bilek <kb@karelbilek.com>
Created: 2015-01-12 Created: 2015-01-12
``` ```
##Abstract ## Abstract
SLIP-0015 describes a format to save Bitcoin transaction metadata (labels to accounts, transactions) SLIP-0015 describes a format to save Bitcoin transaction metadata (labels to accounts, transactions)
in a secure way, with regard to HD wallets, especially (but not limited to) hardware HD wallets. in a secure way, with regard to HD wallets, especially (but not limited to) hardware HD wallets.
##Goals ## Goals
In myTREZOR web wallet, we need to save additional metadata, such as account labels or transaction labels. In myTREZOR web wallet, we need to save additional metadata, such as account labels or transaction labels.
We had several goals: We had several goals:
...@@ -33,7 +33,7 @@ the unsecure device. ...@@ -33,7 +33,7 @@ the unsecure device.
However, we want at least prevent the cloud storage operator to be able to read the metadata. We want to hide However, we want at least prevent the cloud storage operator to be able to read the metadata. We want to hide
the metadata itself from the cloud storage operator, and even the XPUBs of the accounts for deniability. the metadata itself from the cloud storage operator, and even the XPUBs of the accounts for deniability.
##General design ## General design
We first derive a *master key* from hardware device itself, which is shared for all accounts on the device. We first derive a *master key* from hardware device itself, which is shared for all accounts on the device.
...@@ -41,9 +41,9 @@ We then derive *account key* for every account. This key is a string -- because ...@@ -41,9 +41,9 @@ We then derive *account key* for every account. This key is a string -- because
From the account key, we derive both a filename and a symmetric encryption key. We then save the metadata to the fiven file, in an encrypted JSON. From the account key, we derive both a filename and a symmetric encryption key. We then save the metadata to the fiven file, in an encrypted JSON.
##Design details ## Design details
###Deriving master key ### Deriving master key
We first get the master key by sending CipherKeyValue to hardware device with following parameters We first get the master key by sending CipherKeyValue to hardware device with following parameters
...@@ -56,11 +56,9 @@ We first get the master key by sending CipherKeyValue to hardware device with fo ...@@ -56,11 +56,9 @@ We first get the master key by sending CipherKeyValue to hardware device with fo
CipherKeyValue is defined in [SLIP-0011](slip-0011.md). CipherKeyValue is defined in [SLIP-0011](slip-0011.md).
.. _trezor source code: https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c#L451-L483
The master key should be 32 bytes (256 bits) long. It is treated as a pseudo-random byte sequence. The master key should be 32 bytes (256 bits) long. It is treated as a pseudo-random byte sequence.
###Deriving account key ### Deriving account key
From the master key, we derive the account key for every account in the following way: From the master key, we derive the account key for every account in the following way:
...@@ -72,13 +70,14 @@ where ...@@ -72,13 +70,14 @@ where
* master key is a byte sequence, as defined in the previous section * master key is a byte sequence, as defined in the previous section
* xpub is a string, as defined in BIP32. For example: * xpub is a string, as defined in BIP32. For example:
`xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy` `xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy`
Then, the result is converted to string using Base58Check encoding, as used in Bitcoin. Then, the result is converted to string using Base58Check encoding, as used in Bitcoin.
The API key is either 49 or 50 characters long. The API key is either 49 or 50 characters long.
###Deriving filename and password from account key ### Deriving filename and password from account key
We take the account key, *as a string*, and we use HMAC function to derive filename and password for metadata file. Every account has its own metadata file. We take the account key, *as a string*, and we use HMAC function to derive filename and password for metadata file. Every account has its own metadata file.
...@@ -111,7 +110,7 @@ We take the account key, *as a string*, and we use HMAC function to derive filen ...@@ -111,7 +110,7 @@ We take the account key, *as a string*, and we use HMAC function to derive filen
* the next 16 bytes are the GCM authentication tag * the next 16 bytes are the GCM authentication tag
* the rest is the ciphertext * the rest is the ciphertext
###Data format ### Data format
The (decrypted) metadata are in following format: The (decrypted) metadata are in following format:
...@@ -130,7 +129,7 @@ All labels can have any unicode letters. Empty string is treated in the software ...@@ -130,7 +129,7 @@ All labels can have any unicode letters. Empty string is treated in the software
An example object looks like this: An example object looks like this:
``` javascript ```javascript
{ {
"version": "1.0.0", "version": "1.0.0",
"accountLabel": "Saving account", // one file per account, so only 1 label needed "accountLabel": "Saving account", // one file per account, so only 1 label needed
...@@ -152,21 +151,19 @@ An example object looks like this: ...@@ -152,21 +151,19 @@ An example object looks like this:
(comments are of course not part of a valid JSON and are included here only for clarity) (comments are of course not part of a valid JSON and are included here only for clarity)
##Example ## Example
All the example code is in Python2. All the example code is in Python2.
###Deriving master key ### Deriving "master" key
Example code, deriving a master key from a connected TREZOR is in [1_masterkey.py](slip-0015/1_masterkey.py). It requires python-trezor_ installed and TREZOR connencted
.. _python-trezor: https://github.com/trezor/python-trezor Example code, deriving a master key from a connected TREZOR is in [1_masterkey.py](slip-0015/1_masterkey.py). It requires [python-trezor](https://github.com/trezor/python-trezor) installed and TREZOR connencted
For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex):: For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex)::
20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3 20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3
###Deriving account key ### Deriving "account" key
Example code, deriving an account key for master key, is in [2_accountkey.py](slip-0015/2_accountkey.py). First argument of the script is xpub of the account, the second argument is the master key from previous step (in hexadecimal). Example code, deriving an account key for master key, is in [2_accountkey.py](slip-0015/2_accountkey.py). First argument of the script is xpub of the account, the second argument is the master key from previous step (in hexadecimal).
...@@ -174,7 +171,7 @@ For the "stress test" wallet, defined in SLIP-0014, and its first account (with ...@@ -174,7 +171,7 @@ For the "stress test" wallet, defined in SLIP-0014, and its first account (with
v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8 v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8
###Deriving filename, decoding ### Deriving filename, decoding
Example code for decryption is in [3_decrypt.py](slip-0015/3_decrypt.py). First and only argument is the account key from previous step. The file has to be in a current working directory (in myTREZOR, we use `~/Dropbox/Apps/TREZOR/` for saving the files). Example code for decryption is in [3_decrypt.py](slip-0015/3_decrypt.py). First and only argument is the account key from previous step. The file has to be in a current working directory (in myTREZOR, we use `~/Dropbox/Apps/TREZOR/` for saving the files).
......
slip-0016.md
View file @ 40c88470
...@@ -26,17 +26,18 @@ Storage file is encrypted JSON object, which contains configuration, tags and se ...@@ -26,17 +26,18 @@ Storage file is encrypted JSON object, which contains configuration, tags and se
### Deriving master key ### Deriving master key
We derive masterKey from hardware device by sending cipherKeyValue with following params: We derive masterKey from hardware device by sending cipherKeyValue with following params:
- path: `m/10016'/0` (hardened path, see BIP32)
- ENC_KEY: `'Unlock encrypted storage?'` (max length message is 256 bytes) * path: `m/10016'/0` (hardened path, see BIP32)
- ENC_VALUE: `'2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee'` (in hexadecimal (128 /2), max length is 1024 bytes) * ENC_KEY: `'Unlock encrypted storage?'` (max length message is 256 bytes)
- encrypt: `true` * ENC_VALUE: `'2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee'` (in hexadecimal (128 /2), max length is 1024 bytes)
- ask_on_encrypt: `true` * encrypt: `true`
- ask_on_decrypt: `true` * ask_on_encrypt: `true`
- iv: unset * ask_on_decrypt: `true`
* iv: unset
JS EXAMPLE: JS EXAMPLE:
``` javascript ```javascript
session.cipherKeyValue( session.cipherKeyValue(
[(10016 | 0x80000000) >>> 0, 0], [(10016 | 0x80000000) >>> 0, 0],
'Unlock encrypted storage?', 'Unlock encrypted storage?',
...@@ -71,7 +72,7 @@ For encrypt/decrypt we are using `AES-256-GCM` algorithm. ...@@ -71,7 +72,7 @@ For encrypt/decrypt we are using `AES-256-GCM` algorithm.
- Input Vector (IV) is 12 randomly generated bytes - Input Vector (IV) is 12 randomly generated bytes
- GCM is used with full 128-bit autentication tag (authTag) - GCM is used with full 128-bit autentication tag (authTag)
for more: https://nodejs.org/api/crypto.html#crypto_crypto_createcipheriv_algorithm_key_iv [more info](https://nodejs.org/api/crypto.html#crypto_crypto_createcipheriv_algorithm_key_iv)
The result output stored in file is: The result output stored in file is:
...@@ -79,20 +80,23 @@ The result output stored in file is: ...@@ -79,20 +80,23 @@ The result output stored in file is:
- next 16 bytes is the GCM authTag - next 16 bytes is the GCM authTag
- the rest is output ciphertext - the rest is output ciphertext
for more: https://nodejs.org/api/crypto.html#crypto_crypto_createdecipheriv_algorithm_key_iv [more info](https://nodejs.org/api/crypto.html#crypto_crypto_createdecipheriv_algorithm_key_iv)
### Data format ### Data format
(Decrypted) data file is serialized JSON object with the following keys: (Decrypted) data file is serialized JSON object with the following keys:
- `version`: for future backwards compatibility and data storage manipualtion * `version`: for future backwards compatibility and data storage manipualtion
- `config`: for remembering personal setup of application * `config`: for remembering personal setup of application
- `tags`: contain set of labels with their icons (from icomoon set). Default tag is **All** and it is only tag, unable to edit or delete. * `tags`: contain set of labels with their icons (from icomoon set). Default tag is **All** and it is only tag, unable to edit or delete.
``` javascript
```javascript
{title:"My social networks", icon:"person", active:"active"} {title:"My social networks", icon:"person", active:"active"}
``` ```
- `entries`: is object of all password entries encrypted second time
``` javascript * `entries`: is object of all password entries encrypted second time
```javascript
{ {
"title": "http://wwww.github.com", "title": "http://wwww.github.com",
"username": "Satoshi Nakamoto", "username": "Satoshi Nakamoto",
...@@ -124,7 +128,7 @@ Step by step entry encryption: ...@@ -124,7 +128,7 @@ Step by step entry encryption:
EXAMPLE: EXAMPLE:
``` javascript ```javascript
session.cipherKeyValue( session.cipherKeyValue(
[(10016 | 0x80000000) >>> 0, 0], // same path [(10016 | 0x80000000) >>> 0, 0], // same path
'Unlock github.com for user Satoshi Nakamoto?', 'Unlock github.com for user Satoshi Nakamoto?',
...@@ -143,7 +147,7 @@ true) // askOnDecrypt? we want this becuase otherwise somebody could rob us! ...@@ -143,7 +147,7 @@ true) // askOnDecrypt? we want this becuase otherwise somebody could rob us!
EXAMPLE: EXAMPLE:
``` javascript ```javascript
session.cipherKeyValue( session.cipherKeyValue(
[(10016 | 0x80000000) >>> 0, 0], // same path [(10016 | 0x80000000) >>> 0, 0], // same path
'Unlock github.com for user Satoshi Nakamoto?', 'Unlock github.com for user Satoshi Nakamoto?',
......
slip-0017.md
View file @ 40c88470
#SLIP-0017 : ECDH using deterministic hierarchy # SLIP-0017 : ECDH using deterministic hierarchy
``` ```
Number: SLIP-0017 Number: SLIP-0017
...@@ -9,18 +9,18 @@ Authors: Roman Zeyde <roman.zeyde@gmail.com> ...@@ -9,18 +9,18 @@ Authors: Roman Zeyde <roman.zeyde@gmail.com>
Created: 2016-05-29 Created: 2016-05-29
``` ```
##Abstract ## Abstract
This document describes a method for implementing Elliptic Curve This document describes a method for implementing Elliptic Curve
Diffie-Hellman algorithm, using a determinstic hierarchy. Diffie-Hellman algorithm, using a determinstic hierarchy.
##Motivation ## Motivation
Using Deterministic Hierarchy for encryption and decryption is ideal, Using Deterministic Hierarchy for encryption and decryption is ideal,
because the same concepts of easy backup that relate to backing up because the same concepts of easy backup that relate to backing up
deterministic wallets can be applied to backing up private keys. deterministic wallets can be applied to backing up private keys.
##Service Identity ## Service Identity
Let's introduce the service identity. It consists of two elements: Let's introduce the service identity. It consists of two elements:
...@@ -28,9 +28,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]` ...@@ -28,9 +28,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]`
Examples: Examples:
- https://example.com * `https://example.com`
- ftp://public@example.com/pub * `ftp://public@example.com/pub`
- ssh://root@example.com:2222 * `ssh://root@example.com:2222`
b) index (32-bit unsigned integer) b) index (32-bit unsigned integer)
...@@ -50,7 +50,7 @@ The index is used so one can generate more keys corresponding to the same URI. ...@@ -50,7 +50,7 @@ The index is used so one can generate more keys corresponding to the same URI.
6. Derive the HD node `m/17'/A'/B'/C'/D'` according to BIP32. 6. Derive the HD node `m/17'/A'/B'/C'/D'` according to BIP32.
##Shared secret generation ## Shared secret generation
Suppose that Alice and Bob need to agree on a shared secret. Suppose that Alice and Bob need to agree on a shared secret.
...@@ -67,6 +67,6 @@ similar way by Bob (since `Q = k2*P1`), is used to derive a shared secret. ...@@ -67,6 +67,6 @@ similar way by Bob (since `Q = k2*P1`), is used to derive a shared secret.
## References ## References
- [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
- [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) * [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)
- [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986) * [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986)
slip-0044.md
View file @ 40c88470
#SLIP-0044 : Registered coin types for BIP-0044 # SLIP-0044 : Registered coin types for BIP-0044
``` ```
Number: SLIP-0044 Number: SLIP-0044
...@@ -10,17 +10,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com> ...@@ -10,17 +10,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
Created: 2014-07-09 Created: 2014-07-09
``` ```
##Abstract ## Abstract
BIP-0044 defines a logical hierarchy for deterministic wallets. BIP-0044 defines a logical hierarchy for deterministic wallets.
Level 2 of the hierarchy describes a coin type in use. Level 2 of the hierarchy describes a coin type in use.
##Motivation ## Motivation
BIP repository does not want to deal with assigning the values for various BIP repository does not want to deal with assigning the values for various
coin types different than Bitcoin so we propose this SLIP to become such body. coin types different than Bitcoin so we propose this SLIP to become such body.
##Registered coin types ## Registered coin types
These are the registered coin types for usage in level 2 of BIP44 described in chapter "Coin type". These are the registered coin types for usage in level 2 of BIP44 described in chapter "Coin type".
...@@ -136,10 +136,10 @@ index | hexa | coin ...@@ -136,10 +136,10 @@ index | hexa | coin
Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin. Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin.
##Libraries ## Libraries
* [BIP44-constants](https://www.npmjs.com/package/bip44-constants) ([source](http://github.com/bitcoinjs/bip44-constants)) JavaScript package with described coin types * [BIP44-constants](https://www.npmjs.com/package/bip44-constants) ([source](http://github.com/bitcoinjs/bip44-constants)) JavaScript package with described coin types
##References ## References
- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) * [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
slip-0048.md
View file @ 40c88470
...@@ -116,10 +116,10 @@ Disadvantages are: ...@@ -116,10 +116,10 @@ Disadvantages are:
Index | Network | Roles Index | Network | Roles
---------------|-------------|--------------------------------------------------------- ---------------|-------------|---------------------------------------------------------
0x00000000 | Steem | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting 0x00000000 | Steem | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting
0x00000001 | BitShares | `0x0`: owner, `0x1`: active, `0x3`: memo 0x00000001 | BitShares | `0x0`: owner, `0x1`: active, `0x3`: memo
0x00000002 | PeerPlays | `0x0`: owner, `0x1`: active, `0x3`: memo 0x00000002 | PeerPlays | `0x0`: owner, `0x1`: active, `0x3`: memo
0x00000003 | Muse | `0x0`: owner, `0x1`: active, `0x3`: memo 0x00000003 | Muse | `0x0`: owner, `0x1`: active, `0x3`: memo
## Examples ## Examples
...@@ -130,4 +130,4 @@ BitShares | forth | owner | forth | m / 48' / 1' / 3' / 0' ...@@ -130,4 +130,4 @@ BitShares | forth | owner | forth | m / 48' / 1' / 3' / 0'
## References ## References
- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) * [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment