search

helium / ecc_compact

Unpatented ECC point compression for NIST p-256 public keys
Other
8 stars 14 forks source link

secp256r1 public key recovery #7

Open mikekelly opened 4 months ago

mikekelly commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

madninja commented 4 months ago

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 https://github.com/helium/ecc_compact/issues/7#issuecomment-2104965336, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACZBSXME67PPBO26YW4UTZBT46NAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUHE3DKMZTGY . You are receiving this because you were mentioned.Message ID: @.***>

mikekelly commented 4 months ago

the library doesn't support point compression for r1?

mikekelly commented 4 months ago

sorry I meant specifically recovery for compressed r1 public keys

madninja commented 4 months ago

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 https://github.com/helium/ecc_compact/issues/7#issuecomment-2104993297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACZBQMU4WBPAJ2CWW2UETZBT7HFAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUHE4TGMRZG4 . You are receiving this because you were mentioned.Message ID: @.***>

mikekelly commented 4 months ago

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 commented 4 months ago

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 https://github.com/helium/ecc_compact/issues/7#issuecomment-2105010782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACZBUBK4WVNATNLEGRBNDZBUAYZAVCNFSM6AAAAABHQKIQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGAYTANZYGI . You are receiving this because you were mentioned.Message ID: @.***>

ke6jjj commented 4 months ago

@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 commented 4 months ago

yes, that's perfect - thanks @ke6jjj