Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Proposal: an open convention for signing channel messages (anti-impersonation + spam)

Ouverte
  • Quelque chose ne va pas ?
#3,597 7 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c, cryptography
Domaine
networking, security

Piste de recherche

The issue describes a proposed channel-message signing convention and links to draft spec PR #3598. Start by reviewing that draft and the discussion here, especially the proposed data type and domain tag. Done means the project settles whether to standardize signing and agrees on an interoperable format; implementation depends on that decision.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

On busy public channels there's nothing to stop someone posting under any name.
The sender name is just a text prefix on the message, no key attached, so as a
receiver you've no way to tell a genuine post from an impersonation. It also
makes spam hard to deal with: names and text get rotated every message, and the
one thing that doesn't rotate (the repeater a packet came in through) is shared
with everyone else nearby, so you can't filter on it without catching real
traffic.

I want to float a small signing convention for channel messages, and ideally
get it into the spec rather than leaving it as one app's private thing, so any
client or firmware verifies a signed message the same way.

What I've been doing: instead of changing the text message or stuffing the
signature inside it (that eats the payload and breaks older clients), the
signature rides in a separate companion packet on the same channel, a GRP_DATA
datagram in the dev data-type range. Anything that doesn't know about it just
ignores it, so the text stays full length and nobody who hasn't opted in sees a
difference. Costs one extra packet.

Companion packet payload (data_type 0xFFFF):

"MC1"   3 bytes    magic, identifies a signature packet v1
keyid   8 bytes    first 8 bytes of the signer's Ed25519 public key
ts      4 bytes    LE, the text message's timestamp (correlates the two)
sig     64 bytes   Ed25519 signature over the canonical input below

The verifier matches the packet to a recent channel text message on the same
channel with the same timestamp, then checks the signature.

Canonical signed input:

domain tag   ASCII string identifying the scheme/version
channel_hash 1 byte, sha256(channel_name)[0], binds the sig to the channel
ts           4 bytes LE
text         utf8 message text

Pure Ed25519, no pre-hash, same as advert signing, so the radio can do it with
the sign command that's already there and no private key ever leaves the device.
The channel_hash byte stops a signature being lifted and replayed on another
channel.

A signature on its own only tells you "whoever holds key X signed this", not
that key X is really the person named. The bit that closes that gap is pinning:
a client remembers the key it first sees for a name and warns if a later signed
message under that name turns up with a different key. The signature is what
makes a key worth pinning in the first place.

Where this helps with spam

Once a message carries a key you can verify, two things become possible that
aren't today. One, a verified-only view, so on a channel that's getting flooded
you show the posts that verify against a key you've pinned and set the rest
aside, without hard-blocking anyone or losing genuine messages. Two, you can
filter on the key instead of the name. That's the useful one: a name is free to
change, a key isn't, so muting a key actually holds and only ever affects that
one sender.

Why I think it belongs in the spec rather than per-app

There's at least one closed-source app already signing its channel messages,
which is good to see, but a private format only verifies inside that app, nobody
else can check the signatures or build against it, so it doesn't do anything for
the wider spoofing problem. If the format's agreed here, anyone can produce and
verify it and a signed message means the same thing across clients. What's above
is enough to implement it from scratch.

I've opened a PR with a draft of the spec doc to go with this: #3598. It's
working end to end already (radio signs with its own key, verify is a plain
Ed25519 check against the sender's advert key) and I can share sample packets.

Couple of things I'd want your steer on:

  • the data_type, 0xFFFF is just the dev range and a reserved value would be
    better for something standard
  • the domain tag string, which ought to be neutral rather than named after any
    one app

Mainly I want to know if there's appetite for signing in the spec at all, and if
so settle on one format so it interoperates instead of everyone rolling their own.

Langage dominant
C
Étoiles
3.9k
Forks
1.5k
Merge moyen
1 j 1 h
PR mergées (30 j)
26

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de meshcore-dev/MeshCore

Toutes les issues de meshcore-dev/MeshCore

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.