アカウント名:
パスワード:
＞今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、＞20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。
仮にそれを非常に高度な技術力で実装した経験があったとしても、昨日今日、実装した人ばかりでは無い。むしろそうでない人の方が大多数だろう。仮に知識も経験もあっても、やってから10年もたてば技術は陳腐化するし、なにより人間は忘れる生き物だ。仮に覚えていても、突然質問されて10年前のことを上手く説明するのは無理。
この求人が暗号化技術を専門とする技術者で、Requirementsの最初に「公開鍵暗号」となっていない限りは、質問の方が不適切だろう。
これは質問が悪いと思うんだよな。用語じゃなく「何を意図した質問なのか」がさっぱり分からない。仮に公開鍵と伝わったとしても、実装経験のある人間なんかおそらく0.1%もいない。
というか、ツールでも使った事ない技術者はいくらでもいると思う。とりあえず20年システム屋さんやってるけど、「PGPで送りますか」って言って通じた事は残念ながら一度もないってのが正直な話。「どのように暗号化しますか」の質問に対しては、圧縮ファイルにパスワードを掛けると回答する技術者が大半だと思う。というか、企業の情報セキュリティガイドラインがそうなってる。
喩えるなら、自動車修理工場の整備士がどんなに腕が良くて経験があろうとも、タイヤがなぜ4つなのかの理由を答えられるとは限らないという事。
＃リストランテの料理人に「なんでパスタって茹でる時に塩入れんの？」でも可
公開鍵暗号のアルゴリズム自体はわからなくても、OpenSSLやGnuPGはソースを公開してる訳ですから、如何にして公開鍵暗号を使って暗号化し、復号化するか。と言う原理自体が分かっていれば、後はソースを見ながら実際のプロセスを実装したり、独自の関数式を暗号鍵の発行や暗号・復号に使うだけならば、当該ソフト・ミドルウェアにポーティング出来ますよね。# 公開鍵暗号を一から実装しなくても、とりあえず使えれる物を寄せ集めてライセンス侵害しないように作り直せればなんとかなるよね。と云うこと。
そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
＞暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。確かにそうですね。只、そういうニーズは少なからずある訳じゃないですか。クローズドな暗号化手順やアルゴリズムを実装して（試験的に）内輪で使うとか、組み込む側のライセンスの関係で流用が困難だとか。このタレコミに引用されてる質問は、要はこういう事を出来る人を探していたのではないか？と、勝手ながら推測しておりましたので。
暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。
実装できるだけの知識と腕があってそう言うのであれば、大変結構な事ですね。
そのうぬぼれがでっかいホールを生みだすのよおろかものめ
ではその暗号が数学的に安全であることを証明して他の専門家にも安全である事を確認してもらってください。実装する知識と数学的な知識は別物だから普通の技術者だけでやった結果がWi-FiのWEP脆弱性とかな訳で。
そう思ってあえてツールを使うという回答をするなら、そういう考えを説明するべき。そのうえで、どのツールはどういう仕組みになっていてどんなメリットとリスクがあるからどのツールを選択すべきかという話をすればいい。
ツールを使うという回答をする時点で、たんにツールを使うだけの人と面接官に勘違いされるリスクに気付くべき。そういうリスクに対する回避行動を取れない人は、仮に技術者として技術があっても仕事内容の意思疎通に支障がおきる可能性があるから不採用だろう。
DBを使うと脆弱性の危険性があるので独自XMLでデータを保存してます(ｷﾘｯって要求概要説明してくれたベンダーさん(元請け)を思い出した。
# PC/携帯共用コードのサイトでノーチェックでサブスクライバID使って認証してたのには吹いたがｗ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
経験者でも、そればっかりやってるわけじゃないし．．． (スコア: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使って認証してたのには吹いたがｗ