From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 11E842C for ; Wed, 27 Jul 2016 20:59:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3442AC for ; Wed, 27 Jul 2016 20:59:55 +0000 (UTC) Received: by mail-vk0-f47.google.com with SMTP id s189so18219269vkh.1 for ; Wed, 27 Jul 2016 13:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=db9pDsyPp73nT0kfOluOOXixJQ8G64Pi1NYSc+Q/wsQ=; b=rs94daD2lGt3p07FBTybVoKxdYQWYyJIJDBWOzqqZPBgK4zQgtw+KYvxCxF1In96Hl zALCuTww+pFbZQJKE9B/iGWwL2yPP2vAHPKsNZ3GNxFk9+a1pa1bvpeu1dLFDnf9+taZ ZNFBoGkKtnlilqc04YA84JTIRQm+QKfMKMnCA+W2uG/95YNmtHyNemDqr5+ZbtYA4owG kyaAoDyetBLJg5PTdD9L8gCiXA/MaphBIGe47bNDVRQ2Fv+SsMwXx5kwHlib2MmQhSMU YC6QvSq61F6XjLhYdR5YZ5+Lcdu1XMk2xGRyHtuFK3giOS6BU+0fBP7EvrCWHtgGVkXo Cxeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=db9pDsyPp73nT0kfOluOOXixJQ8G64Pi1NYSc+Q/wsQ=; b=bcT/0Ct3y9b+nOLJC6dECPdWgIxY63tQU2oCQPqIP+iAJUR31M6tgrHDDcuVhcCiJt PweZyy9X7NnreAPb4Fzk/SPyLLHFcr68QqNQrqXoRbrsxbS/u6ngjKRIGb9CJyV0ALiw n4QcS+SUGIDioJneVApAA7IzZBH2mKsRXRy932/taaQEtWnoQ1Bi4EM/JpQ7RceawemM L+SQ7X0gIKyDMExU9BlJp6ESLvbsa/3fFu0qUacLzV/TN2gWSI4OPQhox4wVxK+FNf8v MHwZEEuWtteY7joopJ0JMlOK8WIkuQfCuPsO3ofGJ4lRL9z+d1frgvVcnqM65O+qR8kB 0mJQ== X-Gm-Message-State: AEkoouvHn1V4JWzuxGG/5ot3eu2n4qDj7QJ6BR5SayZd6Jm51Brd/Mx8yDgB65o8qFSijUqxw25tdSBfqt5LHQ== X-Received: by 10.31.107.29 with SMTP id g29mr13902940vkc.56.1469653194856; Wed, 27 Jul 2016 13:59:54 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.118.9 with HTTP; Wed, 27 Jul 2016 13:59:54 -0700 (PDT) In-Reply-To: References: <5797AC88.8030507@gmail.com> <5797C3A7.5030600@jonasschnelli.ch> From: Gregory Maxwell Date: Wed, 27 Jul 2016 20:59:54 +0000 X-Google-Sender-Auth: dHxivtFTTyXm1bqPd2WZMyHBwMg Message-ID: To: Jochen Hoenicke , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP proposal: derived mnemonics X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 20:59:57 -0000 On Wed, Jul 27, 2016 at 10:39 AM, Jochen Hoenicke via bitcoin-dev wrote: > Jonas Schnelli via bitcoin-dev > 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.