Skip to content

Conversation

@aqua
Copy link

@aqua aqua commented Nov 1, 2025

This is the same as #1045 but for the dev branch, since the README requested PRs against dev.

Original PR text:

Addresses issue #1044.

  • Stores the original seed during keygen
  • Adds get prv.seed CLI to obtain it
  • Adds set prv.seed to generate a new keypair from a seed chosen off-node (could be useful for devices without reliable entropy)
  • Reworks Identity::writeTo() to semantically explicit forms since the seed and the pubkey are the same length and can't be disambiguated soley via the size_t.

Our ed25519 library uses a representation of its key pair that
is incompatible with most modern implementations, which usually
work with the original 32-byte seed; Peters' impentation represents
the private key as the clamped sha512 of the seed.

This change:

- preserves the original seed when generating keys
- adds CLI commands to obtain the seed via `get prv.seed`,
under the same conditions as `get prv.key` is allowed
- adds support for `set prv.key` to supply a seed, in which
case the keypair will be re-generated from it.  This is
mostly to enable external key management using modern
libraries, but could also be of use on devices where
we don't have a trustworthy entropy source.

I split Identity::writeTo(uint8_t*,size_t) into explicit forms for
the thing being written; the original implementation wrote a
different thing depending on the length, which would be ambiguous
between pubkey and seed and cumbersome if it tried to return all
three in one long buffer. Identity::readFrom() did not have that
ambiguity problem because keys can't be set from pubkey alone,
though it might be preferable to split readFrom() up as well
and not use magic length values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant