public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] BIP32 - invalidation
@ 2014-08-10  0:34 second isogeny
  2014-08-10  1:20 ` Eric Lombrozo
  0 siblings, 1 reply; 3+ messages in thread
From: second isogeny @ 2014-08-10  0:34 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

> Does anyone see any concerns when it comes to security of the proposed
> change?

Yes.  This proposal is less secure.

It is incompatible in theory with existing implementations of the
specification.  The incompatibility is also a potentially a security
problem because it may cause users to believe a key is worthless when
it is not or to lose funds when they are unable to spend them.

It is also an untimely proposal and would be inconsiderate other parties
who have done the work to produce correct and compatible implementations.

> In case I_L >= n assign I_L := I_L mod n.

This will make the selection of private keys uneven.

The unevenness is small and it is unlikely to very matter much but it
is objectively less secure.  Future advances in cryptography may make
the distinction more important.  The change would eliminate any hope of
the specification ever having provable security equal to random keys.

The bignum modulo operation also requires complex additional logic and is
just as likely to remain untested in implementations, though unit-testing
can test these cases by replacing the hash function.

Because of layering no suitable modulo may be available and an incorrect
implementation could create a devastating weakness, like reflecting a
large class of keys to a small number of values.  A similar error would
be unlikely for an incorrect implementation of skipping and someone who
managed to still fail would likely have failed either way.

> 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

There are many corner cases which must be handled in cryptographic
software.

You must handle the point at infinity cases, you must handle the signature
having a value of zero (or you leak the private key), in the point
arithemetics you must handle the special case of adding colinear points.

If someone is unprepared to deal with these and many other complications
they may want to leave writing this kind of software for other people.

[-- Attachment #2: Type: text/html, Size: 2263 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [Bitcoin-development] BIP32 - invalidation
@ 2014-08-08 13:19 Pavol Rusnak
  0 siblings, 0 replies; 3+ messages in thread
From: Pavol Rusnak @ 2014-08-08 13:19 UTC (permalink / raw)
  To: Bitcoin Dev

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>



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-08-10  1:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-10  0:34 [Bitcoin-development] BIP32 - invalidation second isogeny
2014-08-10  1:20 ` Eric Lombrozo
  -- strict thread matches above, loose matches on Subject: below --
2014-08-08 13:19 Pavol Rusnak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox