アカウント名:
パスワード:
＞今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、＞20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。
仮にそれを非常に高度な技術力で実装した経験があったとしても、昨日今日、実装した人ばかりでは無い。むしろそうでない人の方が大多数だろう。仮に知識も経験もあっても、やってから10年もたてば技術は陳腐化するし、なにより人間は忘れる生き物だ。仮に覚えていても、突然質問されて10年前のことを上手く説明するのは無理。
この求人が暗号化技術を専門とする技術者で、Requirementsの最初に「公開鍵暗号」となっていない限りは、質問の方が不適切だろう。
これは質問が悪いと思うんだよな。用語じゃなく「何を意図した質問なのか」がさっぱり分からない。仮に公開鍵と伝わったとしても、実装経験のある人間なんかおそらく0.1%もいない。
というか、ツールでも使った事ない技術者はいくらでもいると思う。とりあえず20年システム屋さんやってるけど、「PGPで送りますか」って言って通じた事は残念ながら一度もないってのが正直な話。「どのように暗号化しますか」の質問に対しては、圧縮ファイルにパスワードを掛けると回答する技術者が大半だと思う。というか、企業の情報セキュリティガイドラインがそうなってる。
喩えるなら、自動車修理工場の整備士がどんなに腕が良くて経験があろうとも、タイヤがなぜ4つなのかの理由を答えられるとは限らないという事。
＃リストランテの料理人に「なんでパスタって茹でる時に塩入れんの？」でも可
公開鍵暗号のアルゴリズム自体はわからなくても、OpenSSLやGnuPGはソースを公開してる訳ですから、如何にして公開鍵暗号を使って暗号化し、復号化するか。と言う原理自体が分かっていれば、後はソースを見ながら実際のプロセスを実装したり、独自の関数式を暗号鍵の発行や暗号・復号に使うだけならば、当該ソフト・ミドルウェアにポーティング出来ますよね。# 公開鍵暗号を一から実装しなくても、とりあえず使えれる物を寄せ集めてライセンス侵害しないように作り直せればなんとかなるよね。と云うこと。
そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
＞暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。確かにそうですね。只、そういうニーズは少なからずある訳じゃないですか。クローズドな暗号化手順やアルゴリズムを実装して（試験的に）内輪で使うとか、組み込む側のライセンスの関係で流用が困難だとか。このタレコミに引用されてる質問は、要はこういう事を出来る人を探していたのではないか？と、勝手ながら推測しておりましたので。
暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。
実装できるだけの知識と腕があってそう言うのであれば、大変結構な事ですね。
そのうぬぼれがでっかいホールを生みだすのよおろかものめ
ではその暗号が数学的に安全であることを証明して他の専門家にも安全である事を確認してもらってください。実装する知識と数学的な知識は別物だから普通の技術者だけでやった結果がWi-FiのWEP脆弱性とかな訳で。
そう思ってあえてツールを使うという回答をするなら、そういう考えを説明するべき。そのうえで、どのツールはどういう仕組みになっていてどんなメリットとリスクがあるからどのツールを選択すべきかという話をすればいい。
ツールを使うという回答をする時点で、たんにツールを使うだけの人と面接官に勘違いされるリスクに気付くべき。そういうリスクに対する回避行動を取れない人は、仮に技術者として技術があっても仕事内容の意思疎通に支障がおきる可能性があるから不採用だろう。
DBを使うと脆弱性の危険性があるので独自XMLでデータを保存してます(ｷﾘｯって要求概要説明してくれたベンダーさん(元請け)を思い出した。
# PC/携帯共用コードのサイトでノーチェックでサブスクライバID使って認証してたのには吹いたがｗ
> そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。
ですね。でも、実装までは求めてないと思いますよ、元記事のramoneThePoolGuyさんは。公開鍵暗号に限らず、暗号システムの全般的な知識を要求したんだと思いますよ。なので、「3DESで暗号化して送ります、鍵は手渡しで」なのでも良かったんだと思いますね。
> 現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
今の人達はフレームワークの使い方とかなんとか、色々お勉強が忙しいのでしょう。公開鍵暗号がどう機能するのかなんて、昔の人みたいな悠長な事をやってられないんだと思います。
>今の人達はフレームワークの使い方とかなんとか、色々お勉強が忙しいのでしょう。公開鍵暗号がどう機能するのかなんて、昔の人みたいな悠長な事をやってられないんだと思います。
たぶん、それを「趣味」でやらないといけないってのが一番のネック。「そんなもんに教育予算回せるか、今すぐ金になる物を勉強しろ」ってのが企業として当たり前の姿勢なので。
さらに言えば、皮肉にも企業の情報セキュリティ統制がしっかりしてきたために、開発環境として職場とプライベートが隔離されてきてる。個人が独力でセキュリティに関してエンタープライズ用途も意識した実践的な経験を積む事は通常のキャリアプランでは不可能だと思う。
エンコード／デコードエンジンも、たとえ自作できたとしても、自分単独では書きたくないものの筆頭。脆弱性レポートの定番ニュースに、首を並べることになる。10年前から問題が絶えない。
OpenSSLとかjava.securityとかSystem.Securityとかあるんだから、そこは自前実装しない方向に主張しましょうよ！そういうの使えるだけで意外と感心されたりする。
ググる先生に教えてもらいました。パスタを茹でるときには塩を加えるべきか？ [shokuikuclub.jp]それは塩入れて茹でた方がうまいかららしいですよ。
そこはあまり考えてはいけません。料理は別に手間を最適化すること、結果に対しレシピが最善手であることは求められないので、「師匠から○○と教わった」場合、例えソレが科学的・論理的に正解ではなかろうと「できたものが旨ければ正当化される」のです。
・塩を入れても入れなくても大して変わらない説・ソースを絡めた時の味の染みこみが違う説・突沸を防ぐ説←明確に誤りでマイナー・沸点上昇説←明確に誤りだと思われるが根強く生き続けるなどなどありますが、結局は論理的かどうか、多数派かどうかではなく、「自分の信じたい説かどうか」でしかありません。
よって、「パスタが産まれ泳いでいた海に最も近い塩分濃度にすることが収穫直後の味を最もよく再現できる」vs「パスタに悪霊が憑依している可能性があるため除霊要素として塩を加える」のいずれかを信じるのが幸福に近づく最善手だと主張したいと思います。
信じたいとかじゃなくて、味が違うんだから、それでいいじゃん。
ソース無しパスタ何度も食べれば分かる。
質問が悪い、に同意だな。つーかさ、安全な方法で鍵を共有できるなら、共通鍵でもいいんだよね。目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
状況によってはAES128(MS Office)やAES256(ZIP)の方が公開鍵よりも解読しにくいんだけどねぇ。公開鍵の場合は、計算時間さえかければ必ずペアの鍵を見つけられるけど、共通鍵は複合化できたかどうかの判断基準が必要だから。
> 目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
ストーリーの内容を見ると...
たとえば、今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。他の求職者にも同様に「あなたが非常に機密性の高い情報を私に送るとしたら、あなたは私が復号する情報をどのように暗号化しますか」といった質問をしたところ、
公開鍵に関する質問と、面接官に情報を送る質問とは、別の質問だと思われます。
また、面接官に情報を送る質問に対して、いまここで送る（別れてから後日送るという可能性はない、あるいは「あなた」「私」という言葉は単なる例として使った可能性はない）という意味に決めつけて解釈し、それに基づいた回答をするのが妥当でしょうか？
いや、開発者/アーキテクトの面接なんだから開発の知識聞いてることぐらいわかるよ。Excelかpdfかとか、ツールの操作方法でも答えるつもりか？車の整備士の面接で「ハイブリッド車は解りますか？」と聞いて、「プリウスなら乗ったことあります」って答えるぐらいとんちんかんな回答だぞ。
今の自分の立場、前後の文脈から、それすら解らん人は流石に要らんだろう。
会社「整備士募集」求職者「応募します」会社「君、ハイブリッド車は解る？」求職者「はい、ハイブリッド車の整備士免許持ってます」会社「実際に整備したことは？」
どこに曖昧な所がある？
そこに塩とパスタがあるからさ。
> 用語じゃなく「何を意図した質問なのか」がさっぱり分からない。
そう思ったなら、聞き返さないといけないね。疑問点を解消しないまま仕事を進めるやつとは一緒に仕事できない。
いやいや、これは別の話題で言うなら、クイックソートの基本的な仕組みを聞かれてるのに「Excelですか？それならA->Zって書かれたボタンを押すんですよ」って答えてくるアホの話だろ。
技術が陳腐化するとか求人条件に書く項目とかの話とか、そういう段階の問題じゃないね。
# 一応断っておくが、「パブリック/プライベートキーによる暗号化の基本的なプロセス」ってのは高度な技術力で# 実装した経験者じゃないと分からないようなムツカシイ話じゃなくて、基本情報処理技術者レベルの試験でも聞かれる話だからね？
いやいや、SSLの証明書をサーバに貼ったヤツのうち、PKIを本当に理解して操作したのなんて1/1000くらいだろ。たんに理解する気がないだけだ。その証拠に、ActiveDirectoryなんてできて15年経つが、まともにKerberos使えるヤツなんて見たことない。
訊き方が悪いってのはある種同意で、長い秘密鍵を持っててもパディングが十分じゃないと繰り返し盗聴された時にいつか秘密鍵が漏れるみたいな話に聞こえる。
質問が悪いにしても、
> Excelファイルなのか、PDFなのかといった質問を始めた
これはないな。求人の内容すら理解してない。そう答えて許されるのはオペレータの求人の時だ。
目の前にいる面接官へは、安全な共通鍵の受け渡しが可能。鍵の受け渡しが安全であり、十分にランダムな鍵を使用するのであれば、公開鍵暗号より共通鍵暗号の方が堅固である。
標準の実装が暗号化の手段を提供しているのであれば、それを利用するのが技術的に最短であり、下手なことをして脆弱性を付与する可能性も低い。
よって、Excelファイルなのか、PDFファイルなのかを聞くのは妥当である。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
経験者でも、そればっかりやってるわけじゃないし．．． (スコア:0)
＞今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、
＞20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。
仮にそれを非常に高度な技術力で実装した経験があったとしても、
昨日今日、実装した人ばかりでは無い。むしろそうでない人の方が大多数だろう。
仮に知識も経験もあっても、やってから10年もたてば技術は陳腐化するし、なにより
人間は忘れる生き物だ。仮に覚えていても、突然質問されて10年前のことを上手く
説明するのは無理。
この求人が暗号化技術を専門とする技術者で、Requirementsの最初に
「公開鍵暗号」となっていない限りは、質問の方が不適切だろう。
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:2, 参考になる)
これは質問が悪いと思うんだよな。
用語じゃなく「何を意図した質問なのか」がさっぱり分からない。
仮に公開鍵と伝わったとしても、実装経験のある人間なんかおそらく0.1%もいない。
というか、ツールでも使った事ない技術者はいくらでもいると思う。
とりあえず20年システム屋さんやってるけど、「PGPで送りますか」って言って通じた事は残念ながら一度もないってのが正直な話。
「どのように暗号化しますか」の質問に対しては、圧縮ファイルにパスワードを掛けると回答する技術者が大半だと思う。
というか、企業の情報セキュリティガイドラインがそうなってる。
喩えるなら、自動車修理工場の整備士がどんなに腕が良くて経験があろうとも、タイヤがなぜ4つなのかの理由を答えられるとは限らないという事。
＃リストランテの料理人に「なんでパスタって茹でる時に塩入れんの？」でも可
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:1)
公開鍵暗号のアルゴリズム自体はわからなくても、OpenSSLやGnuPGはソースを公開してる訳ですから、如何にして公開鍵暗号を使って暗号化し、復号化するか。と言う原理自体が分かっていれば、後はソースを見ながら実際のプロセスを実装したり、独自の関数式を暗号鍵の発行や暗号・復号に使うだけならば、当該ソフト・ミドルウェアにポーティング出来ますよね。
# 公開鍵暗号を一から実装しなくても、とりあえず使えれる物を寄せ集めてライセンス侵害しないように作り直せればなんとかなるよね。と云うこと。
そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。
現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:2, すばらしい洞察)
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:1)
＞暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。
確かにそうですね。
只、そういうニーズは少なからずある訳じゃないですか。
クローズドな暗号化手順やアルゴリズムを実装して（試験的に）内輪で使うとか、組み込む側のライセンスの関係で流用が困難だとか。
このタレコミに引用されてる質問は、要はこういう事を出来る人を探していたのではないか？と、勝手ながら推測しておりましたので。
Re: (スコア:0)
暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。
実装できるだけの知識と腕があってそう言うのであれば、大変結構な事ですね。
Re: (スコア:0)
そのうぬぼれがでっかいホールを生みだすのよ
おろかものめ
Re: (スコア:0)
ではその暗号が数学的に安全であることを証明して他の専門家にも安全である事を確認してもらってください。
実装する知識と数学的な知識は別物だから普通の技術者だけでやった結果がWi-FiのWEP脆弱性とかな訳で。
Re: (スコア:0)
そう思ってあえてツールを使うという回答をするなら、そういう考えを説明するべき。
そのうえで、どのツールはどういう仕組みになっていてどんなメリットとリスクがあるからどのツールを選択すべきか
という話をすればいい。
ツールを使うという回答をする時点で、たんにツールを使うだけの人と面接官に勘違いされるリスクに気付くべき。
そういうリスクに対する回避行動を取れない人は、仮に技術者として技術があっても仕事内容の意思疎通に支障が
おきる可能性があるから不採用だろう。
Re: (スコア:0)
DBを使うと脆弱性の危険性があるので独自XMLでデータを保存してます(ｷﾘｯ
って要求概要説明してくれたベンダーさん(元請け)を思い出した。
# PC/携帯共用コードのサイトでノーチェックでサブスクライバID使って認証してたのには吹いたがｗ
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:1)
> そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。
ですね。でも、実装までは求めてないと思いますよ、元記事のramoneThePoolGuyさんは。公開鍵暗号に限らず、暗号システムの全般的な知識を要求したんだと思いますよ。なので、「3DESで暗号化して送ります、鍵は手渡しで」なのでも良かったんだと思いますね。
> 現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
今の人達はフレームワークの使い方とかなんとか、色々お勉強が忙しいのでしょう。公開鍵暗号がどう機能するのかなんて、昔の人みたいな悠長な事をやってられないんだと思います。
Re: (スコア:0)
>今の人達はフレームワークの使い方とかなんとか、色々お勉強が忙しいのでしょう。公開鍵暗号がどう機能するのかなんて、昔の人みたいな悠長な事をやってられないんだと思います。
たぶん、それを「趣味」でやらないといけないってのが一番のネック。
「そんなもんに教育予算回せるか、今すぐ金になる物を勉強しろ」
ってのが企業として当たり前の姿勢なので。
さらに言えば、皮肉にも企業の情報セキュリティ統制がしっかりしてきたために、開発環境として職場とプライベートが隔離されてきてる。
個人が独力でセキュリティに関してエンタープライズ用途も意識した実践的な経験を積む事は通常のキャリアプランでは不可能だと思う。
Re: (スコア:0)
エンコード／デコードエンジンも、たとえ自作できたとしても、自分単独では書きたくないものの筆頭。
脆弱性レポートの定番ニュースに、首を並べることになる。10年前から問題が絶えない。
Re: (スコア:0)
OpenSSLとかjava.securityとかSystem.Securityとかあるんだから、そこは自前実装しない方向に主張しましょうよ！
そういうの使えるだけで意外と感心されたりする。
それは塩入れて茹でた方がうまいから (スコア:1)
ググる先生に教えてもらいました。
パスタを茹でるときには塩を加えるべきか？ [shokuikuclub.jp]
それは塩入れて茹でた方がうまいかららしいですよ。
Re: (スコア:0)
そこはあまり考えてはいけません。
料理は別に手間を最適化すること、結果に対しレシピが最善手であることは求められないので、
「師匠から○○と教わった」場合、例えソレが科学的・論理的に正解ではなかろうと「できたものが旨ければ正当化される」のです。
・塩を入れても入れなくても大して変わらない説
・ソースを絡めた時の味の染みこみが違う説
・突沸を防ぐ説←明確に誤りでマイナー
・沸点上昇説←明確に誤りだと思われるが根強く生き続ける
などなどありますが、結局は論理的かどうか、多数派かどうかではなく、「自分の信じたい説かどうか」でしかありません。
よって、「パスタが産まれ泳いでいた海に最も近い塩分濃度にすることが収穫直後の味を最もよく再現できる」vs「パスタに悪霊が憑依している可能性があるため除霊要素として塩を加える」のいずれかを信じるのが幸福に近づく最善手だと主張したいと思います。
Re: (スコア:0)
Re: (スコア:0)
信じたいとかじゃなくて、味が違うんだから、それでいいじゃん。
ソース無しパスタ何度も食べれば分かる。
Re: (スコア:0)
質問が悪い、に同意だな。
つーかさ、安全な方法で鍵を共有できるなら、共通鍵でもいいんだよね。
目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
状況によってはAES128(MS Office)やAES256(ZIP)の方が公開鍵よりも解読しにくいんだけどねぇ。
公開鍵の場合は、計算時間さえかければ必ずペアの鍵を見つけられるけど、
共通鍵は複合化できたかどうかの判断基準が必要だから。
Re:経験者でも、そればっかりやってるわけじゃないし．．． (スコア:1)
> 目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
ストーリーの内容を見ると...
公開鍵に関する質問と、面接官に情報を送る質問とは、別の質問だと思われます。
また、面接官に情報を送る質問に対して、いまここで送る（別れてから後日送るという可能性はない、あるいは「あなた」「私」という言葉は単なる例として使った可能性はない）という意味に決めつけて解釈し、それに基づいた回答をするのが妥当でしょうか？
Re: (スコア:0)
いや、開発者/アーキテクトの面接なんだから開発の知識聞いてることぐらいわかるよ。
Excelかpdfかとか、ツールの操作方法でも答えるつもりか？
車の整備士の面接で「ハイブリッド車は解りますか？」
と聞いて、「プリウスなら乗ったことあります」
って答えるぐらいとんちんかんな回答だぞ。
Re: (スコア:0)
って。
そんな曖昧で漠然とした質問こそが不適切だという議論をしているとことなのに・・・・
Re: (スコア:0)
今の自分の立場、前後の文脈から、それすら解らん人は流石に要らんだろう。
Re: (スコア:0)
会社「整備士募集」
求職者「応募します」
会社「君、ハイブリッド車は解る？」
求職者「はい、ハイブリッド車の整備士免許持ってます」
会社「実際に整備したことは？」
どこに曖昧な所がある？
Re: (スコア:0)
そこに塩とパスタがあるからさ。
Re: (スコア:0)
> 用語じゃなく「何を意図した質問なのか」がさっぱり分からない。
そう思ったなら、聞き返さないといけないね。
疑問点を解消しないまま仕事を進めるやつとは一緒に仕事できない。
Re: (スコア:0)
いやいや、これは別の話題で言うなら、クイックソートの基本的な仕組みを聞かれてるのに
「Excelですか？それならA->Zって書かれたボタンを押すんですよ」って答えてくるアホの話だろ。
技術が陳腐化するとか求人条件に書く項目とかの話とか、そういう段階の問題じゃないね。
# 一応断っておくが、「パブリック/プライベートキーによる暗号化の基本的なプロセス」ってのは高度な技術力で
# 実装した経験者じゃないと分からないようなムツカシイ話じゃなくて、基本情報処理技術者レベルの試験でも聞かれる話だからね？
Re: (スコア:0)
いやいや、SSLの証明書をサーバに貼ったヤツのうち、PKIを本当に理解して操作したのなんて1/1000くらいだろ。
たんに理解する気がないだけだ。
その証拠に、ActiveDirectoryなんてできて15年経つが、まともにKerberos使えるヤツなんて見たことない。
Re: (スコア:0)
訊き方が悪いってのはある種同意で、長い秘密鍵を持っててもパディングが十分じゃないと繰り返し盗聴された時にいつか秘密鍵が漏れるみたいな話に聞こえる。
Re: (スコア:0)
質問が悪いにしても、
> Excelファイルなのか、PDFなのかといった質問を始めた
これはないな。
求人の内容すら理解してない。
そう答えて許されるのはオペレータの求人の時だ。
Re: (スコア:0)
目の前にいる面接官へは、安全な共通鍵の受け渡しが可能。
鍵の受け渡しが安全であり、十分にランダムな鍵を使用するのであれば、公開鍵暗号より共通鍵暗号の方が堅固である。
標準の実装が暗号化の手段を提供しているのであれば、
それを利用するのが技術的に最短であり、下手なことをして脆弱性を付与する可能性も低い。
よって、Excelファイルなのか、PDFファイルなのかを聞くのは妥当である。