public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pavol Rusnak <stick@gk2.sk>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] BIP32 - invalidation
Date: Fri, 08 Aug 2014 15:19:38 +0200	[thread overview]
Message-ID: <53E4CE6A.5070609@gk2.sk> (raw)

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 <stick@gk2.sk>



             reply	other threads:[~2014-08-08 13:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 13:19 Pavol Rusnak [this message]
2014-08-10  0:34 [Bitcoin-development] BIP32 - invalidation second isogeny
2014-08-10  1:20 ` Eric Lombrozo

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=53E4CE6A.5070609@gk2.sk \
    --to=stick@gk2.sk \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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