Add serialization of account secret key #19
Conversation
src/aeser_api_encoder.erl
Outdated
| @@ -191,6 +192,7 @@ type2enc(oracle_query) -> ?BASE64; | |||
| type2enc(oracle_query_id) -> ?BASE58; | |||
| type2enc(oracle_response) -> ?BASE64; | |||
| type2enc(account_pubkey) -> ?BASE58; | |||
| type2enc(account_secret_key) -> ?BASE64; | |||
There was a problem hiding this comment.
I propose to use BASE64 as it is a low-level thing don't be needed to handle by users in everyday life. Though I'm fine to use BASE58.
src/aeser_api_encoder.erl
Outdated
| @@ -219,6 +221,7 @@ type2pfx(oracle_query) -> <<"ov">>; | |||
| type2pfx(oracle_query_id) -> <<"oq">>; | |||
| type2pfx(oracle_response) -> <<"or">>; | |||
| type2pfx(account_pubkey) -> <<"ak">>; | |||
| type2pfx(account_secret_key) -> <<"sk">>; | |||
There was a problem hiding this comment.
Using "secret" instead of "private" to have less visual overlap with "public", also this is consistent with naming in tweetnacl https://www.npmjs.com/package/tweetnacl
There was a problem hiding this comment.
I'd argue about consistency here: account_prvkey
There was a problem hiding this comment.
Would prvkey be consistent with naming in this repo or the node? Or you mean in style of pubkey? Maybe to name it seckey, scrtkey, or secrkey?
http://acronymsandslang.com/abbreviation-for/SECRET.html
https://www.allacronyms.com/secret/abbreviated
Would you rename prefix also to "pk"?
Here is one more example from original NaCl docs
unsigned char pk[crypto_sign_PUBLICKEYBYTES];
unsigned char sk[crypto_sign_SECRETKEYBYTES];There was a problem hiding this comment.
I don't have hard feelings here, I agree that consistency is good, but I see Denis' point too.
src/aeser_api_encoder.erl
Outdated
| @@ -275,6 +279,7 @@ byte_size_for_type(oracle_query) -> not_applicable; | |||
| byte_size_for_type(oracle_query_id) -> 32; | |||
| byte_size_for_type(oracle_response) -> not_applicable; | |||
| byte_size_for_type(account_pubkey) -> 32; | |||
| byte_size_for_type(account_secret_key) -> 32; | |||
There was a problem hiding this comment.
tweetnacl operates with 64-byte secret keys though half of it is a public key, we can safely drop it to reduce key size. Not sure if would it affect performance or so.
There was a problem hiding this comment.
While the public key can always be derived from the seed, the precomputation saves a significant amount of CPU cycles when signing.
https://doc.libsodium.org/public-key_cryptography/public-key_signatures#extracting-the-seed-and-the-public-key-from-the-secret-key
https://github.com/aeternity/protocol/blob/master/consensus/README.md#keys
in the most cases in can be computed once by app and cached 🤷♀️ 32 bytes would be easier to read in QR codes (if used in invite links)
|
No opinion about the format - just a reminder from the past. It is NOT an omission that there is no way to serialize a secret/private key... You should never be tempted to do it, except for possibly testing, you should not serialize and store a private key. |
|
Probably what Hans has in mind is that such services need to use aex3 wallet files in such cases. As always, the real world is a bit different, even the node gained this ability just recently (not merged yet): aeternity/aeternity#4171 The current state is that we put base64 encoded private keys in the node config file... (of course) My opinion is that we cannot escape from various people doing it and this PR is more good than bad (although it's a bit debatable). |
Where store the AEX-3 password then? (in case of a service, not a user) If you have a good place to store it then you can put the whole private key there. AEX-3 changes the situation only by splitting a secret key into two pieces, not sure how it can be useful. |
|
Base64 are used for variable sized things base58 for fixed sized things... |
|
@hanssv I'm switched it to base58 🙌 |
|
test trigger CI?! |
JS SDK misses a fancy way to serialize an account secret key. Currently, it uses a very long hex string representing 64 bytes. Would be good to define a more efficient and distinguishable way to encode account secret keys.
This PR is supported by the Æternity Crypto Foundation