Closed ArvsIndrarys closed 5 years ago
I'm not very familiar with these - but my first thought is that publicKeyConvert should be analogous to me serialize_vec on the rust side, not from_slice
I'd wait for someone more familiar with the secret store to respond though (cc @grbIzl)
The thing is, Parity returns the correct Public Key that allows the Document key recuperation, which I can not do in JS. So either Parity wraps correctly the original secp256k1 C implementation and the others, not ( ethers-io/ethers.js for example), either that part is flawed and the code has been adapted to get the correct result from that flaw (perhaps the same way).
I don't expect the difference between serialize_vec
and from_slice
to be the problem.
I got no problem with secretKey.to_secp256k1_secret() that uses from_slice
.
I am adapting the full rpc shadow decrypt code and I got no problem until the key::PublicKey::from_slice()
method. Only that part gives me a different result than the bitcoin secp256k1 implementation.
The public keys looks the same, though coordinates are serialized differently. Public key is simply 2x serialized 256-bit numbers (x and y coordinates of a point on the SECP256k1 curve) and the 04
is simply tag that points to serialization format. Please mention that coordinates in JS and Parity are simply reversed. I.e. in JS x coordinate is 1cdd523dc2a4a81a6801504d60a00214e58248224ad075f32035d8dbc0a16027
and in Parity it is reverse-bytes(1cdd523dc2a4a81a6801504d60a00214e58248224ad075f32035d8dbc0a16027) = 2760a1c0dbd83520f375d04a224882e51402a0604d5001681aa8a4c23d52dd1c
. So either both libraries are compatible but are printing keys differently, or JS library expects some different format of the public key in its parse()
. You could try doing some math with your JS keys (like scalar * pub_key
) && check if result is the same (with regard to reverse-bytes()
) as in rust - if they're different, try parsing/creating public key in JS with reversing + probably without prefix tag.
Please reopen if you need more help. And thanks for your interest in secret store
I did not see the reverse_bytes
thingy !
My solution is working now, thanks @svyatonik !
cargo build --features secretstore --release
)Hi everyone,
my goal would be to interact with the Secret Store via JS. The environment of my setup would allow me to trust no-one, thus having all plain datas decrypted only on the Client Side.
I am using the Secret Store feature of document key shadow retrieval and avoid using the shadow_decrypt rpc call to an untrusteed node.
I would then need to implement that call in JS.But I don't understand one of the function calls :
( original code is here )
The struct above the
to_secp256k1_public
function is from StackOverflow and helps me debug the content of the array before it is modified by thekey::PublicKey::from_slice
call.I re-adapted this code in JS thanks to that part :
I get then these results :
[JS]
[Parity]
For Parity, the call
key::PublicKey::from_slice(&SECP256K1, &public_data)
comes from the parity-secp256k1 rust wrapper and calls the underlying secp246k1 C implementation from that code :For the JS, I am using the secp256k1-node wrapper that calls the underlying secp246k1 C implementation from that code :
I don't understand how Parity returns a public key THAT different from the entry, as it is already a correct public key, and the method called is
publicKeyConvert
.And how could I obtain the same result (2760a1c0dbd83520f375d04a224882e51402a0604d5001681aa8a4c23d52dd1c8bb4edd66260b3a4e7f08b8cd08269a7330d939faa41f9641e05ad1f5d2b1672) in JS?