From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wu44W-0006Bi-Jc for bitcoin-development@lists.sourceforge.net; Mon, 09 Jun 2014 18:13:28 +0000 X-ACL-Warn: Received: from mail-ig0-f177.google.com ([209.85.213.177]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wu44V-0002X9-84 for bitcoin-development@lists.sourceforge.net; Mon, 09 Jun 2014 18:13:28 +0000 Received: by mail-ig0-f177.google.com with SMTP id l13so4160815iga.10 for ; Mon, 09 Jun 2014 11:13:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=XYAkG1hIAfMJ9Tg3Z+UG5uIcFj5U95cOMcPofvt/Ht0=; b=fKwZtaUWD6avGY3OKo+04BaQT6FRA6bU48WfNClblbieb8VShC7nZzNArx5+NCv2HE W7ig1aedUtWkHXYtp72TI1smW6d7z4+K99Q7Kmb+Rnky2KM21hmMLLoSGGyIDrlaGQPC zJydkfFZZHqoisDGVbdn7Fka9E/n0DiWYD9eGkuEa1E4b5IXrKoJ20WNe17xKYeKeDqJ r+KYjA/2bbmRK7YuKEMxlHlyNeR5Ie4jbtz3tGd1zNAr7dhoiiGrHCao6LZtnyeUtIy6 ESXjcaTkn3bbNscti0LgyfPVtsPHR8KckDwpyiZGWiN1e6VN2MgQ9QexWVAQ+y962TBP 2aYg== X-Gm-Message-State: ALoCoQnQ/8Cu5KWgdMFHbAyB0+2UQaGUqG75Yl5YHElic7PZJMHrTRCd6YsRHhYJ+b+Tos/8SPzh X-Received: by 10.42.88.135 with SMTP id c7mr21464030icm.46.1402337601328; Mon, 09 Jun 2014 11:13:21 -0700 (PDT) Received: from [192.168.2.22] (bas5-toronto47-2925108535.dsl.bell.ca. [174.89.157.55]) by mx.google.com with ESMTPSA id j3sm58197169igx.8.2014.06.09.11.13.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 11:13:20 -0700 (PDT) From: Richard Moore Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 9 Jun 2014 14:13:19 -0400 To: Bitcoin Dev Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Wu44V-0002X9-84 Subject: [Bitcoin-development] BIP38 Encrypted Address Discussion X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:13:28 -0000 Hey all again, I am implementing BIP38 wallets right now, and had another idea I would = like to put out there for discussion. Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was = wondering if it would make sense to include an extra byte in the address = which would encode the parameters used? For now, they are fine, as it = takes over 3 minutes to to hash once in my pure-Python implementation in = CPython (3 seconds in pypy). But with all the latest scrypt mining ASICS = hitting the market, and the difficulty rising of the scrypt alt coins, = it may become more profitable in the future to try hacking wallets to = gobble up their funds. Currently all the hardware is tuned for (1024, 1, = 1) and with adaptive-N, it only targets upgrading the N value, so having = p =3Dr =3D 8 certainly means that hardware won=92t affect BIP 38=85 But = who knows in the future if they start making Adaptive-N-r-p ASICS. It also provides a way to vastly secure more important master keys=85 = Maybe for a key that is cold storage of millions of dollars that won=92t = be touched for multiple years, I don=92t mind waiting an hour on = commodity hardware to decrypt it. I was thinking, for example, if we used 1 byte, c, we could use a = formula: N =3D 2 ** (c + 11) r =3D 2 ** c p =3D r Although, even a full byte is overkill=85 Maybe we can use the top three = bits for something else? With 5 bits, the space becomes: c =3D 0 =3D> (1024, 1, 1) (same as scrypt mining, albeit requires twice = the dkLength) c =3D 3 =3D> (16384, 8, 8) (current specs) c =3D 31 =3D> (2199023255552,2147483648, 2147483648) (highest = difficulty, requiring (5.6 * 10 ** 12) Gigabytes of memory per hash) Anyways, just thinking out loud=85 I think even this space is too large=85= We could also use the top 5 bits for N and lower 3 bits of r, p, if = more granularity seems more useful (maybe somebody *wants* their = passwords easy to parallelize but still difficult to break?) N =3D 2 ** (10 + ((c >> 3) & 0x1f)) r =3D p =3D 2 ** ((c & 0x07) * 3) Would put N =3D [1024, 2048, ..., 2199023255552] and r =3D p =3D [1, 8, = 64, 512, ..., 2097152] The biggest issue would be backwards compatibility. The 6P should = obviously stay the same, as it =93requires something extra=94 and the = thing required is a passphrase. But maybe we could use one of the = reserved bits to indicate that the address is adaptive? The decoded = length of the address will also change though, which could pose issues = if, for example, bounds checks aren=92t being done (bad, but it happens) = or in the case of things like python implementations, might assume the = length correct an use derived_half2 =3D decoded[23:] which would now = come back with the last byte of derived_half1 and be one byte too long, = unchecked, passed into AES, an exception is raised because it is not one = 16-byte block. These however seem assumptions that the developer should = guard against. This would retain backward compatibility though, as without the adaptive = bit set, new and old implementations can decode the address fine (new = implementations assuming c =3D 3); new implementations can detect the = adaptive bit and select the correct kdrf parameters. old implementations = on adaptive addresses would hopefully fail upon seeing the length is = wrong or that the reserved bits are not 0, otherwise the checksum should = fail=85 But if it does by some 1 in 4 billion chance match, the wallet = may successfully import a newly created private key and address=85 Does = this seem likely, or are current implementations ensuring the decoded = length and bits are set to 0? Otherwise, we *could* if all else fails, use =936A=94 for adaptive, or = =936p=94=85 But I don=92t really like polluting the namespace for a = minor tweak. Randomly, RicMoo .=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`= =B7.=B8=B8.=B7=B4=AF`=B7.=B8><(((=BA> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes.com www: http://GeneticMistakes.com