※本稿には正しい認識からずれた部分があります。コメント欄で紹介されている記事を参考にして、正しく理解していきましょう。
今回は「公開鍵暗号方式」について書いてみたいと思います。
目次
公開鍵暗号方式……
WEBサイトでよく利用されるSSLサーバ証明書やメールの署名/暗号化で利用されるS/MIMEやPGP等、調べればいくらでも情報はヒットするし、初心者向けの解説も多数。
でもいまひとつ自分にしっくりくるものがなくて、一度自分が説明できる範囲でまとめてみました。
メールやファイルの受け渡しが説明しやすそうです。
公開鍵暗号方式でなにができるのか
よく言われるのが「暗号化」と「署名」です。
-
署名
自分が書いたものであり、他の誰かに偽装や加工されていないことの証明を受け手が確認できる。 -
暗号化
受け手のみが内容を知ることができる。
魔法のカラクリ
この「自分が作った(送った)証明」や「受け手だけが読める」ための仕組みを構成するために、ペアとなる二種類の鍵を用意します。
- 自分だけが持つ鍵(秘密鍵/私有鍵)
- 友人知人連絡先にばら撒く鍵(公開鍵)
自分だけが持つ秘密鍵は例えば左にだけ回せる鍵。右には回せない。
不特定の相手に配る公開鍵は右にだけ回せる鍵。左には回せない。
そして、それぞれ90°回転させることができる。
この鍵を動かせる範囲は以下のようなイメージです。
いずれも③は回せない位置なので、「あぁ、回せないのね……」と思っていただければ。
そして、①同士、②同士で鍵閉め、鍵開けの流れが成立します。
①で、Aさんが鍵をかけたものは、Aさんから貰った鍵(公開鍵)で誰もが開錠することができます。
この鍵で開くということは「Aさんが鍵をかけた後、他者に改変されていない」ことを意味します。
誰でも開錠(復元)できることで、暗号化としての意味はありませんが、偽装や改変されていない証明になります。
②では、Aさんだけに見てもらいたいデータを(誰もが)Aさんの公開鍵で鍵閉めをすることで、Aさんの秘密鍵でしか開くことができない状態にできます。
秘密鍵を持つAさんだけが鍵を開けることができます。
一方通行
今回、Aさんの鍵ペアを用いて説明しました。
ここでは以下2点が利用できます。
- Aさんの秘密鍵で鍵閉め、公開鍵で鍵開け …… Aさんからのデータで、偽装や改変されていない証明
- Aさんの公開鍵で鍵閉め、Aさんが秘密鍵で鍵開け …… Aさんだけが内容を確認できる
逆に AさんがBさんだけに伝えたい、Bさん以外に見られたくない内容がある場合、AさんはBさんの公開鍵を入手する必要があります。Bさんだけが持てる鍵(秘密鍵)も必要で、Bさんも自身の鍵ペアを用意しておかないといけません。
まとめ
繰り返しのようになりますが、
- 自分が送ったデータが偽装、改変されていないことを証明(受け手が確認)するためには、自分の秘密鍵(鍵ペア)が必要
- 相手だけに伝えたい内容がある場合には、相手の公開鍵が必要
ということになります。
自分が何かするだけで相手だけに伝わる暗号化ができるわけではないので、なかなか一般的になってこないのかなと思います。
おばあちゃんに伝わるかな。
「コンピューターおばあちゃん (by コスミック・インベンション)」ならわかってくれるはず……
最後に
本稿執筆後改めて検索してみたらありました!同じ考え方の記事が。
今まで見つけられなかったのに……
こちらも参考にしていただければと思います。
https://blog.vrypan.net/2013/08/28/public-key-cryptography-for-non-geeks/
https://www.cloudflare.com/ja-jp/learning/ssl/how-does-public-key-encryption-work/
以上、自転車の鍵開けならちょっと得意な m//t でした。
COBOL系SE,PG から NetNews(nntp)配送管理者(tnn.netnews.stats集計担当) を経て現職。
社内業務改善(「やりたくない」がモチベーション)でいろいろ社内ツールを作ってきました。
ネットワーク系の機器をいじることも多いので、それらの管理や制御に関するツールもちらほら。
perlで書くことが多いですね。(COBOLやFORTRAN、Pascal でもいいですけど……)
どれだけ読みやすく書けるか、10年後の自分に手紙でも書くような気持ちで。
最近はDNSを少しかじったりしてますが、いろいろ悩ましいことが多すぎます (>_<)
好きなポート番号は53、119、123です。
LINK
クラウドベリージャム:プロフィールページ
分かりやすい説明を試みる、という趣旨かと思うのですが、先に実態に即して理解できているかを確認する方が重要かと思います。
暗号技術を錠前・開け締め操作で喩えるのは、一部には使えなくもないですが、基本的に止めたほうが良いです。
特に署名が問題です。既に「自筆署名(日本なら印鑑)」のような特性の技術として喩えられて名前がつけられているのに、錠前という別の喩えを持ち出す時点で、何かがおかしいと気付くべきところかと思います。( 仕組み自体の理解が不適切なことの傍証 )
コメントありがとうございます。
記事( https://qiita.com/angel_p_57/items/897bf94160be8d637585 ) やtwitterの引用ツイートも拝読しました。
すごく参考になり、他の記事もあれこれ読ませていただきました。
twitterについては権限がないので私からは返せないのですが……
そうですね、署名についてはかなり無理があると認識しています。内容も足りていませんし。
ただ、署名を語る時に「鍵」というものの存在が難解で、だったら鍵ペア+錠前の開閉イメージから例えば真正性の説明に使えたりしないだろうかと考えました。
そういう意味ではむしろ「署名」という言葉も出すべきでなかったのかもしれません。
あまりに奥が深すぎて思考停止してしまった人に少しずつでも動き出してもらえたらと、ない頭を捻っての記事でした。
> 署名を語る時に「鍵」というものの存在が難解で
それは日常で使う「錠を開け閉めする物理的な鍵」という先入観に囚われているからだと思います。英語の「キー」であれば、そのような先入観は無いでしょうから。
※RDBMSの「主キー」「外部キー」、NoSQLで出てくる「キーバリューストア」、他にも形容詞的な「キーワード」いずれも同じ「キー」という用語ですが、物理的な鍵のイメージにはならないでしょう。
あるいは、「秘密鍵で暗号化すると署名になります」というデマの影響かも知れません。が、そもそもそのような事実もないので、鍵による「開け閉め」のイメージをスタート地点とした時点で既に誤りです。
実体を正しく見ることができれば、もっと単純に捉えることができるかと思います。
例えば https://togetter.com/li/1412507 も参考にどうぞ。
確かにそうですね。共通鍵暗号の暗号化/復号化のイメージから性質の違う署名にこじつけようとしてしまったからかもしれません。
秘密鍵で復号したものを公開鍵で暗号化して元に戻るかという動作でいろいろ腑に落ちた気がします。
参考URLもありがとうございます。