Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#3,597 コメント 7 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c, cryptography
領域
networking, security

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C
スター
3.9k
フォーク
1.5k
平均マージ
1日 3時間
マージ済み PR（30日）
24

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

meshcore-dev/MeshCore のほかの issue

meshcore-dev/MeshCore の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。