From: Gregory Maxwell <greg@xiph•org>
To: Jochen Hoenicke <hoenicke@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: derived mnemonics
Date: Wed, 27 Jul 2016 20:59:54 +0000 [thread overview]
Message-ID: <CAAS2fgS-ObNbkP2PN6y+xJaxFnaz0sTSYiafCzjMtUv0sHjtxg@mail.gmail.com> (raw)
In-Reply-To: <CANYHNmLot1+-LbisfrPRtgDPnofD7bnQ3By_pgT2RFvLHRm7Hg@mail.gmail.com>
On Wed, Jul 27, 2016 at 10:39 AM, Jochen Hoenicke via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> schrieb am Di., 26. Juli 2016 um 22:10 Uhr:
>>
>> Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
>> personally consider "not enough" to protect a serious amount of funds.
>>
>
> But what are the alternatives? Put an expensive processor and a decent
> amount of memory in every hardware wallet to support scrypt? Use a million
> iterations and just wait 10 minutes after entering you passphrase? Or
> compute the secret key on your online computer instead?
>
> Also, how many iterations are secure? A million? Then just add two random
> lower-case letters to the end of your passphrase and you have a better
> protection with 2048 iterations. If you want to be able to use your
> passphrase with cheap hardware and be protected against a high-end computer
> with multiple GPUs that is almost a mllion times faster, then you have to
> choose a good passphrase. Or just make sure nobody steals your seed;
Jochen, two alternatives were raised in public discussion:
Use a scheme which supports delegatable hardening-- (there are two
broad classes proposed, one where the delegated party learns
information that would let them bypass the part of the hardening they
perform but only that part, and another where the delegation is
information theoretically private.)
or
Eschew the pretextual 'hardening' that serves no purpose but to cause
users to think the scheme is more secure than it is, and which makes
the system more complex to implement.
Both were rejected by the authors of that spec.
> it is
> not a brainwallet that is only protected by the passphrase after all.
This ignores the history of that spec and the widespread use. Because
of the design, the check value can't be computed without a fixed
dictionary, and many people do use it as a brainwallet-- which is what
that BIP originally specified, in fact.
prev parent reply other threads:[~2016-07-27 20:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 18:31 millibitcoin
2016-07-26 20:10 ` Jonas Schnelli
2016-07-27 10:39 ` Jochen Hoenicke
2016-07-27 10:53 ` Jonas Schnelli
2016-07-27 20:59 ` Gregory Maxwell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgS-ObNbkP2PN6y+xJaxFnaz0sTSYiafCzjMtUv0sHjtxg@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hoenicke@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox