公開鍵を公開したくないという人に対しどう説得すれば良い？ 113
ストーリー by hylom
公開とは一体 部門より
公開とは一体 部門より
あるAnonymous Coward 曰く、
公開鍵暗号では公開鍵が一般公開され不特定多数がアクセスできることを前提としているが、それにも関わらず「公開鍵を公開したくない」「公開鍵を平文で送るな」「公開鍵をそのままサーバに保管するな」「公開鍵が盗聴される恐れがある」「公開鍵だけ送るのでは復号ができない」など、主張する人がいるそうだ（@illness072氏のTweet）。
これに対し、「そーゆー間抜けな人たちって、パスワード付きZipで暗号化すると満足したりしません？」という指摘も出ている（@masanork氏のTweet）。
もはやPKIを否定しているとしか (スコア:5, おもしろおかしい)
1. そのような御仁が上司だったら、今すぐに転職を準備しましょう。
2. そのような御仁が客だったら、まず逃げることを考えましょう。
3. そのような御仁が同僚だったら、黙ってスルーしましょう。もしその御仁が出世したら速やかに転職しましょう。
そのような御仁には、公開鍵を公開して良い理由を数学的に証明しても無駄です。
もはや宗教になっています。逃げて! 今すぐ逃げて!
# 地球平面主義者に地球が丸いことを理解させるに近いかも。
HIKARU
Re:もはやPKIを否定しているとしか (スコア:1)
そこまで見知らぬ人を小馬鹿にしなくてもよいんでは？
Re:もはやPKIを否定しているとしか (スコア:5, 参考になる)
小馬鹿にするつもりは毛頭ありません。「そのような人は救えない 。被害を受ける前に逃げるべき」と主張しています。
根拠
1. 高度情報処理技術者試験対策として公開鍵については勉強するはず。こんな主張をする上司は大抵ほかの箇所でもトンチンカンなことを言い出します。危険です。
2. 客がただ無知の場合は、根拠付きでご案内するだけです。それを聞けない客は他にもっとトンチンカンな事を言い出します。極めて危険です。
3. 同僚が言い出して聞かない場合は時間の無駄です。そんな人物を上司が認めて昇進できることが危険です。
HIKARU
当然 (スコア:4, おもしろおかしい)
パスワードは、別メールで平文。
Re: (スコア:0)
１件、２件ならお付き合いできるが、
２０数人が一度にパスワード付zip＋平文パスワードを
送ってきたときには殺意が沸いた。
めんどくさいこと！
Re: (スコア:0)
あれは、機械的に解凍&virusチェックをされないためのものと解している
それはそれでどうなのとは思うが。
PGPの公開鍵の場合 (スコア:2)
メールアドレスで一意性を(ほぼ)とってるので、結果メアドが公開状態になるのが難点なんですよね。
(サーバでは)メールはマスクして、小文字化後にhashしたもので一致確認する、とかで鍵検索できるなら、多少は隠せるのかな...
とか考えたことはありますが、あまり意味ないだろうな
# どのみちブルートフォースにデータを取得されて、手元では読めるし、成功クエリを保持するのは難しくないだろうし。
###
Githubでのssh公開鍵が見えるようになってるIFについては、「弱い鍵がばれるという問題くらいはあるかも」的な話になったことありましたね。
M-FalconSky (暑いか寒い)
別の手段で伝達 (スコア:1)
電話で16進数で鍵を読み上げよう
Re:別の手段で伝達 (スコア:1)
FAXで送ろう
フロッピーディスクに格納して手渡し (スコア:1)
・法務省：＜参考１＞ 電子証明書の発行を受けるまで [moj.go.jp]
・Pretty Good Privacy（PGP）を利用した電子メール [ipa.go.jp]
Re: (スコア:0)
プリントして書留郵便では？
Re: (スコア:0)
直接は関係ないけど，印刷出版して国外に持ち出した PGPi を思い出しました．
Re: (スコア:0)
キーサインパーティ [wikipedia.org]
公開鍵暗号方式に関する知識が乏しいのでしょう？ (スコア:1)
公開鍵暗号方式を理解しいている人にとっては、説得したいのかもしれないけど、利用者というのはだいたい無知なまま利用するのです。
「公開」という言葉を使っていても暗号化する際の「鍵」なので、「これが漏れたら解読されちゃうんじゃないか」と気にするのは当然だと思うけど。
議論の都度、説明するしかないよね。
背景によるとしか (スコア:0)
サーバ側に公開鍵登録してっていう依頼ならそりゃ平文で送るなは正しい。
(HTTP、FTPでの転送って意味だよ)
それぞれの「理由」が書いてないので公開することを嫌がる事を批判する事がおかしい
Re:背景によるとしか (スコア:1)
公開鍵は、紙で手渡しが原則だろうｗ
それぞれの理由を考えてみた
「公開鍵が盗聴される恐れがある」…「盗聴さえる恐れ」ならなんだってあるだろう。
「公開鍵を平文で送るな」…平文で送れば、盗聴で検知され、別の公開鍵に置き換えられることをいってないか？
「公開鍵をそのままサーバに保管するな」…「そのまま」が暗号なしの手順で送るなって意味じゃないのか？
「公開鍵だけ送るのでは復号ができない」…「公開鍵だけ」送られてきても、貴方のものか検証できないって意味じゃないの？
「公開鍵を公開したくない」…それは「お前に」公開したくないだけじゃないのかｗ
Re: (スコア:0, フレームのもと)
転送方法に関わりなく、盗まれようと流出しようと問題はないです。
PKIの仕組みを勉強した方が良いのでは？
酔っぱらった状態での意見だけど (スコア:1)
どういう意図で、公開したくないと言ったのかが解らないため、真意はわかりませんが、
例えば、乱数的に生成されたURLを発行し、それを知る人物しかアクセスできないことで、
第三者によるアクセスを防ごうとするシステムがあるように、
公開鍵を隠すことで、通信を開始できないようにするという考え方もあるのではないのでしょうか？
公開暗号方式自体が安全だとしても、実装が本当に安全であるかは判らない訳で、
（現実で起こった例と挙げるとすれば、TLSの仕様が(実用面ではともかくとしてセキュリティ面で)問題なかったとしても、
その実装でHeartbleedのような脆弱性が発見された）
「通信を開始できる人間を限定することで、そのような脆弱性をつつかれる可能性を減らす」
という考え方はあるのではないでしょうか？
Re:酔っぱらった状態での意見だけど (スコア:1)
という考えは、公開暗号方式の仕組みの知識があっても、
使われた方の知識がなければ要求・提案できないし、
公開したくないと言った人が仕組みしか知っていなかった可能性はあるのだから、
「理由」を聞いて、提案しないといけないんじゃないの？
Re: (スコア:0)
差し替えられたら問題があるからでは？
Re: (スコア:0)
Re: (スコア:0)
全体的に公開鍵と証明書がごっちゃになってる。
証明書ならそのまま送っていい。受けた側が検証できる。
生の公開鍵ならまず安全な通信路を確保する必要がある。
Re: (スコア:0)
ルート証明書やオレオレ証明書など他の証明書で検証可能な署名のついていない証明書は普通にあるし、
証明書は公開鍵に付加情報をつけられるコンテナに過ぎないと考えたほうがいいかと。
Re: (スコア:0)
公開鍵を平文で送って改竄されたらどうすんの？
KPI云々以前に俺は「サーバに公開鍵登録して」っていうパターンって言ってんだけど。
Re: (スコア:0)
> 改竄されたら
ユーザ認証は別にするんですよね?
ならば、どのみち改ざんされた公開鍵とペアの秘密鍵では、ログインできないだけなので
単純にもう一回公開鍵を送ればいいだけでは。
そういう問題ではない?
Re: (スコア:0)
だいたいの人はSSHは公開鍵オンリーで認証通しちゃわない？
なので改ざん公開鍵を設置されちゃうと悪意のある人がログインできてしまうな。
まぁ、平文で送ってauthorized_keysに追加するとかいうケースは考えにくいけど。
教えるほうがバカなんだよ (スコア:0, すばらしい洞察)
メリットを説明できず押しつけになっている
この手の問題はたいていそうだ
Re: (スコア:0)
「こんなこと言われた」ならば普通のあるあるネタで済みますが、
説明できずにネットに泣きつくレベルなら同次元ですよね。
原理もわからず教条的に使ってる知識だから、ただ強く言われただけで窮する。
Re: (スコア:0)
公開鍵暗号を使わせたがる側が楽したがっている、ええかっこしたがっていることが相手に見抜かれてるんだよな
普段から仲良くしてないとこういう時に相手は意地でも使ってやるかと思ってしまう
Re:教えるほうがバカなんだよ (スコア:2)
人に言う事聞いてもらいたいなら人から信頼されるか尊敬されるか愛されないといけない。
まあコミュニケーションの基本ですよね。
Re: (スコア:0)
裏でこうやって見下した陰口たたくようなタイプは物腰にも出てるだろうしな
裏でこうやって見下した陰口たたいてるあたりまで見透かされてるわな
もしかして 共通鍵 (スコア:0)
「公開鍵を平文で送るな」だけは正しい (スコア:0)
公開鍵暗号方式は、そのままでは成り済ましを防げません。
公開鍵が平文のメール等で送られてきた場合、本当にその相手の公開鍵なのか、悪意のある第三者の公開鍵にすり替えられているのかが分かりません。
無論、フィンガープリントを別途安全な方法で送ってもらって確認するということはできますが、二度手間になるので、公開鍵を最初から安全な方法で送った方が早いでしょう。
例えば、相手が確実に本人だと分かり、かつTLSで暗号化されている Slack チャット とか Twitter のDMとかで送れば良いのではないでしょうか。
Re: (スコア:0)
文書の真正性と暗号化されているかどうかとは本質的には関係ないぞ。鍵なんかいくらでも作れるんだから、本物の偽者であることは簡単に証明できる。
安全な方法で鍵を配送するか、信頼できる第三者機関に証明してもらうくらいしか方法はない。その過程は盗聴されても問題はないのだから平文で良い。
Re: (スコア:0)
え？その公開鍵で暗号化した文を相手が秘密鍵で複号できるかどうかで判断できるのでは？
と思ったけど、宛て先自身が書き換えられてる可能性があるのか。
電話とかで直接連絡つく相手で「届きましたか？複号できましたか？」と確認しても、メールはMITMで中継されるとアウトか。
Re: (スコア:0)
それは公開鍵を平文で送ることの問題ではなく、送り元証明の有無の問題じゃないでしょうか。
送り元の身元証明ができれば平文で送ることになんの問題もないですよね。
Re: (スコア:0)
馬鹿なのかな？
送り元の身元がしっかりしていることと、通信の安全性の両方が必要なの
送り元の身元が明らかで送信時点では送り元の公開鍵だったとしても、
通信が平文で改竄が検知できないなら、通信に割り込んで悪意のあるクラッカーの公開鍵に差し替えられるかもしれない
で、そのクラッカーの公開鍵で暗号化したデータを送信すると、
通信が傍受された場合、クラッカーが復号できてしまう
オレオレ証明書が危険な理由と同じ危険性があるの
なんのために公開鍵暗号方式の他にPKIというものが存在するかよく考えた方が良い
Re: (スコア:0)
送信者の身元確認、送信内容の証明、内容の秘匿性の三つに分けて考えると、秘匿性は要らないよね。
暗号化で確保できるのは秘匿性だけなんだけれど、目的は前二項なんだから目的を達成できないよね。
それではなぜ(身元を確認も内容の証明もせず)暗号化すればオッケー、なの?
あるいはなぜ(身元を確認し内容を証明しても)暗号化してないとNG、なのかな?
量子コンピュータ (スコア:0)
量子コンピュータの到来を予測しているだけでしょ。
理由は明らか (スコア:0, 荒らし)
> これに対し、「そーゆー間抜けな人たちって、パスワード付きZipで暗号化すると満足したりしません？」という指摘も出ている（@masanork氏のTweet）。
こういう部分にオタの説得下手がにじみ出ている
なにかというと人を見下すことしかできない輩の言うことなんてまともに聞いてもらえるわけがない
Re: (スコア:0)
自虐でしょうか
名前が悪い (スコア:0)
こういうのこそ、横文字にしろよ
公開しないと (スコア:0)
後悔するぞ
Re: (スコア:0)
こう書いてもおもおか５は狙えない
Re: (スコア:0)
1すら…
Re: (スコア:0)
狡獪だな
虎の威を借る (スコア:0)
○○さん笑いや××さん(偉い人、できる人)もやっていらっしゃいますよ。
#ああ、セールスか詐欺師の手口
一休さんモード (スコア:0)
「それならば、公開鍵(a)を暗号化するための公開鍵(b)を送りますので、その公開鍵(b)を送るための公開鍵(c)を送ってください」
って言ってあげれば、自分の言っていることの矛盾に気がつくのではないでしょうか？
でも電子証明書(X.509)は作りたくない (スコア:0)
そこらへんはいろいろなトレードオフですよね。
「完全第三者」であれば、電子証明書でやるしかないし、
「少し関係」があるのであれば、公開鍵+fingerprint(sha256)
を平文(メール)で送っても、業務都合上では問題ない場合が多い。
少なくとも、電子証明書でやりとりするのは、コストが高過ぎなのは確か。
なので、公開鍵のやり取りだけしかない。
公開鍵を公開したくない、って人には、真っ当なセキュリティである、公開鍵証明書だとコストが高いすぎなので、
コストをかけられないので、しょうがないから慣れてください、というので納得してくれないかな。。
セキュリティリスクは「公開鍵」だけでの真正性は担保できないことなので
それはその「少しの関係」で担保しているのです、てな感じでいけないかな。
Re:でも電子証明書(X.509)は作りたくない (スコア:1)
> 「少し関係」があるのであれば、公開鍵+fingerprint(sha256)
> を平文(メール)で送っても、業務都合上では問題ない場合が多い。
その fingerprint 、同じ経路で送ってたら無意味じゃない？
経路上で改竄（すり替え）されていないことを保証したいのなら、
まだmd5の上4桁を電話で伝えるほうがまし。