secp256r1 public key recovery

[mikekelly]

Hi there, I'm confused about how this library works. It looks like accurate recovery is implemented for secp256k1 via recover_compressed_key which includes the odd/even byte, but secp256r1 can't be accurately recovered because the function only takes the raw X coordinate via recover_compact_key without the odd/even byte and therefore can't know which Y coordinate is the public key. Is there a specific reason that this library has that limitation?

[madninja]

the standard allows for even/odd compression as a feature, but compact keys are a different feature. It allows the Y co-ordinate to be recovered from the X coordinate. See here.

[mikekelly]

hi @madninja, yes that makes sense - I was wondering why you chose to support only k1 for compressed and r1 for compact?

[madninja]

because point compression is standard and we wanted compact encoding for only the one type.. k1 is not used much

…

On Fri, May 10, 2024 at 12:05 PM Mike Kelly ***@***.***> wrote: hi @madninja <https://github.com/madninja>, yes that makes sense - I was wondering why you chose to support only k1 for compressed and r1 for compact? — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACZBSXME67PPBO26YW4UTZBT46NAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUHE3DKMZTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mikekelly]

the library doesn't support point compression for r1?

[mikekelly]

sorry I meant specifically recovery for compressed r1 public keys

[madninja]

this ecc_compact library is not a generic point compression library.. (hence the name)... we really only use it for compaction

…

On Fri, May 10, 2024 at 12:25 PM Mike Kelly ***@***.***> wrote: sorry I meant specifically recovery for compressed r1 public keys — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACZBQMU4WBPAJ2CWW2UETZBT7HFAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUHE4TGMRZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mikekelly]

understood - I was suprised to see there was support for compression, it's just confusing why this was added with only support for k1. Wondered if there was some specific reason why

[madninja]

the details of exactly why are lost in history :-) I remember us doing some experimenting with k1 but I really don't recall where it ended up

…

On Fri, May 10, 2024 at 12:38 PM Mike Kelly ***@***.***> wrote: understood - I was suprised to see there was support for compression, it's just confusing why this was added with only support for k1. Wondered if there was some specific reason why — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACZBUBK4WVNATNLEGRBNDZBUAYZAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGAYTANZYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ke6jjj]

@mikekelly This library was originally developed for the Helium blockchain, where only secp256r1 and ed25519 were used, and even then, secp256r1 was only used for compact keys for the specific reason that point compression was something the developers wanted to avoid putting in the library.

Much later, when it looked like the Certicom patents around point compression had safely expired, and when there was some discussion about allowing the chain to recognize secp256k1 keys in order to help create transaction bridges to other blockchains, I added secp256k1 support, complete with point compression/decompression routines, as an experiment. Even with this addition there was no need to back-port the point compression support to secp256r1 as no one was planning for the blockchain to change to support it.

Hopefully that explains the history a bit better.

[mikekelly]

yes, that's perfect - thanks @ke6jjj