ファイルのデジタル署名：真正性と出所を証明する

デジタル署名とは、特定の人物・組織がファイルを作成し、その後一切改ざんされていないことを暗号的に証明するものです。技術的には、ファイルを SHA-256 でハッシュ化し、そのハッシュを秘密鍵で「署名」します。使用するアルゴリズムは RSA-PSS・ECDSA・Ed25519 のいずれかです。公開鍵を持つ誰でも署名を検証でき、検証が通れば、そのファイルがあなたが作成したものであり、署名後にバイト単位で同一であることがわかります。macOS がアップデートを検証し、Git がコミットの著者を記録し（git commit -S）、PGP が署名付きメールを実現するのもこの仕組みです。暗号化だけでは解決できない問題、つまり「誰が何を送ったか」の証明を可能にします。

署名と暗号化の違い：それぞれの役割

暗号化は内容を秘密にします。署名は著者と整合性を証明します。補完的な役割であり、代替ではありません。

暗号化のみ：受信者は内容を知りますが、誰が送ったかはわかりません。公開鍵を持つ誰でも暗号化できます。
署名のみ：受信者は誰が送ったか、改ざんされていないかがわかりますが、傍受者にも内容が見えます。
署名 + 暗号化：真正性・整合性・機密性のすべてを実現。PGP のデフォルトモードです。

ファイル転送サービスは通常、暗号化に焦点を当てています。署名が必要になるのは高信頼コンテキスト、つまりソフトウェア配布・法的文書・契約書・法的証拠の連鎖です。

署名が実際に動作する仕組み

Ed25519 の標準的な署名フローは以下のとおりです。

メッセージをハッシュ化する：h = SHA-512(message)。
決定論的なナンスを計算する：r = SHA-512(private_key_prefix || h)。
署名点を計算する：R = r·G（G は曲線のベース点）。
s = r + SHA-512(R || public_key || h)·private_key mod ℓ を計算する。
署名は (R, s) で合計64バイトです。

検証は公開鍵・メッセージ・署名のみを使います。数学が成立すれば、署名が対応する秘密鍵を持つ人物によって生成されたことが確認できます。

RSA-PSS（PKCS#1 v2.2）と ECDSA も同様の仕組みですが、数学的な基礎が異なります。Ed25519 が新しいシステムで好まれる理由は、決定論的（署名ごとのランダムナンスが不要）で高速だからです。

3つの主要な署名アルゴリズムの比較

| アルゴリズム | 鍵サイズ | 署名サイズ | 速度 | 備考 | |-----------|----------|----------------|-------|-------| | RSA-PSS-2048 | 256バイト | 256バイト | 約1,000署名/秒 | 広くサポート、鍵生成が低速 | | ECDSA P-256 | 32バイト | 64バイト | 約30,000署名/秒 | NIST 曲線、署名ごとに安全な RNG が必要 | | Ed25519 | 32バイト | 64バイト | 約50,000署名/秒 | 決定論的、現代の標準的選択肢 |

3つすべて NIST FIPS 186-5（2023年）で承認されています。Ed25519 は新しいプロトコルの選択肢です。WireGuard・SSH（OpenSSH 8.0 以降のデフォルト）・Signal・Git のコミット署名・Rust の Cargo パッケージ署名で採用されています。

コード署名：数兆円規模のユースケース

ソフトウェア配布は署名に依存しています。なければ、ユーザーは本物のインストーラーとマルウェアを区別できません。

Apple Developer ID + 公証：macOS のすべてのアプリは Catalina（2019年）以降、署名と公証が必要です。RSA-2048 または ECDSA P-256 を使用。
Microsoft Authenticode：Windows 実行ファイルは RSA-3072 または ECDSA P-384 証明書で署名されます。
Android APK v2/v3：APK の内容への Ed25519 署名。
Debian apt・Red Hat dnf・npm・PyPI・Homebrew：すべてパッケージマニフェストへのデタッチ署名（通常 GPG Ed25519 または RSA）を使用。

有名な事件として、2020年に SolarWinds の Orion アップデートは、攻撃者がビルドシステムを侵害した後に同社の正規証明書で署名されました。署名は有効でしたが、侵害されたソースからのコードであることを証明しただけです。署名は署名者の身元を保証しますが、署名者の判断は保証しません。

PGP とファイルへのデタッチ署名

GnuPG（gpg）は企業の PKI 外でのファイル署名の主力です。デタッチ署名はファイルを変更せず、署名を別の .sig ファイルに置きます。

gpg --detach-sign --armor document.pdf
# document.pdf.sig を生成

gpg --verify document.pdf.sig document.pdf
# gpg: Good signature from "Alice <alice@example.com>"

PGP の弱点は鍵配布です。検証者は署名鍵が本当に Alice のものであることをどうやって知るのでしょうか。オプションとして、キーサーバー・信頼の網・keybase.io・帯域外検証（名刺に掲載されたフィンガープリント）があります。

現代の代替として、Sigstore（Kubernetes・npm で使用）は OIDC アイデンティティトークンを使ったキーレス署名を行い、透明性ログが信頼の網を置き換えます。minisign（Frank Denis 作）は PGP の複雑さなしに Ed25519 署名を提供します。

タイムスタンピング：「いつ」を証明する

署名は「誰が」を証明しますが「いつ」は証明しません。秘密鍵を盗んだ攻撃者は署名の日付を遡らせることができます。信頼されたタイムスタンプ局（TSA）は署名にタイムスタンプを追加署名することで、特定の時点にアンカーします。

主な標準は以下のとおりです。

RFC 3161 タイムスタンピング：Microsoft Authenticode・Adobe PDF 署名で使用。
Roughtime：Google による低レイテンシの検証済み時刻のための新しいプロトコル。

法的文書の署名（DocuSign・Adobe Sign・EU eIDAS 適格署名）は RFC 3161 タイムスタンプを使用して契約が署名された時点を確立します。

ファイル転送における署名の位置づけ

ほとんどのコンシューマー向けファイル転送サービスは署名を直接公開していません。AES-GCM 認証タグが転送内の整合性を証明し、TLS がサーバーの身元を証明しますが、送信者の身元を証明する組み込みの方法はありません。

高信頼の転送では、アップロード前に署名します。

送信者が Ed25519 または PGP でファイルに署名し、ファイル.ext と ファイル.ext.sig を生成する。
両ファイルを任意の転送サービス（HexaTransfer・SwissTransfer・WeTransfer）にアップロードする。
受信者が両方をダウンロードし、送信者の公開鍵で署名を検証する。

これにより真正性と転送メカニズムが分離されます。転送サービスが侵害されても、送信者の秘密鍵が安全であり受信者が正しい公開鍵を持っている限り、署名の有効性は損なわれません。

署名が過剰になるケースとそうでないケース

すべてのファイルに署名が必要なわけではありません。以下の場合はスキップできます。

受信者が転送チャンネルをエンドツーエンドで信頼している場合（Signal・対面での USB 渡し）。
コンテンツがセキュリティ上重要でない場合（会議の写真・レシピ・草稿）。
整合性だけで十分で、AES-GCM または TLS が提供している場合。

以下の場合には署名を追加します。

法的または契約上の重みがある場合（契約書・裁判証拠・医療記録）。
サプライチェーンの信頼が関係する場合（ソフトウェアリリース・ファームウェアアップデート）。
ファイルが信頼できない仲介者を経由して転送される場合。
元の転送を超えて残る耐久性のある監査証跡が必要な場合。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。