[2.8.0] Clarify XEdDSA material on keygen-excluded identity restore

[RCGV1]

Problem

In builds with MESHTASTIC_EXCLUDE_PKI_KEYGEN but without MESHTASTIC_EXCLUDE_PKI, boot restores an existing 32-byte Curve25519 keypair through CryptoEngine::setDHPrivateKey() without first calling regeneratePublicKey(). The in-memory XEdDSA signing material is therefore not rebuilt.

Normal keygen-capable builds call regeneratePublicKey() before installing the private key and already derive this material. This issue is limited to the keygen-excluded restore path.

Decision needed

Confirm whether XEdDSA signing is expected to operate on keygen-excluded builds that restore an existing PKI identity. If yes, loading the valid persisted identity should rebuild its matching in-memory XEdDSA private/public material and a focused regression should cover that configuration. If not, the proposed fix should not proceed.

Related: #10966
Design: meshtastic/design#122

[RCGV1]

I am actively working on this fix and its regression coverage. This contributor account cannot self-assign the issue, so please treat this comment as the ownership claim.

[jp-bennett]

I don't immediately see a code path where this is a problem, though it's quite possible. Can we write a test case that currently fails, that demonstrates this problem?

[RCGV1]

Reproduction is now covered by a focused native crypto regression:

void test_XEdDSA_persisted_private_key_reload(void)
{
    uint8_t curvePublic[32], persistedPrivate[32];
    uint8_t expectedEdPrivate[32], expectedEdPublic[32];
    crypto->generateKeyPair(curvePublic, persistedPrivate);
    XEdDSA::priv_curve_to_ed_keys(persistedPrivate, expectedEdPrivate, expectedEdPublic);

    CryptoEngine firstLoad;
    CryptoEngine secondLoad;
    firstLoad.setDHPrivateKey(persistedPrivate);
    secondLoad.setDHPrivateKey(persistedPrivate);

    TEST_ASSERT_EQUAL_MEMORY(expectedEdPrivate, firstLoad.xeddsa_private_key, sizeof(expectedEdPrivate));
    TEST_ASSERT_EQUAL_MEMORY(expectedEdPublic, firstLoad.xeddsa_public_key, sizeof(expectedEdPublic));
    TEST_ASSERT_EQUAL_MEMORY(firstLoad.xeddsa_private_key, secondLoad.xeddsa_private_key, sizeof(expectedEdPrivate));
    TEST_ASSERT_EQUAL_MEMORY(firstLoad.xeddsa_public_key, secondLoad.xeddsa_public_key, sizeof(expectedEdPublic));

    const uint8_t payload[] = "persisted identity";
    uint8_t signature[XEDDSA_SIGNATURE_SIZE];
    TEST_ASSERT_TRUE(firstLoad.xeddsa_sign(0x12345678, 0xABCDEF01, 1, payload, sizeof(payload), signature));
    TEST_ASSERT_TRUE(secondLoad.xeddsa_verify(curvePublic, 0x12345678, 0xABCDEF01, 1, payload, sizeof(payload), signature));
}

Observed result:

• Current develop (8abae9083) plus this test: fails at the first XEdDSA private-key comparison because the freshly loaded engine still contains zeroed signing material.
• With 65af8eb2761f363078387bc75aed533355b4c7b9: passes, including signing with one fresh load and verification with a second fresh load.

The regression is in test/test_crypto/test_main.cpp and is registered in the existing native crypto suite.

[jp-bennett]

In practice, I believe this code path is only hit when MESHTASTIC_EXCLUDE_PKI_KEYGEN is defined. In real firmware, we always call regeneratePublicKey() first, unless that define is present.

And honestly, I'm not sure how to handle a device that can't generate a pubkey, as the edkey is always derived via a generation step.

[RCGV1]

Confirmed. In the normal PKI-keygen path, NodeDB::generateCryptoKeyPair() calls regeneratePublicKey() before setDHPrivateKey(), which already derives the XEdDSA material.

The direct boot-time setDHPrivateKey() path is the #elif !(MESHTASTIC_EXCLUDE_PKI) branch selected when MESHTASTIC_EXCLUDE_PKI_KEYGEN is defined. That branch restores a persisted 32-byte Curve keypair and node number without a public-key regeneration step.

So the regression demonstrates the missing invariant for the keygen-excluded configuration, not normal keygen-capable boot. If XEdDSA signing is not intended for that configuration, I should close the draft PR; if it is intended, I will narrow the PR and regression explicitly to that supported restore path. Which behavior do you prefer?