小ネタ:ed25519秘密鍵公開鍵とJson serialized canonical

2026/1/21 [14:51:21] (水) 天気

あちこちに散らばるとモノを探すだけのために時間を使っちゃうことになるんで、こっちにメモ。


【ED25519秘密鍵と公開鍵の作成】


opensslを使って作成する。RSAなどと同じ。


Linux Mint 22.3で作成

opensslのバージョン

OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)


まず秘密鍵を作る

openssl genpkey -algorithm ed25519 -out ed25519-sercret.key

作った秘密鍵を使って公開鍵を作る

openssl pkey -in ed25519-secret.key -pubout -out ed25519-pub.key


ActivityPubでActivityとObjectの署名に使える予定らしい

https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md


これをAcitvityPubのJSONで使うにはこのままではなくて、さらにpublicMultibase形式に変換する必要があるらしい

・BEGIN PUBLICK KEYとEND PUBLIC KEYの接頭辞を削除

・改行を削除

decode_base64でバイナリデータに戻して、base58形式に変換して使うとのこと。


pem形式からpublicMultibase形式に変換してJSONに登録

署名する時はpublicMultibase形式からpem形式に戻して署名

検証する時も同じことを…って、すげー手間だな、これ。


【Json serialized canonical】


ActivityPubの本体のJSONを対象に署名する必要がある。


現状2種類あるらしい。

・Mastodonが実装している Linked Data Signatures

https://docs.joinmastodon.org/spec/security/#ld

・FEP-8b32 で提案されている Integrity proofs

https://amasecocoa.github.io/fep/8b32/


Mastodonが採用してるやつは古い仕様で、公式自体が非推奨だし、複雑怪奇の伏魔殿。かかわりたくない。

FEP-8b32がこれから使われると思うけど、これはこれで現在仕様検討のdraft状態で現状の決定ではない。


将来的にFEP 8B32になると想定して検討するとして、やっぱり具体的に署名対象ってどれで、それをどうすんの問題。


ActivityのJSONをcanonicalしてserializeしたものを対象にする、とのこと。

なにそれ?だったんだけど「日本語でどうぞ」だった。


canonical

→キーを辞書順に並べる

serialize

→文字列にする

※改行や空白、インデントなどは不要なので削除


perlのJSONの場合は

$json=JSON->new->canonical(1)->utf8(1)->indent(0)->space_before(0)->space_after(0)

で、OKのようだ。

ただ、perlの場合「0.00」というのが文字列の「0」になるんで、数値をそのまま数値として使うには「var+=0」などと明示的に数値にする必要がある、らしい。



【オチ】


ここまでダラダラとメモったのは、ActivityPubで本体に署名をするため。

本体に署名されていれば、本体の改竄検知に利用できるから。

これに対応することで、Mastodon系などはメンションの時に「転送」することができる。


いわゆる「ゴーストリプライ」問題の対応。

とはいえ、転送しなくてもAnnounceすれば同じこと。どっちで問題解決する?という程度の話だろう。


それより、この本体署名をつけることをMUSTにするには問題があると思っていて。

署名を認証するためには「公開鍵」が必要。actor(アカウント)が削除されたら「公開鍵」を取得できない。

(ActivityPubの仕様的に「転送」はMUSTだけど、本文署名は仕様にはないからややこしいんだけど)


なので、公開鍵はアカウントが削除された後もキャッシュされたりサーバーが一定期間保持したりするらしい。


「公開鍵」を取得できることが大前提。


いつまでキャッシュ・保持しなきゃいけないの?と言われても答えられないはず。本体に署名をつける意味ある?ということになるんじゃないかな。

Misskey系のパッケージは本体署名に対応してないんだけど、むしろこっちの方が合理的かもしれない。


様子見するけど、これって対応する必要がないと思ったなあ。どうなんだろ…

image

<<2026/1>>
    123
45678910
11121314151617
18192021222324
25262728293031
検索:

【最近の20件】