ECPoint compressed state and 1.64

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ECPoint compressed state and 1.64

Andreas Schildbach
When trying to migrate from BC 1.63 to 1.64, which was advertised as a
security release, I noticed compressed state has been removed from ECPoint.

I see two problems:

- If I'm not mistaken, this breaking change hasn't been documented in
the release notes.
- Putting breaking changes into a security release is detrimental to
quick rollout of the respective security fixes.

I understand that we should only use compressed pubkeys. However in
reality lots of uncompressed pubkeys are out in the wild and we still
need to interoperate with them. In the case of Bitcoin, they're frozen
into the blockchain. What's the recommended migration path for apps that
still need to deal with uncompressed keys?


Reply | Threaded
Open this post in threaded view
|

Re: ECPoint compressed state and 1.64

Peter Dettman-3
Hi Andreas,
Could you explain what the immediate issues are with upgrading? It
sounds like there might be a misunderstanding about what changed.

The fundamental change was the removal of a (long deprecated) mechanism
where an ECPoint would remember whether it was decoded from a compressed
point encoding, and then default to that same format when
ECPoint.getEncoded() was called.

We still support decoding end encoding of both compressed and
uncompressed points, however when encoding the caller must indicate
whether they want a compressed point encoding using the argument to
ECPoint.getEncoded(boolean).

Regards,
Pete Dettman


On 21/10/19 7:15 pm, Andreas Schildbach wrote:
> I understand that we should only use compressed pubkeys. However in
> reality lots of uncompressed pubkeys are out in the wild and we still
> need to interoperate with them. In the case of Bitcoin, they're frozen
> into the blockchain. What's the recommended migration path for apps that
> still need to deal with uncompressed keys?
>
>


Reply | Threaded
Open this post in threaded view
|

RE: ECPoint compressed state and 1.64

Huy Sy Doi
Hi,
Is this topic related to our request for "Replacing references from Jsse.jar"?

Thanks,


Huy Sy Doi
Manager, Engineering
Kofax Vietnam Co. Ltd.
521 Kim Ma Street, 11 Fl., A Tower, RESCO Building, Ba Dinh District
Hanoi
Vietnam
Tel: +84 4 6254 5558
Mobile: +84 913 567 909
Fax: +84 4 3771 2543
 [hidden email]-----Original Message-----
From: Peter Dettman [mailto:[hidden email]]
Sent: Tuesday, October 22, 2019 11:24 AM
To: [hidden email]
Subject: Re: [dev-crypto] ECPoint compressed state and 1.64

Hi Andreas,
Could you explain what the immediate issues are with upgrading? It sounds like there might be a misunderstanding about what changed.

The fundamental change was the removal of a (long deprecated) mechanism where an ECPoint would remember whether it was decoded from a compressed point encoding, and then default to that same format when
ECPoint.getEncoded() was called.

We still support decoding end encoding of both compressed and uncompressed points, however when encoding the caller must indicate whether they want a compressed point encoding using the argument to ECPoint.getEncoded(boolean).

Regards,
Pete Dettman


On 21/10/19 7:15 pm, Andreas Schildbach wrote:
> I understand that we should only use compressed pubkeys. However in
> reality lots of uncompressed pubkeys are out in the wild and we still
> need to interoperate with them. In the case of Bitcoin, they're frozen
> into the blockchain. What's the recommended migration path for apps
> that still need to deal with uncompressed keys?
>
>




-------------------------------------------------

This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately.
Reply | Threaded
Open this post in threaded view
|

Re: ECPoint compressed state and 1.64

Andreas Schildbach
In reply to this post by Peter Dettman-3
The immediate problem is the changed API, for which we have to find
other solutions before upgrading to the security release.

Bitcoinj uses the ECPoint class to track the compression state of
pubkeys. The reason is Bitcoin addresses are a hash of their encoded
pubkey, so you get a different address wether you derive it from
compressed or uncompressed encoding. Since the payer pays to an address,
this state is relevant for if you can receive your money or not.


I'm already working on tracking compression state ourself, see
https://github.com/bitcoinj/bitcoinj/pull/1941
However due to regression potential of the these changes this can only
go to master, so the current release branch is stuck at BC 1.63.


On 22/10/2019 06.24, Peter Dettman wrote:

> Hi Andreas,
> Could you explain what the immediate issues are with upgrading? It
> sounds like there might be a misunderstanding about what changed.
>
> The fundamental change was the removal of a (long deprecated) mechanism
> where an ECPoint would remember whether it was decoded from a compressed
> point encoding, and then default to that same format when
> ECPoint.getEncoded() was called.
>
> We still support decoding end encoding of both compressed and
> uncompressed points, however when encoding the caller must indicate
> whether they want a compressed point encoding using the argument to
> ECPoint.getEncoded(boolean).
>
> Regards,
> Pete Dettman
>
>
> On 21/10/19 7:15 pm, Andreas Schildbach wrote:
>> I understand that we should only use compressed pubkeys. However in
>> reality lots of uncompressed pubkeys are out in the wild and we still
>> need to interoperate with them. In the case of Bitcoin, they're frozen
>> into the blockchain. What's the recommended migration path for apps that
>> still need to deal with uncompressed keys?
>>
>>
>
>
>