ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-14 00:35:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rewrite cryptographic keys page significantly for clarity

Browse Source
This commit is contained in:
mDuo13
2020-07-31 16:52:35 -07:00
parent 4aa13ff82d
commit d26223141b
3 changed files with 387 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

168
content/_img-sources/cryptographic-keys.uxf Normal file
View File

@@ -0,0 +1,168 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLClass</id>
<coordinates>
<x>260</x>
<y>100</y>
<w>120</w>
<h>70</h>
</coordinates>
<panel_attributes>Seed
--
(Optional)
16 bytes
lt=.</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLObject</id>
<coordinates>
<x>80</x>
<y>100</y>
<w>140</w>
<h>70</h>
</coordinates>
<panel_attributes>Passphrase
or source of
randomness
--
(Optional)
lt=.</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>210</x>
<y>130</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=-&gt;</panel_attributes>
<additional_attributes>10.0;10.0;50.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>420</x>
<y>100</y>
<w>120</w>
<h>70</h>
</coordinates>
<panel_attributes>Private Key
--
32 bytes</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>370</x>
<y>130</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=-&gt;</panel_attributes>
<additional_attributes>10.0;10.0;50.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>530</x>
<y>130</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=-&gt;</panel_attributes>
<additional_attributes>10.0;10.0;50.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>580</x>
<y>100</y>
<w>120</w>
<h>70</h>
</coordinates>
<panel_attributes>Public Key
--
33 bytes</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>740</x>
<y>100</y>
<w>120</w>
<h>70</h>
</coordinates>
<panel_attributes>Account ID
--
20 bytes</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>690</x>
<y>130</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=-&gt;</panel_attributes>
<additional_attributes>10.0;10.0;50.0;10.0</additional_attributes>
</element>
<element>
<id>UMLNote</id>
<coordinates>
<x>60</x>
<y>60</y>
<w>500</w>
<h>130</h>
</coordinates>
<panel_attributes>Secrets
fg=red</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>580</x>
<y>60</y>
<w>440</w>
<h>30</h>
</coordinates>
<panel_attributes>Public information
style=wordwrap
halign=center</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>900</x>
<y>100</y>
<w>160</w>
<h>70</h>
</coordinates>
<panel_attributes>Address
--
24 bytes (classic)
32 bytes (X-address)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>850</x>
<y>130</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=&lt;-&gt;</panel_attributes>
<additional_attributes>10.0;10.0;50.0;10.0</additional_attributes>
</element>
</diagram>

136
content/concepts/payment-system-basics/accounts/cryptographic-keys.md
View File

@@ -1,105 +1,120 @@
# Cryptographic Keys
In the XRP Ledger, a digital signature proves that a [transaction](transaction-basics.html) is authorized to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. <!-- STYLE_OVERRIDE: is authorized to -->
In the XRP Ledger, a digital signature _authorizes_ a [transaction](transaction-basics.html) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
Every digital signature is based on a cryptographic key pair associated with the transaction's sending account. A key pair may be generated using any of the XRP Ledger's supported [cryptographic signing algorithms](#signing-algorithms). A key pair can be used as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair) or a member of a [signer list](multi-signing.html), regardless of what algorithm was used to generate it.
To make a digital signature, you use a cryptographic key pair associated with the transaction's sending account. A key pair may be generated using any of the XRP Ledger's supported [cryptographic signing algorithms](#signing-algorithms). A key pair can be used as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair) or a member of a [signer list](multi-signing.html), regardless of what algorithm was used to generate it.
**Warning:** It is important to maintain proper security over your secret keys. Digital signatures are the only way of verifying to the XRP Ledger that you are authorized to send a transaction, and there is no privileged administrator who can undo or reverse any transaction that has been applied to the ledger. If someone else knows the secret key of your XRP Ledger account, that person can create digital signatures to authorize any transaction the same as you could.
**Warning:** It is important to maintain proper security over your cryptographic keys. Digital signatures are the only way of authorizing transactions in the XRP Ledger, and there is no privileged administrator who can undo or reverse any transactions after they have applied. If someone else knows the seed or private key of your XRP Ledger account, that person can create digital signatures to authorize any transaction the same as you could.
## Generating Keys
You generate a key pair using the [`wallet_propose`](wallet_propose.html) method. Here's a sample `wallet_propose` response:
There are several ways to create a key pair:
```
{
"result": {
"account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q",
"key_type": "secp256k1",
"master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT",
"master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX",
"master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A",
"public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS",
"public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948"
},
"status": "success",
"type": "response"
}
```
- The [wallet_propose method][] in [the `rippled` server](the-rippled-server.html).
- The [`generateAddress()` method of ripple-lib](rippleapi-reference.html#generateaddress).
- Other [tools or wallet applications](software-ecosystem.html). <!-- TODO: link a "wallets" page when that gets added -->
The response contains a key pair (a seed and a public key, in various formats) as well as an `account_id`.
**Seed**
## Key Components
A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual secret key (and public key) for an account. The `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
A cryptographic key pair is a **private key** and a **public key** that are connected mathematically through a key derivation process. Each key is a number; the private key should be chosen using a strong source of randomness. The [cryptographic signing algorithm](#signing-algorithms) defines the key derivation process and sets constraints on the numbers that can be cryptographic keys.
Because the seed value is the basis for all the other information of an account, you must protect it very carefully. Anyone who has knows an address's seed value effectively has full control over that address.
When dealing with the XRP Ledger, you may also use some related values such as a passphrase, seed, account ID, or address.
**Secret Key**
[![Passphrase → Seed → Private Key → Public Key → Account ID ←→ Address](img/cryptographic-keys.svg)](img/cryptographic-keys.svg)
_Figure: A simplified view of the relationship between cryptographic key values._
The `wallet_propose` response does not explicitly list the secret key value, also called a _private key_. Software that can sign transactions is expected to [derive the secret key](#key-derivation) from the seed value.
The passphrase, seed, and private key are **secrets**: if you know any of these values for an account, you can make valid signatures and you have full control over that account. If you own an account, be **very careful** with your account's secret information. If you don't have it, you can't use your account. If someone else can access it, they can take control of your account.
**Public Key**
The public key, account ID, and address are public information. There are some situations where you might temporarily keep a public key to yourself, but eventually you need to publish it as part of a transaction so that the XRP Ledger can verify the signature and process the transaction.
The `public_key` and `public_key_hex` both represent the same public key value. The public key is derived from the secret key as part of key derivation. The public key makes it possible to verify the authenticity of a transaction signature, but not to create more signatures.
For more technical details of how key derivation works, see [Key Derivation](#key-derivation).
**Account ID**
### Passphrase
The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. Typically, an Account ID is encoded in [base58][] to make a "classic address", but other representations are possible, including hexadecimal. The [X-Address format](accounts.html#addresses) combines an Account ID and a [Destination Tag](source-and-destination-tags.html) into a single address.
You can, optionally, use a passphrase or some other input as a way of choosing a seed or private key. This is less secure than choosing the seed or private key completely at random, but there are some rare cases where you want to do this. (For example, in 2018 "XRPuzzler" gave away XRP to the first person [to solve a puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); he used the puzzle's solution as the passphrase to an account holding the prize XRP.)
It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account.
The passphrase is secret information, so you must protect it very carefully. Anyone who knows an address's passphrase has effectively full control over the address.
The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](multi-signing.html) to authorize transactions for another account that does exist.
### Seed
To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](payment.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html).
A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual private and public keys for an account. In a [wallet_propose method][] response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
For more information about the `wallet_propose` response, see [`wallet_propose`](wallet_propose.html).
The seed value is secret information, so you must protect it very carefully. Anyone who has knows an address's seed value has effectively full control over that address.
You can use this generated key pair in one of three ways: as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair), or [signer list member](multi-signing.html).
### Private Key
**Key Type**
The _private key_ is the value that is used to create a digital signature. Most XRP Ledger software does not explicitly show the private key, and [derives the private key](#key-derivation) from the seed value when necessary. It is technically possible to save the private key instead of the seed and use that to sign transactions directly, but this usage is rare.
The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [wallet_propose method][].
Just like the seed, the private key is secret information, so you must protect it very carefully. Anyone who has knows an address's private key has effectively full control over that address.
### Public Key
The _public key_ is the value used to verify the authenticity of a digital signature. The public key is derived from the private key as part of key derivation. In a [wallet_propose method][] response, the `public_key` and `public_key_hex` both represent the same public key value.
Transactions in the XRP Ledger must include the public keys so that the network can verify the transactions' signatures. The public key cannot be used to create valid signatures, so it is safe to share publicly.
### Account ID and Address
The **Account ID** is the core identifier for an [account](accounts.html) or a key pair. It is derived from the public key. In the XRP Ledger protocol, the Account ID is 20 bytes of binary data. Most XRP Ledger APIs represent the Account ID as an address, in one of two formats:
- A "classic address" writes an Account ID in [base58][] with a checksum. In a [wallet_propose method][] response, this is the `account_id` value.
- An "X-Address" combines an Account ID _and_ a [Destination Tag](source-and-destination-tags.html) and writes the combined value in [base58][] with a checksum.
The checksum in both formats is there so that small changes result in an invalid address, instead of changing it to refer to a different, but still potentially valid, account. This way, if you make a typo or a transmission error occurs, you don't send money to the wrong place.
It is important to know that not all Account IDs (or addresses) refer to accounts in the ledger. Deriving keys and addresses is purely a mathematical operation. For an account to have a record in the XRP Ledger, it must [receive a payment of XRP](accounts.html#creating-accounts) that funds its [reserve requirement](reserves.html). An account cannot send any transactions until after it has been funded.
Even if an Account ID or address does not refer to a funded account, you _can_ use that Account ID or address to represent a [regular key pair](#regular-key-pair) or a [member of a signer list](multi-signing.html).
### Key Type
The XRP Ledger supports more than one [cryptographic signing algorithm](#signing-algorithms). Any given key pair is only valid for a specific cryptographic signing algorithm. Some private keys may technically qualify as valid keys for more than one algorithm, but those private keys would have different public keys for each algorithm, and you should not reuse private keys anyway.
The `key_type` field in the [wallet_propose method][] refers to the cryptographic signing algorithm to use.
## Master Key Pair
The master key pair is composed of a secret key and a public key. In addition to being able to sign all transactions that a regular key pair can, the master key pair's secret key is the only key that can be used to perform the following actions:
The master key pair consists of a private key and a public key. The address of an account is derived from the account's master key pair, so they are [intrinsically related](accounts.html#address-encoding). You cannot change or remove the master key pair, but you can disable it.
* [Disable the master public key](accountset.html).
The [wallet_propose method][] is one way of generating a master key pair. The response from this method shows the account's seed, address, and master public key together. For some other ways of setting up master key pairs, see [Set Up Secure Signing](set-up-secure-signing.html).
* Permanently give up the ability to [freeze](freezes.html#no-freeze).
**Warning:** If a malicious actor learns your master private key (or seed), they have full control over your account, unless your master key pair is disabled. They can take all the money your account holds and do other irreparable harm. Treat your secret values with care!
* Send a cost-0 [key reset transaction](transaction-cost.html#key-reset-transaction).
Because changing a master key pair is impossible, you should treat it with care proportionate to the value it holds. A good practice is to [keep your master key pair offline](offline-account-setup.html) and set up a regular key pair to sign transactions from your account instead. By keeping the master key pair enabled but offline, you can be reasonably certain that no one can get access to it using the internet, but you can still go find it to use in an emergency.
The master key pair for an account is generated in the same [`wallet_propose`](wallet_propose.html) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](accounts.html#address-encoding) to the address, which is derived from the public key.
Keeping your master key pair offline means not putting the secret information (passphrase, seed, or private key) anywhere that malicious actors can get access to it. In general, this means it is not within reach of a computer program that interacts with the internet at large. For example, you could keep it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or have it completely memorized. (Memorization has some drawbacks, though, including making it impossible to pass they key on after you are dead.)
This is as opposed to a regular key pair, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key pair to an account. Because a regular key pair is explicitly assigned, it is not intrinsically related to the address of the account it is authorized to sign transactions for. For more information, see [Regular Key Pair](#regular-key-pair).
**Caution:** A master key pair cannot be changed, but it can be disabled. This means that if your master seed or secret key is compromised, rather than change it, you must [disable it](accountset.html).
Because a master key pair cannot be changed and can only be disabled in the event of a compromise, this is a compelling reason to [keep your master key pair offline](offline-account-setup.html) and set up a regular key pair to sign transactions from your account instead.
### Special Permissions
Keeping your master key pair offline means not putting your master secret key anywhere that malicious actors can get access to it. For example, this can mean keeping it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or in general, not within reach of a computer program that interacts with the internet at large. Ideally, a master key pair is used only on the most trusted of devices and for emergencies only, such as to change a regular key pair in the event of a possible or actual compromise.
**Only** the master key pair can authorize transactions to do certain things:
- Send an account's very first transaction, because accounts cannot be initialized with
- Disable the master key pair. (You must set up at least one other method of [authorizing transactions](transaction-basics.html#authorizing-transactions) first.)
- Permanently give up the ability to [freeze](freezes.html#no-freeze).
- Send a special [key reset transaction](transaction-cost.html#key-reset-transaction) with a transaction cost of 0 XRP.
A regular key or [multi-signature](multi-signing.html) can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](accounts.html#deletion-of-accounts) if it meets the requirements for deletion.
## Regular Key Pair
The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions, while keeping your master key pair offline. If the seed or secret key of a regular key pair is compromised, you can remove or replace the key pair without changing the rest of your account. This saves the trouble of re-establishing the account's settings and relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.)
An XRP Ledger account can authorize a secondary key pair, called a _regular key pair_. After doing so, you can use either the [master key pair](#master-key-pair) or the regular key to authorize transactions. You can remove or replace your regular key pair at any time without changing the rest of your account.
You generate a key pair to use as a regular key pair using the [`wallet_propose`](wallet_propose.html) method. However, unlike with a [master key pair](#master-key-pair), which is generated alongside and intrinsically related to the `account_id` of an account it supports, you must explicitly create the relationship between a regular key pair and the account you want it to sign transactions for. You use the [`SetRegularKey`](setregularkey.html) method to assign a regular key pair to an account.
A regular key pair can authorize most of the same types of transactions as the master key pair, with [certain exceptions](#special-permissions). For example, a regular key pair _can_ authorize a transaction to change the regular key pair.
For a tutorial on assigning a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html).
A good security practice is to save your master private key somewhere offline, and use a regular key pair most of the time. As a precaution, you can change the regular key pair regularly. If a malicious user learns your regular private key, you can get the master key pair out of offline storage and use it to change or remove the regular key pair. This way, you can regain control of your account. Even if you are not fast enough to stop the malicious user from stealing your money, at least you don't need to move to a new account and re-create all your settings and relationships from scratch.
After you assign a regular key pair to an account, the account has two key pairs associated with it:
Regular key pairs have the same format as master key pairs. You generate them the same way (for example, using the [wallet_propose method][]). The only difference is that a regular key pair is not intrinsically tied to the account it signs transactions for. It is possible (but not a good idea) to use the master key pair from one account as the regular key pair for another account.
* A master key pair that is intrinsically related to the account's `account_id` and which you should keep offline.
* A regular key pair that you've explicitly assigned to the account and which you use to sign transactions for the account.
You can assign one regular key pair to an account and use it to sign all transactions, except for the ones reserved for the [master key pair](#master-key-pair).
You can remove or change a regular key pair at any time. This means that if a regular secret key is compromised (but the master secret key is not), you can regain control of your account by removing or changing the regular key pair.
For a tutorial on changing or removing a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html).
The [SetRegularKey transaction][] assigns or changes the regular key pair for an account. For a tutorial on assigning or changing a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html).
## Signing Algorithms
@@ -110,18 +125,17 @@ The XRP Ledger supports the following cryptographic signing algorithms:
| Key Type | Algorithm | Description |
|-------------|-----------|---|
| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the scheme used in Bitcoin. The XRP Ledger uses these key types by default. |
| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. |
| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the same scheme Bitcoin uses. The XRP Ledger uses these key types by default. |
| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. |
When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.
**Note:** Currently, you cannot sign [payment channel claims](use-payment-channels.html) with Ed25519 keys. This is a bug.
### Future Algorithms
In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of early 2020, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. <!-- STYLE_OVERRIDE: will -->
In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of mid 2020, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. <!-- STYLE_OVERRIDE: will, easily -->
## Key Derivation

144
img/cryptographic-keys.svg Normal file
View File

@@ -0,0 +1,144 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN'
'http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd'>
<svg fill-opacity="1" xmlns:xlink="http://www.w3.org/1999/xlink" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" width="1040" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" viewBox="40 40 1040 170" height="170" xmlns="http://www.w3.org/2000/svg" font-family="'Dialog'" font-style="normal" stroke-linejoin="miter" font-size="12px" stroke-dashoffset="0" image-rendering="auto"
><!--Generated by the Batik Graphics2D SVG Generator--><defs id="genericDefs"
/><g
><defs id="defs1"
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath1"
><path d="M0 0 L2147483647 0 L2147483647 2147483647 L0 2147483647 L0 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath2"
><path d="M0 0 L0 70 L160 70 L160 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath3"
><path d="M0 0 L0 30 L440 30 L440 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath4"
><path d="M0 0 L0 130 L500 130 L500 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath5"
><path d="M0 0 L0 70 L120 70 L120 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath6"
><path d="M0 0 L0 70 L140 70 L140 0 Z"
/></clipPath
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath7"
><path d="M0 0 L0 30 L70 30 L70 0 Z"
/></clipPath
></defs
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(900,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="158.5" height="68.5" y="0.5" clip-path="url(#clipPath2)" stroke="none"
/></g
><g transform="translate(900,100)"
><rect fill="none" x="0.5" width="158.5" height="68.5" y="0.5" clip-path="url(#clipPath2)"
/><text x="51" font-size="14px" y="18.1094" clip-path="url(#clipPath2)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Address</text
><path fill="none" d="M1 24.1094 L159 24.1094" clip-path="url(#clipPath2)"
/><text x="5" font-size="14px" y="39.2188" clip-path="url(#clipPath2)" font-family="sans-serif" stroke="none" xml:space="preserve"
>24 bytes (classic)</text
><text x="5" font-size="14px" y="55.3281" clip-path="url(#clipPath2)" font-family="sans-serif" stroke="none" xml:space="preserve"
>32 bytes (X-address)</text
></g
><g font-family="sans-serif" font-size="14px" transform="translate(580,60)"
><text x="156" xml:space="preserve" y="18.1094" clip-path="url(#clipPath3)" stroke="none"
>Public information</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(60,60)" stroke-opacity="0" stroke="rgb(255,255,255)"
><path d="M0.5 0.5 L488.5 0.5 L499 12.5 L499 129 L0.5 129 Z" stroke="none" clip-path="url(#clipPath4)"
/></g
><g fill="red" transform="translate(60,60)" stroke="red"
><path fill="none" d="M0.5 0.5 L488.5 0.5 L499 12.5 L499 129 L0.5 129 Z" clip-path="url(#clipPath4)"
/><path fill="none" d="M488.5 0.5 L488.5 12.5 L499 12.5" clip-path="url(#clipPath4)"
/><text x="5" font-size="14px" y="18.1094" clip-path="url(#clipPath4)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Secrets</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(740,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)" stroke="none"
/></g
><g transform="translate(740,100)"
><rect fill="none" x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)"
/><text x="21" font-size="14px" y="18.1094" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Account ID</text
><path fill="none" d="M1 24.1094 L119 24.1094" clip-path="url(#clipPath5)"
/><text x="5" font-size="14px" y="39.2188" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>20 bytes</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(580,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)" stroke="none"
/></g
><g transform="translate(580,100)"
><rect fill="none" x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)"
/><text x="23" font-size="14px" y="18.1094" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Public Key</text
><path fill="none" d="M1 24.1094 L119 24.1094" clip-path="url(#clipPath5)"
/><text x="5" font-size="14px" y="39.2188" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>33 bytes</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(420,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)" stroke="none"
/></g
><g transform="translate(420,100)"
><rect fill="none" x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)"
/><text x="20" font-size="14px" y="18.1094" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Private Key</text
><path fill="none" d="M1 24.1094 L119 24.1094" clip-path="url(#clipPath5)"
/><text x="5" font-size="14px" y="39.2188" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>32 bytes</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(80,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="138.5" height="68.5" y="0.5" clip-path="url(#clipPath6)" stroke="none"
/></g
><g stroke-dasharray="8,5" stroke-miterlimit="5" transform="translate(80,100)" stroke-linecap="butt"
><rect fill="none" x="0.5" width="138.5" height="68.5" y="0.5" clip-path="url(#clipPath6)"
/><text x="30" font-size="14px" y="13.3906" clip-path="url(#clipPath6)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Passphrase</text
><text x="28" font-size="14px" y="29.5" clip-path="url(#clipPath6)" font-family="sans-serif" stroke="none" xml:space="preserve"
>or source of</text
><text x="26" font-size="14px" y="45.6094" clip-path="url(#clipPath6)" font-family="sans-serif" stroke="none" xml:space="preserve"
>randomness</text
></g
><g font-family="sans-serif" font-size="14px" transform="translate(80,100)"
><path fill="none" d="M1 51.6094 L139 51.6094" clip-path="url(#clipPath6)"
/><text x="34" xml:space="preserve" y="66.7188" clip-path="url(#clipPath6)" stroke="none"
>(Optional)</text
></g
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(260,100)" stroke-opacity="0" stroke="rgb(255,255,255)"
><rect x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)" stroke="none"
/></g
><g stroke-dasharray="8,5" stroke-miterlimit="5" transform="translate(260,100)" stroke-linecap="butt"
><rect fill="none" x="0.5" width="118.5" height="68.5" y="0.5" clip-path="url(#clipPath5)"
/><text x="42" font-size="14px" y="18.1094" clip-path="url(#clipPath5)" font-family="sans-serif" stroke="none" xml:space="preserve"
>Seed</text
></g
><g font-family="sans-serif" font-size="14px" transform="translate(260,100)"
><path fill="none" d="M1 24.1094 L119 24.1094" clip-path="url(#clipPath5)"
/><text x="5" xml:space="preserve" y="39.2188" clip-path="url(#clipPath5)" stroke="none"
>(Optional)</text
><text x="5" xml:space="preserve" y="55.3281" clip-path="url(#clipPath5)" stroke="none"
>16 bytes</text
></g
><g transform="translate(850,130)"
><path fill="none" d="M11.5 10.5 L50.5 10.5" clip-path="url(#clipPath7)"
/><path fill="none" d="M22.2583 17 L11 10.5 L22.2583 4" clip-path="url(#clipPath7)"
/><path fill="none" d="M38.7417 17 L50 10.5 L38.7417 4" clip-path="url(#clipPath7)"
/></g
><g transform="translate(690,130)"
><path fill="none" d="M10.5 10.5 L49.5 10.5" clip-path="url(#clipPath7)"
/><path fill="none" d="M38.7417 17 L50 10.5 L38.7417 4" clip-path="url(#clipPath7)"
/></g
><g transform="translate(530,130)"
><path fill="none" d="M10.5 10.5 L49.5 10.5" clip-path="url(#clipPath7)"
/><path fill="none" d="M38.7417 17 L50 10.5 L38.7417 4" clip-path="url(#clipPath7)"
/></g
><g transform="translate(370,130)"
><path fill="none" d="M10.5 10.5 L49.5 10.5" clip-path="url(#clipPath7)"
/><path fill="none" d="M38.7417 17 L50 10.5 L38.7417 4" clip-path="url(#clipPath7)"
/></g
><g transform="translate(210,130)"
><path fill="none" d="M10.5 10.5 L49.5 10.5" clip-path="url(#clipPath7)"
/><path fill="none" d="M38.7417 17 L50 10.5 L38.7417 4" clip-path="url(#clipPath7)"
/></g
></g
></svg
>
Side by Side

After

Width:  |  Height:  |  Size: 9.1 KiB