デジタル署名でハッシュを使う理由
-
angel_p_57
- 11581
- 19
- 7
- 0
-
- いいね！0
angel (as ㌵㌤の猫)
@angel_p_57
これは、署名データの省容量化にもつながる。現実の自筆署名や印鑑だって、文書のごく一部しか場所を取ってないにも関わらず十分な効力を発揮する。 デジタル署名でも、「保証」だけ分かれば良いんだから、署名データが小さくて済むなら、それに越したことはないのだ。
2021-07-04 20:42:07
angel (as ㌵㌤の猫)
@angel_p_57
ということで、ハッシュで元データの処理を先に行うことは、署名の実装上メリットしかない。であれば、(仮定にあったような) 大容量データを直接扱うような署名方式で頑張るのではなく、最初からハッシュを使う前提で、内部の計算は小容量データ限定にしてしまうのが当然ということになる。
2021-07-04 20:42:34
angel (as ㌵㌤の猫)
@angel_p_57
ちなみに、ハッシュの恩恵が受けられれば良いので、必ずしも「対象のデータのハッシュ値を秘密鍵で変換」でなくても良い。と言うか、EdDSAや、その元になったシュノアはちょっと違う。
2021-07-04 20:42:50
angel (as ㌵㌤の猫)
@angel_p_57
これらの方式では、対象のデータに別のデータを混ぜてからハッシュ値を取って、そこから処理を進めている。まあ、元データの圧縮効果があることには変わらないので、些細な違いではあるけど。
2021-07-04 20:43:06
angel (as ㌵㌤の猫)
@angel_p_57
ところで、ここまでの話を見ても、もうちょっとツッコミの余地はあるかも知れない。「メリットがあるのは分かった。しかし無いなら無いでも対応はできるのではないか。なぜハッシュが無い時代のRSAに実用性がないと言えるのか」
2021-07-04 20:43:20
angel (as ㌵㌤の猫)
@angel_p_57
まず一つには署名のサイズの大きさ。繋げられた署名の合計は、元のデータと遜色ないサイズになってしまう。何なら元のデータよりも大きいかもしれない。これでは流石に不便だ。
2021-07-04 20:44:00
angel (as ㌵㌤の猫)
@angel_p_57
もう一つ、公開鍵暗号としての処理はとても負荷が高い。元のデータ容量と同等分を処理するようだと、扱うのに必要なマシンリソース量もとんでもなく跳ね上がる。
2021-07-04 20:44:34
angel (as ㌵㌤の猫)
@angel_p_57
例えば「Aに/Xを/譲渡する」「Bに/Yを/譲渡する」というそれぞれのデータに対して / で区切った単位で署名が作成されるとすると。ここの単位で署名が完結してしまうため、適当に入れ替えて「Aに/Yを/譲渡する」という意図しないデータの保証にすり替えられるおそれがある。
2021-07-04 20:45:37
angel (as ㌵㌤の猫)
@angel_p_57
入れ替えだけでなく、意図的に一部分を除いたデータに対する保証へのすり替えも考えられる。twitterでも、たまに「発言の一部が切り取られる」ことの問題が語られることがある。それと同じ問題が署名にも現れるということだ。
2021-07-04 20:45:52
angel (as ㌵㌤の猫)
@angel_p_57
…まあ、この最後の問題への対処はなんか有りそうな気もするけど。ただ、署名のことを「改ざん対策」とか考えてると足を掬われるところ。署名と対比して語られることが多いMAC (こちらは分割してそれぞれで処理してもO.K.)とは決定的に違うところになる。
2021-07-04 20:46:30
angel (as ㌵㌤の猫)
@angel_p_57
MACとデジタル署名とをあんまり対比したくないのは ( 共通点もあるとは言え )、こういう点にもあるんだよね。
2021-07-04 20:46:46
angel (as ㌵㌤の猫)
@angel_p_57
話を戻して、データを分割してそれぞれで署名を作ろうというのは、上に挙げたような3重苦をなんとかしなければならない。だから無理筋ということで。
2021-07-04 20:47:02
angel (as ㌵㌤の猫)
@angel_p_57
…というところで。長くなったので一応結論としては、次のようなことで良いだろう。 ・ハッシュを署名に組み込んでも問題ない ・逆にハッシュを署名に組み込むとメリットが非常に大きい ・その上ハッシュなしで対処するのには困難が伴う ・なので署名にはハッシュを内包するのがほぼ当然となった。
2021-07-04 20:47:35