[sylpheed-jp:11392] SylpheedダウンロードのPGP署名について

2017年 10月 24日 (火) 20:34:40 JST

　やまねです。

　https://sylpheed.sraoss.jp/ja/download.html でのPGP署名が
　気になったので、GnuPG作者の一人、新部さんに相談しました。

　結論を言うと
　・配布用の鍵を作ってそれで運用
　・配布用鍵は2048bit以上 RSA利用を推奨
　・Web of Trustを辿れるように配布用の鍵については山本さんの個人鍵で署名
　　しておく
　・サイトについてもPGP署名の説明をできれば増やす
　という形にしてもらうのが良いかと思います。


　以下、新部さんから頂いた助言です。

-----------------------------------------------------------------------------
> 　現在Debianでは、2048bit未満のGPG鍵を使わないようにしているかと思います
> 　が、1024bitの鍵はもう良くないよ、という根拠となる話はどこにあったか
> 　ご存知ですか？

いわゆる「2010年問題」と呼ばれた話かと思いますが、NISTの勧告の以下の文
書によるものだと思います。

https://csrc.nist.gov/publications/detail/sp/800-131/archive/2010-06-16

これは 2015年に改訂されてます(移行期間が過ぎたので)。

https://csrc.nist.gov/publications/detail/sp/800-131a/rev-1/final

> 　sylpheedの配布にPGP署名がついたのですが、鍵が期限切れで1024bit DSA鍵
> 　だったので、upstreamにどういう風に話をして、どう更新してもらうのが
> 　良いかと思いまして...（期限を延長してkeyserverに上げなおしてもらう？
> 　それとも新しい鍵で配布してもらう？）

新しい鍵を作って新しい鍵の電子署名が妥当だと思います。

現在、DSA の 1024-bit 以下の鍵長のものは、あんまり推奨できません。


詳しく言うと、複雑です。 長くなりますので必要が無ければ読み飛ばしてください。

(1) OpenSSH の場合は、おそらく保守が面倒だからだと思いますが、DSAのアル
    ゴリズム自体が非推奨となったと思います。(だいたい全否定)

(2) OpenPGP の場合は DSAのアルゴリズム自体は使えます。非推奨ではありません。

(3) 注意点として電子署名のために DSA とともに使うハッシュ関数の問題があります。

(4) OpenPGP では DSA の利用は全否定はしてません。

    DSAの電子署名のアルゴリズムを 1024-bit で使っても、SHA1 を避けて
    SHA2 を使うことにすれば、現在でも使えないことはありません。

    1024-bit の DSAの場合、入力の有効な長さが 160-bit なので、歴史的には
    SHA1が使われます(OpenPGP の古い標準の RFC2440)。

    2048-bit 以上の DSA の場合はSHA2が使われます。

    新しい標準のRFC4880に基づいて、1024-bit の DSAの場合でもわざわざ
    SHA2 を使うようにすれば、使えます。


(5) 鍵長の運用は、あくまでも慣習であって、2010年の勧告の後 7年経った現在
の時点で、1024-bit(SHA2をあえて使う)の DSAや、1024-bit の RSA の暗号アル
ゴリズム自体が破られた、ということは、まだありません。

(個別の実装の脆弱性により、暗号が破られるということは、別に 1024-bit に
限らず、いつも脆弱性報告があり、修正があります。)

----------------------------------------------------------------
すみません。先ほどのメールは具体的な電子署名の運用を見ないで回答してまし
た。

二点問題があると思います。

* 電子署名が実質的に電子署名としての意味がない、という話

電子署名が意味を持つのは、使われている鍵があらかじめ検証されているとき、
その場合だけです。

Sylpheed の「ダウンロード」のページでおかれている電子署名は
5024337CC00C2E26 の山本さん個人の鍵と思われるもので署名されているだけで、
わたくしが見た範囲では、鍵に対する言及はなにもありません。

この状況では、署名の確認は、hash の値が正しいくらいの意味しかなくて、ダ
ウンロードの際に(CRLF変換などで)壊れたのではないようだ、ということが確認
できる程度でしょう。(外部から見たら今と区別がつけられない形態で、偽のリ
リースをすることができる、ということについて検討することをおすすめします。)

たとえば、リリースの 際には常にリリース鍵のフィンガープリントと入手先を
説明したメールを送ったり(メールは個人の電子鍵で署名)、HTTPSで保護されて
いるダウンロードサイトでも鍵を開示したり、潜在的にリリースを受けとるであ
ろう方に別の(物理的)チャネルでも確認出来るようにパンフレットや名刺に鍵の
フィンガープリントを常に載せる、などの運用をすることが望まれます。

よくある慣習では、開発者個人の鍵ではなく、独立のリリース鍵を運用します。
(その独立のリリース鍵は開発者の個人の鍵で署名します。)


* 署名自体の問題

最近のものを二つみました。

(1) 
https://sylpheed.sraoss.jp/sylpheed/v3.6/sylpheed-3.6.0.tar.bz2.asc

(2)
https://sylpheed.sraoss.jp/sylpheed/v3.6/sylpheed-3.6.0.tar.gz.asc

確認するのに、これに対する gpg --list-packet の出力ですが、それぞれ、

# off=0 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid 5024337CC00C2E26
	version 4, created 1498713528, md5len 0, sigclass 0x00
	digest algo 2, begin of digest d1 1b
	hashed subpkt 2 len 4 (sig created 2017-06-29)
	subpkt 16 len 8 (issuer key ID 5024337CC00C2E26)
	data: [158 bits]
	data: [159 bits]

# off=0 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid 5024337CC00C2E26
	version 4, created 1498713525, md5len 0, sigclass 0x00
	digest algo 2, begin of digest b0 c8
	hashed subpkt 2 len 4 (sig created 2017-06-29)
	subpkt 16 len 8 (issuer key ID 5024337CC00C2E26)
	data: [159 bits]
	data: [158 bits]

となってます。

digest algo 2 ですが、SHA1 のハッシュに対する DSA のアルゴリズムで署名を
生成したものになってます。ですので、他のアルゴリズムを使っている場合に比
べて、署名の検証が有効に働かない危険性が高いと言えます。

2017年の今年に、SHA1 の collision attack の実際の例が示されました。(異な
る入力に対して同一の出力となるものを得ることが、実例で示されました。)

これは、preimage attack とは異なるので、ただちに、たとえば、リリースさ
れている tar.bz2 を(悪意で)置き換えて、同一の電子署名が有効となって、
検証がすり抜けられる、というわけではありません、けれども。
----------------------------------------------------------------

-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp