mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-21 23:58:09 +00:00
Edited ch05_wallets.adoc with Atlas code editor
This commit is contained in:
parent
8873a8957b
commit
f8e15fa51f
@ -817,6 +817,25 @@ another purpose--it allows the introduction of a passphrase that
|
||||
serves as an additional security factor protecting the seed, as we will
|
||||
describe in more detail in <<recovery_passphrase>>.
|
||||
|
||||
[TIP]
|
||||
====
|
||||
The key-stretching function, with its 2,048 rounds of hashing, makes it
|
||||
slightly harder to brute-force attack the recovery code using software.
|
||||
Special-purpose hardware is not significantly affected. For an attacker
|
||||
who needs to guess a user's entire recovery code, the length of the code
|
||||
(128 bits at a minimum) provides more than sufficient security. But for
|
||||
cases where an attacker might learn a small part of the user's code,
|
||||
key-stretching adds some security by slowing down how fast an attacker
|
||||
can check different recovery code combinations. BIP39's parameters were
|
||||
considered weak by modern standards even when it was first published
|
||||
almost a decade ago, although that's likely a consequence of being
|
||||
designed for compatibility with hardware signing devices with low-powered
|
||||
CPUs. Some alternatives to BIP39 use stronger key-stretching
|
||||
parameters, such as Aezeed's 32,768 rounds of hashing using the more
|
||||
complex Scrypt algorithm, although they may not be as convenient to run
|
||||
on hardware signing devices.
|
||||
====
|
||||
|
||||
The process described in steps 7 through 9 continues from the process
|
||||
described previously in <<generating_recovery_words>>:
|
||||
|
||||
@ -842,24 +861,6 @@ described previously in <<generating_recovery_words>>:
|
||||
.From recovery code to seed
|
||||
image::images/mbc3_0505.png["From recovery code to seed"]
|
||||
|
||||
[TIP]
|
||||
====
|
||||
The key-stretching function, with its 2,048 rounds of hashing, makes it
|
||||
slightly harder to brute-force attack the recovery code using software.
|
||||
Special-purpose hardware is not significantly affected. For an attacker
|
||||
who needs to guess a user's entire recovery code, the length of the code
|
||||
(128 bits at a minimum) provides more than sufficient security. But for
|
||||
cases where an attacker might learn a small part of the user's code,
|
||||
key-stretching adds some security by slowing down how fast an attacker
|
||||
can check different recovery code combinations. BIP39's parameters were
|
||||
considered weak by modern standards even when it was first published
|
||||
almost a decade ago, although that's likely a consequence of being
|
||||
designed for compatibility with hardware signing devices with low-powered
|
||||
CPUs. Some alternatives to BIP39 use stronger key-stretching
|
||||
parameters, such as Aezeed's 32,768 rounds of hashing using the more
|
||||
complex Scrypt algorithm, although they may not be as convenient to run
|
||||
on hardware signing devices.
|
||||
====
|
||||
|
||||
Tables pass:[<a data-type="xref" href="#bip39_128_no_pass"
|
||||
data-xrefstyle="select: labelnumber">#bip39_128_no_pass</a>],
|
||||
|
Loading…
Reference in New Issue
Block a user