Skip to content

Use the authoritative key on the PKI decrypt path #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
caveman99 wants to merge 1 commit into from
Closed

Use the authoritative key on the PKI decrypt path #26

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions src/mesh/Router.cpp
View file
Open in desktop

@NomDeTom NomDeTom Jul 21, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which intention is more important here:

  1. making sure to use an authenticated PKI not TOFU (TOFU is still accepted from hot & warm stores)
  2. making sure to avoid an extended search in the ephemeral store

If 1, we can gate the ephemeral key use to authoratative keys only (evicted hot/warm store that have been authenticated previously)

If 2, we can use NodeDB::copyPublicKey (not confirmed - clod suggested that)

Interestingly this did make me realise we call the same thing 3 names:

hot: nodeInfoLiteHasXeddsaSigned
warm: isVerifiedSigner
cache: keySignerProven

@NomDeTom NomDeTom Jul 21, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addendum: keySignerProven is a double-role: manually verified or a xeddsa signer

Original file line number Diff line number Diff line change
Expand Up @@ -624,13 +624,13 @@ DecodeState perhapsDecode(meshtastic_MeshPacket *p)
meshtastic_NodeInfoLite *ourNode = nullptr;
if (p->channel == 0 && isToUs(p) && p->to > 0 && !isBroadcast(p->to) && rawSize > MESHTASTIC_PKC_OVERHEAD &&
(ourNode = nodeDB->getMeshNode(p->to)) != nullptr && ourNode->public_key.size > 0) {
// Resolve the sender's public key only for actual PKI-decrypt candidates: prefer NodeDB
// (hot store or warm tier), else a not-yet-committed key held during an in-progress
// key-verification handshake. On a full NodeDB miss, copyPublicKey() falls through to a
// linear scan of TrafficManagement's large NodeInfo cache, so it must not run for every
// encrypted channel packet from an unknown sender - only for packets we might decrypt.
// Resolve the sender's public key only for actual PKI-decrypt candidates. Use
// copyPublicKeyAuthoritative (hot store or warm tier only), not the opportunistic
// copyPublicKey: authenticated DM attribution (pki_encrypted, p->from) must rest on
// authoritative keys, never on the ephemeral TOFU TrafficManagement NodeInfo cache. A
// not-yet-committed key from an in-progress key-verification handshake is tried below.
meshtastic_NodeInfoLite_public_key_t remotePublic = {0, {0}};
bool haveRemoteKey = nodeDB->copyPublicKey(p->from, remotePublic);
bool haveRemoteKey = nodeDB->copyPublicKeyAuthoritative(p->from, remotePublic);
// A pending key is an unverified identity claim supplied by whoever opened the handshake, so it is
// accepted only for the exchange itself (checked after decode). perhapsEncode applies the same rule.
bool havePendingKey = false;
Expand Down