arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-22 08:08:11 +00:00
Code Issues Releases Wiki Activity

Edited ch05_wallets.adoc with Atlas code editor

Browse Source
This commit is contained in:
claylock 2023-10-27 12:36:10 +00:00
parent 8873a8957b
commit f8e15fa51f
1 changed files with 19 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
ch05_wallets.adoc
View File

@ -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 serves as an additional security factor protecting the seed, as we will
describe in more detail in <<recovery_passphrase>>. 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 The process described in steps 7 through 9 continues from the process
described previously in <<generating_recovery_words>>: described previously in <<generating_recovery_words>>:
@ -842,24 +861,6 @@ described previously in <<generating_recovery_words>>:
.From recovery code to seed .From recovery code to seed
image::images/mbc3_0505.png["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" Tables pass:[<a data-type="xref" href="#bip39_128_no_pass"
data-xrefstyle="select: labelnumber">#bip39_128_no_pass</a>], data-xrefstyle="select: labelnumber">#bip39_128_no_pass</a>],