Add serialization of account secret key #31
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: QPQ-AG/gmserialization#31
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "github/fork/davidyuk/secret-key"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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.
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
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.
Created by: dincho
I'd argue about consistency here:
account_prvkeyI agree with Dincho
Would
prvkeybe consistent with naming in this repo or the node? Or you mean in style ofpubkey? Maybe to name itseckey,scrtkey, orsecrkey?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
https://nacl.cr.yp.to/sign.html
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)
Created by: hanssv
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.
For a backend service (or an oracle) can serialized private key be stored along with other API tokens in production? I mean as a hot coin storage.
@dincho @loxs Let's agree on
sk_prefix,account_seckey.I don't have hard feelings here, I agree that consistency is good, but I see Denis' point too.
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): https://github.com/aeternity/aeternity/pull/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.
Created by: hanssv
Base64 are used for variable sized things base58 for fixed sized things...
@hanssv I'm switched it to base58 🙌
Created by: hanssv
Review: Approved
approved this merge request
Created by: dincho
test trigger CI?!
Merged by: uwiger at 2023-11-13 15:13:54 UTC