Add keypair encoding, fix seckey size checks #57

2026-03-25T07:18:30+09:00

uwiger commented

2026-03-25 07:18:30 +09:00

A curious issue with account_seckey encoding was detected:

enacl secret keys can be either 32-byte or 64-byte, depending on whether they include the pubkey as an optimization
gmser_api_encoder:encode(account_seckey, Sec64Byte) would work, but the subsequent decode would fail.
Generally, encode/2 never bothered to check the payload size, but decode() did, which is backwards.
There was even an EUnit test that relied on this, using encode() to generate an illegal encoding, and then verifying that it couldn't be decoded.

This PR introduces size checks in encode(), which technically might be a compatibility break. For testing, encode_/2 works like the old encode/2, without checking size.
Also encode/decode of account_seckey now supports both 32-byte and 64-byte payload.

The new functions encode_keypair/1 and safe_decode_keypair/1 convert between an enacl keypair and one that the gajumaru config schema can handle. The decode verifies that the public and secret keys in fact match.

The usual caveats still apply that secret keys should remain secret (thus strictly not being good candidates for serialization) - but for testing, it is quite useful, and since we've gone down that road already, it would be nice to have the support be consistent and reasonably safe.

A curious issue with `account_seckey` encoding was detected: * enacl secret keys can be either 32-byte or 64-byte, depending on whether they include the pubkey as an optimization * `gmser_api_encoder:encode(account_seckey, Sec64Byte)` would work, but the subsequent decode would fail. * Generally, `encode/2` never bothered to check the payload size, but `decode()` did, which is backwards. * There was even an EUnit test that relied on this, using `encode()` to generate an illegal encoding, and then verifying that it couldn't be decoded. This PR introduces size checks in `encode()`, which technically might be a compatibility break. For testing, `encode_/2` works like the old `encode/2`, without checking size. Also encode/decode of `account_seckey` now supports both 32-byte and 64-byte payload. The new functions `encode_keypair/1` and `safe_decode_keypair/1` convert between an `enacl` keypair and one that the gajumaru config schema can handle. The decode verifies that the public and secret keys in fact match. The usual caveats still apply that secret keys should remain secret (thus strictly not being good candidates for serialization) - but for testing, it *is* quite useful, and since we've gone down that road already, it would be nice to have the support be consistent and reasonably safe.

uwiger added 1 commit 2026-03-25 07:18:30 +09:00

Add keypair encoding, fix seckey size checks

Gajumaru Serialization Tests / tests (push) Successful in -2m51s

Details

4f97dd1bd1

uwiger requested review from dimitar.p.ivanov 2026-03-25 07:18:31 +09:00

uwiger requested review from hans_sv 2026-03-25 07:18:31 +09:00

uwiger requested review from spivee 2026-03-25 07:18:31 +09:00

uwiger requested review from zxq9 2026-03-25 07:18:31 +09:00

uwiger added 1 commit 2026-03-26 06:09:19 +09:00

Add unsafe_encode/2 to forego size check

Gajumaru Serialization Tests / tests (push) Successful in -2m49s

Details

4cc6adee2e

uwiger merged commit 4698b54832 into master

2026-03-30 05:26:10 +09:00

uwiger referenced this issue from a commit

2026-03-30 05:26:12 +09:00

Merge pull request 'Add keypair encoding, fix seckey size checks' (#57) from uw-account_seckey into master

Sign in to join this conversation.

No Reviewers

dimitar.p.ivanov

spivee

zxq9

hans_sv

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/gmserialization#57