From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XFkX4-0003DI-Ji for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 13:48:34 +0000 X-ACL-Warn: Received: from mail-wg0-f45.google.com ([74.125.82.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XFkX2-0002Ms-DJ for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 13:48:34 +0000 Received: by mail-wg0-f45.google.com with SMTP id x12so5685897wgg.16 for ; Fri, 08 Aug 2014 06:48:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=cZihI8IGGoXwzmIr6tEXtUHSsFEOh9MOulWFAepWQVE=; b=aKOjI0VtxOYwBw3O4G+We4AKOJYgL68MplnY2fPIDgBCBfw3T2eDDlwGBYfocOLV7k 7rFOkqcNHtnE5Q/1lym0gAoAVQ+lPnWYvFTvxjBh898UMj/dUKKG7Ke3Nh/EHrOJRGzx SQq0xAj3Ug4COqnVfwxezihm82Z83WvjuojFgtksmCNQEDtBkoLb0h/1xI2rmmLeRXvr e7nX4empbI5wn687NbyRhrw+p7k5UWScvc5j6/of7NFhQVeR4sDn1mVbPdNAzIQmyWja xkLcLdZhu58skmepa8tloqwidDdjB6lx2Puq92dL9dscvwyioO5r6cGTr8zUARpzeYJY wKPQ== X-Gm-Message-State: ALoCoQnTCvY8VsxAqK2471o143REpanMSQZYZkgl6mg3MO6q5/7Ai2P615CYFO1U3t0H+Vl4Lj2q X-Received: by 10.194.134.70 with SMTP id pi6mr32647198wjb.1.1407503981596; Fri, 08 Aug 2014 06:19:41 -0700 (PDT) Received: from tetra.site (nat-0-15.lam.cz. [80.92.242.254]) by mx.google.com with ESMTPSA id dc3sm7154136wib.9.2014.08.08.06.19.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 06:19:39 -0700 (PDT) Message-ID: <53E4CE6A.5070609@gk2.sk> Date: Fri, 08 Aug 2014 15:19:38 +0200 From: Pavol Rusnak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bitcoin Dev X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1XFkX2-0002Ms-DJ Subject: [Bitcoin-development] BIP32 - invalidation 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: Fri, 08 Aug 2014 13:48:34 -0000 Hi all! I would like to discuss invalidation of nodes in BIP32. Currently the document says: a) Public CKD In case I_L >= n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. b) Private CKD In case I_L >= n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i. c) Master Key Generation In case IL is 0 or I_L >= n, the master key is invalid. (All these cases have probability lower than 1 in 2^127.) What do you think about the following change for all 3 cases: In case I_L >= n assign I_L := I_L mod n. Rationale: It's easy to say "mark as invalid and proceed with next", but actually most of the implementations don't do the checking at all, because tjen it's rather hard at application level to implement skipping logic. OTOH it's quite straightforward to perform modulo if needed, so we probably see more implementations doing the checking. We would still need to deal with cases when I_L = 0 or ki = 0 or ki = inf, but these have probability around 1 in 2^255. Does anyone see any concerns when it comes to security of the proposed change? -- Best Regards / S pozdravom, Pavol Rusnak