|
|
|
@ -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>],
|
|
|
|
|