Enhancements to private and public keys articles

This commit is contained in:
Piotr Włodarek 2018-01-09 14:33:55 +01:00
parent fdc9af1ea9
commit 5ad59f45b2
7 changed files with 59 additions and 28 deletions

View file

@ -1,26 +1,11 @@
# Ed25519 curve # Ed25519 curve
!!! danger !!! danger
Article author is nowhere close to being a cryptographer. Be sceptical on accuracy. Author is nowhere close to being a cryptographer. Be sceptical on accuracy.
!!! note !!! note
This article is only about the underlying curve. Public key derivation and signing algorithm will be treated separately. This article is only about the underlying curve. Public key derivation and signing algorithm will be treated separately.
!!! note
Before we get to Monero, a little bit of context. We are talking asymmetric cryptography here.
The "asymmetric" simply means the are two keys:
* the private key (used primarily for signing data and for decrypting data)
* the public key (used primarily for signature verification and encrypting data)
This is in contrast to symmetric cryptography which uses a single (secret) key.
Historically, asymmetric cryptography was based on the problem of factorization of a very large integers
back into prime numbers (which is practically impossible for large enough integers).
Recently, asymmetric cryptography is based on a mathematical notion of elliptic curves.
Ed25519 is a specific, well researched and standardized elliptic curve.
Monero employs Ed25519 elliptic curve as a basis for its key pair generation. Monero employs Ed25519 elliptic curve as a basis for its key pair generation.
However, Monero does not exactly follow EdDSA reference signature scheme. However, Monero does not exactly follow EdDSA reference signature scheme.

View file

@ -1,7 +1,7 @@
# Asymmetric cryptography used in Monero # Asymmetric cryptography used in Monero
!!! danger !!! danger
Article author is nowhere close to being a cryptographer. Be sceptical on accuracy. Author is nowhere close to being a cryptographer. Be sceptical on accuracy.
Before we get to Monero specific stuff, a little bit of context. We are talking asymmetric cryptography here. Before we get to Monero specific stuff, a little bit of context. We are talking asymmetric cryptography here.
The "asymmetric" simply means the are two keys: The "asymmetric" simply means the are two keys:

View file

@ -1,12 +1,9 @@
# Private keys in Monero # Private keys in Monero
!!! danger !!! danger
Article author is nowhere close to being a cryptographer. Be sceptical on accuracy. Author is nowhere close to being a cryptographer. Be sceptical on accuracy.
!!! warning In Monero, the root private key is generated [randomly](/cryptography/prng). Other private keys are derived deterministically from the root private key.
Article is a work in progress.
Private key is generated [randomly](/cryptography/prng).
Private key must be kept secret. Private key must be kept secret.
@ -24,10 +21,31 @@ In user-facing contexts, private key is encoded in a [little-endian](https://en.
## Relation to Ed25519 ## Relation to Ed25519
Being a simple random integer, private key is not specific to any particular asymmetric cryptography scheme. Being simply a random integer, private key is not specific to any particular asymmetric cryptography scheme.
However, before deriving Ed25519 public key, the private key is subject to modulo `l`, In context of Monero EC cryptography the private key is a number the base point `G` is multiplied by.
where `l` is the maximum scalar allowed by [Ed25519 scheme](/cryptography/asymmetric/ed25519). The result of the multiplication is the public key `P` (another point on the curve).
Multiplication of a point by a number has a very special definition in EC cryptography.
See this [this guide](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/) for details.
### Key strength
Before deriving Ed25519 public key, the private key is subject to modulo `l`,
where `l` is the maximum scalar allowed by the [Ed25519 scheme](/cryptography/asymmetric/ed25519).
The `l` is on the order of 2^252, so the effective key strength is technically 252 bits, not 256 bits. The `l` is on the order of 2^252, so the effective key strength is technically 252 bits, not 256 bits.
This is standard for EC cryptography and is more of a cosmetic nuance than any real concern. This is standard for EC cryptography and is more of a cosmetic nuance than any concern.
## Private spend key
Private spend key is used to spend moneros.
More specifically, it is used to build one-time private keys which allow to spend related outputs.
## Private view key
Private view key is used to recognize your incoming transactions on the otherwise opaque blockchain.
## One-time private keys
One-time private key like construct is used in [stealth addresses](https://monero.stackexchange.com/questions/1409/constructing-a-stealth-monero-address).

View file

@ -1,7 +1,7 @@
# Public keys in Monero # Public keys in Monero
!!! danger !!! danger
Article author is nowhere close to being a cryptographer. Be sceptical on accuracy. Author is nowhere close to being a cryptographer. Be sceptical on accuracy.
!!! warning !!! warning
Article is a work in progress. Article is a work in progress.
@ -36,3 +36,8 @@ However, the addition is **not** a simple vector addition. It has a very specifi
definition nicely described in [this article](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/). definition nicely described in [this article](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/).
What is important is that result of addition is always a point on the curve. What is important is that result of addition is always a point on the curve.
For example, G + G is another point on the curve. For example, G + G is another point on the curve.
## Use cases
[Monero address](/public-address/standard-address) is composed of public spend key and public view key.
These keys are used to build stealth addresses to receive payments.

View file

@ -1,4 +1,4 @@
# Unofficial Monero Documentation (1% done) # Unofficial Monero Documentation (2% done)
Monerodocs attempts to organize basic technical knowledge on Monero in one place. Monerodocs attempts to organize basic technical knowledge on Monero in one place.

View file

@ -37,6 +37,11 @@ It totals to 69 bytes. The bytes are then encoded ([src](https://github.com/mone
`4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge` `4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge`
## Generating
Standard address is derived from the root private key. TODO: describe.
## Reference ## Reference
* [StackExchenge answer](https://monero.stackexchange.com/questions/980/what-are-the-public-viewkeys-and-spendkeys)
* [https://xmr.llcoins.net/addresstests.html](https://xmr.llcoins.net/addresstests.html) * [https://xmr.llcoins.net/addresstests.html](https://xmr.llcoins.net/addresstests.html)

View file

@ -33,6 +33,10 @@ All subaddresses can be derived from the wallet seed.
Additionally, you conveniently manage your subaddresses within a single user interface. Additionally, you conveniently manage your subaddresses within a single user interface.
## Wallet level feature
Subaddresses are a wallet-level feature to construct and interpret transactions. They do not affect the consensus.
## Data structure ## Data structure
Subaddress has a dedicated "network byte": Subaddress has a dedicated "network byte":
@ -46,6 +50,20 @@ Otherwise the data structure is the same as for [standard address](/public-addre
Each subaddress conceptually has an index (with 0 being the base standard address). Each subaddress conceptually has an index (with 0 being the base standard address).
The index is not directly included in subaddress structure but is used as input to create the private spend key. The index is not directly included in subaddress structure but is used as input to create the private spend key.
## Generating
The private key `m` related to a subaddress is derived as follows:
m = Hs(a || i)
Where:
* `Hs` is a Keccak-256 hash function interpreted as integer and modulo `l` (maximum Ed25519 scalar)
* `a` is a private view key
* `i` is a subaddress index
TODO: describe rest of the procedure.
## Caveates ## Caveates
* Subaddress **cannot** be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions. * Subaddress **cannot** be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions.