Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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.

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

[Feature Request]: Generate node ID out of public key #5006

Closed
contra-bit opened this issue Oct 9, 2024 · 0 comments
Closed

[Feature Request]: Generate node ID out of public key #5006

contra-bit opened this issue Oct 9, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@contra-bit
Copy link

contra-bit commented Oct 9, 2024

Platform

Cross-Platform

Description

I'd like to propose creating the node ID (aka node number) out of the public key,
similar to how software like Tor and SSH handle it. This would allow users to
choose whether a factory reset node should appear as new or retain its old
identity.

Currently, the node ID is generated from the MAC address, which leads to
issues when a node is reset and a new public and private key pair is
generated without warning. This causes PKI mismatches and prevents
functions like updating the position or getting a new node name.

By generating the node ID from the public key, users can choose to back up
their private and public keys and restore them after a factory reset,
allowing the device to retain its identity on the network. If the keys are
not restored, the device will appear as a new node.

This approach also solves a a privacy concern, as it allows users to appear
as a new device on the network if they choose to.

It's essential to inform users about the importance of backing up their keys,
as mentioned in Feature Request #272. This should be done in a secure and
user-friendly way, such as prompting the user to download or print a copy of
their private keys.

Regarding the open points in Feature Request #272 Prepare for PKI & Config Updates:

Display message when others in conversation change their key.

Tying the node ID the public key, will minimize the risk of a user resetting their node.
The chance of a user accidentally messing up their public key is minimized.

Allow user to forget node, allowing it to rejoin with new key

This can be implemented by adding an option to
"forget" a node, which would remove the node's public key and any
associated data such as the node id from the local device.
Rejoining the network, with a different public key and the same node id, will not be possible.
This will be the same as deleting a node. If the user wants to keep the node, he will restore his keys.

Here's a possible implementation:

  • When generating a new node ID, use a hash of the public key instead of the MAC
    address.
  • Provide an option for users to choose whether a factory reset node should
    retain its old identity or appear as new. (This would create a backup of the private and public keys and update the node, after the factory reset).
  • Document the process of adding multiple remote management keys and the
    implications of adding only the key of a remote device.
  • Implement notifications for key changes in conversations.
  • Implement the "forget node" option.

This feature would improve the overall security, privacy, and user experience
of the Meshtastic network. It addresses the issues mentioned in Feature
Request #272 Prepare for PKI & Config Updates and #281 Prompt User to download PKI keys for backups, and provides a more robust and user-friendly PKI
system.

Relevant issues

@contra-bit contra-bit added the enhancement New feature or request label Oct 9, 2024
@meshtastic meshtastic locked and limited conversation to collaborators Oct 9, 2024
@thebentern thebentern converted this issue into discussion #5007 Oct 9, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant