自分の知識があまりない分野での仕事をしている開発者、どれぐらいいる? 128
ストーリー by headless
得手 部門より
得手 部門より
本家/.「Ask Slashdot: What Portion of Developers Are Bad At What They Do?」より
わが社ではシニア開発者/アーキテクトの候補者を探している。現在のところ私は求職者に失望しており、確保できる開発者/エンジニアの質を正直言って心配している。たとえば、今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。他の求職者にも同様に「あなたが非常に機密性の高い情報を私に送るとしたら、あなたは私が復号する情報をどのように暗号化しますか」といった質問をしたところ、この人はExcelファイルなのか、PDFなのかといった質問を始めた。全般的に、私が面接した開発者の大半は重要な概念を理解しておらず、とりわけデータ保護の話になると、ほとんど理解していないことがわかった。他の会社では適切な求職者を探すのに同様の問題に直面していないのだろうか。(このような開発者が安全性を要するサイトを構築すると考えると、正直なところとても恐ろしいと感じる)
専門分野というより、情報技術の基礎知識の欠如では (スコア:4, 参考になる)
>今日私はパブリック/プライベートキーによる暗号化の基本的なプロセス
これって、日本なら、確か基本情報処理技術者のカリキュラムに含まれているよね。
送りたいファイルを、自分の秘密鍵で暗号化し、さらに送付先の公開鍵で暗号化すれば、受取人しか読めないし、送付者が本当に送ったか確認できる。
直接、そこの業務に関係しないとしても、体系的に基礎知識を身につけさせる必要はあると思うので、日本でなら情報処理技術者試験を活用すればいいかと。アメリカでも、体系的な知識を問う認定試験かなんかあるんじゃないかな。
/*
セキュリティ確保のため暗号化メールを使うときに、同じメールアドレスにメール本体と、別メールでカギを送ってくる人がいるけど意味が無い・・(組織のセキュリティ・ポリシーで決められていたりして)。
*/
署名と暗号化は別物です (スコア:1)
Re:署名と暗号化は別物です (スコア:1)
RSAが、ではなく、公開鍵暗号が、では?
実際には、署名には公開鍵暗号とハッシュ関数が、暗号化には公開鍵暗号と共通鍵暗号が、それぞれ組み合わせて使われるわけですが。
Re:署名と暗号化は別物です (スコア:2)
他のアルゴリズムの例として、ElGamal暗号 (もちろん公開鍵暗号) と ElGamal署名は (基本原理は同じでも) 別物です
ElGamal暗号は署名には使えませんし、ElGamal署名(DSA等)は暗号化には使えません。
これに対してRSA暗号は、単一アルゴリズムで署名も暗号化もできます。
対称性はRSA暗号の特性であり、公開鍵暗号すべてに共通する特性ではありません。
Re:署名と暗号化は別物です (スコア:1)
なるほど。
公開鍵で暗号化して、秘密鍵で復号化できるのは、公開鍵暗号一般に共通する性質ではない、ってことですか。
勉強になりました。
ありがとう。
Re:署名と暗号化は別物です (スコア:1)
同一の暗号アルゴリズム(とりあえずRSA)を 暗号化と署名両方に使う場合でも、暗号鍵と署名鍵を別生成すれば 選択暗号文攻撃の直撃は避けられます
危険だから「使わない」のではなく、機能の有無の問題と理解しています。DSAとかElGamalとかで追っかけてみてください。
Re:署名と暗号化は別物です (スコア:1)
#2762274では、問いかけの意味を勘違いしてました。お恥ずかしい。選択暗号文攻撃のくだりは取り消します。
機能の有無と書いたのは、以下のようなことです。
原文を秘密鍵で署名(=復号)して、再度ペアとなる公開鍵で署名確認(=暗号化)した場合、RSAだと原文が得られるけれど、他の公開鍵暗号アルゴリズムだと、原文が得られるとは限りません。
暗号・署名の両用可能なのは、上記処理で原文が得られるアルゴリズムだけ。もちろん、原文から(秘密鍵なしで)署名を得るのが困難、という条件付きです。
Re: (スコア:0)
何を言ってるんだと思ったけど、送付者が本当に送ったか確認する目的なら暗号化じゃなく署名つけとけよっー話?
Re:署名と暗号化は別物です (スコア:1)
Re: (スコア:0)
> これって、日本なら、確か基本情報処理技術者のカリキュラムに含まれているよね。
いつものスラドらしくないコメントだな?
その基本的な資格を持っていない連中が、集まっているところじゃないのか。
資格試験を軽視している人に限って、自分は知らないことが多いということを知らないんだよね。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:2)
持っている資格の一覧見て、関係する資格取得済みだったので普通に話を進めたら、途中で知らないと言い出すのが居たので・・・・・・。
#その資格の取得年月は話をしている日から二年以内だったのにねぇ・・・・
Re: (スコア:0)
ところがだ、本当に安全なのかどうかを説明できたら求職なんてしなくて済むんだな。
P≠NP予想
http://ja.wikipedia.org/wiki/P%E2%89%A0NP%E4%BA%88%E6%83%B3 [wikipedia.org]
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
こういうのは、「本当に安全」か証明できる必要はなくて「十分に安全」が説明できればいいものですので……
Re: (スコア:0)
90年代前半の二種なら含まれてないんじゃないかな。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
でも、その後のカリキュラム改訂で二種レベルに含まれていると思うんだけど。
仮に90年代前半に二種をとったとしても、IT分野で仕事をしているなら、その後の進展に追いつくようにしておくべきでは?
たとえば二十年前に医師免許をとって、その後の医療技術について無頓着な医師がいたとする。で、今、普通に使われている医療技術を用いれば、すぐに直るけど、二十年前の医療水準で治療をして重症化するなど医療事故が起きたら、その医師の治療が適切か問われることになるでしょう。
どの分野でも、それを生業にしているなら、その時代の一般的な水準は習得しておくべきだよね。
Re: (スコア:0)
送りたいファイルを、自分の秘密鍵で暗号化し、さらに送付先の公開鍵で暗号化すれば、受取人しか読めないし、送付者が本当に送ったか確認できる。
自分の秘密鍵で暗号化したら、受取人は読めませんよね。
署名と言いたいのだろうけど。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:2)
>> 送りたいファイルを、自分の秘密鍵で暗号化し、さらに送付先の公開鍵で暗号化すれば、受取人しか読めないし、送付者が本当に送ったか確認できる。
> 自分の秘密鍵で暗号化したら、受取人は読めませんよね。
いや、受取人は読めるでしょう。自分の公開鍵が公開されているなら。てか、自分の秘密鍵で暗号化されているなら、誰でも復号化出来るでしょう。
内容を秘匿する為なら、相手の公開鍵での暗号化で十分ですね。じゃあ自分の秘密鍵での暗号化は難の為かと言えば、「送付者が本当に送ったか確認できる」なんでしょう。署名の代わりですね。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
そうですね。それに細かい話をするのであれば、通常電子署名はデータ本体ではなく、ハッシュ値を作ってそれに公開鍵暗号方式を適用しますね。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
> 秘密鍵で暗号化したものを公開鍵で復号できるかは(そのアルゴリズムに依存し)できるとは限りません。
いや、暗号化アルゴリズムの問題ではなく、暗号化および復号の変換そのもの数学的特性から、
秘密鍵で暗号化したものは公開鍵で復号できることは保証できますよ。
公開鍵による変換を関数 f、秘密鍵による変換を関数 g とすると、これで暗号化・復号ができるというのは、
g(f(x)) = x が成り立つ(公開鍵で変換したものを秘密鍵で変換すると元に戻る)ということなわけですが、これを
f(x) = y
g(y) = x
とわけて考えれば、そこから
f(g(y)) = f(x) = y が導けますから、
「f(g(y)) = y が成り立つ」つまり「秘密鍵で変換したものを公開鍵で変換すると元に戻る」ことになります。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
すみません、よくよく考えてみればその通りですね。不勉強でした。
・暗号化アルゴリズムの定義域と値域が等しい場合(100ビットの平文を暗号化すると同じ100ビットの暗号文が得られるようなアルゴリズムの場合)
→暗号化アルゴリズムと復号アルゴリズムの適用順番を逆にしても使える。署名に利用可能。
・暗号化アルゴリズムの定義域より値域が大きい場合(100ビットの平文を暗号化すると101ビットの暗号文が得られるようなアルゴリズムの場合)
→暗号化と復号の順番を逆にすることはできない。そのまま署名アルゴリズムには使えない。
ってことで。
自分の知識としてずっと「暗号化アルゴリズムは定義域と値域は等しいのが当たり前」(←たぶん共通鍵暗号の一般的な特性に染まってるだけ)と思い込んでました…orz。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
いや、RSAの細かいアルゴリズムは、どーでもいいです。
(理解しているかどうかという問題ではなく、アルゴリズムは今回の問題の本質ではありません。)
暗号化関数f、復号関数gに対して、f(g(y))≡y になるかどうかは、
> 任意のyに対して、f(x)=yとなるxが存在する
かどうかという問題になるわけですが、
・暗号化関数f は単射ですので、xの元の数と、f(x)の元の数は同じです。
また、fの定義域のすべての元に対して、f(x)が定義されますから、
「fの定義域と値域が等しい」のであれば、値域の任意のyに対し、f(x)=yとなるxが存在することになります。
元のコメントの例であれば、100ビットの平文を暗号化する場合、
平文は2100種類あり、それに対応する暗号文も2100種類あるので、暗号文のビット数が100ビットであれば、「2100通りある100ビットの任意のビット列に対し、対応する平文は必ず存在する」ことになります(f(g(y))≡yが成立する)が、
暗号文のビット数が101ビットあると、「2101通りある101ビットの任意のビット列に対し、2100個のの元については対応する平文が存在するが、残りの2101-2100(=2100)個ののビット列には、対応する平文が存在しない」(f(g(y))≡yが成立しない)ことになります。
RSAの場合は、暗号化も復号も最終的に mod d しているので、、定義域と値域が等しいのは明白。
Re: (スコア:0)
海外だと「GAIT」という試験が基本情報処理技術者に近い試験内容みたいですね。
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
ネタにマジレス感があるが、
一応教典には「ファイルとは異なる方法(経路)で」とある。
#某社の場合
Re:専門分野というより、情報技術の基礎知識の欠如では (スコア:1)
機密性の確保はできないけど可用性の確保はできる。
# ウイルス誤検知回避
専門分野は人それぞれ、経験年数だけではなく経歴も必要 (スコア:2)
専門分野は人それぞれ、経験年数だけではなく経歴も必要だということ。
言葉だけ知っていても、実際にコードを書いてみると、想定外の暗黙の機能要件が
あることに気づくだろう。これは、受注した後で開発量が上乗せされてしまうということだ。
平たく言えば、デスマーチ状態になる可能性が高くなる。
だから、全員でなくとも、数人はその分野の専門家がいることが望ましい。
残りのメンバーには、その分野特有の概念を学習する期間を設けるべきでしょう。
むしろ逆を聞いてみたい (スコア:1)
> 自分の知識があまりない分野での仕事をしている開発者、どれぐらいいる?
むしろ「俺は仕事で自分の知識と経験をバリバリ生かして開発してるぜ」って
いうひとがどれぐらいいるかの方が興味がある。
日本の一般の職場では、あまりプロフェッショナビリティが生かせないことが多い
気がするんで。
Re:むしろ逆を聞いてみたい (スコア:1)
専門が本当に上流工程ならいいじゃないか。
一度「じぶんたちのたんとうはなかぬきです」と真面目に回答されたことがあるぞ。
商社ならその回答もありかもしれないが(いや、それでも顧客との窓口という役割は持ってるのが普通だが・・・)、
営業でもなく、客には開発総括として自己紹介してる連中に旨を張って言われるとあきれてしまう。
Re:むしろ逆を聞いてみたい (スコア:1)
>専門が本当に上流工程ならいいじゃないか。
「上流工程」一般の知識や専門なんて評価にも値しない。
銀行業務が隅々まで理解できているとか、製造業の生産管理に超詳しいとかで、しかもいろいろな会社のやり方を知っている、とかが「上流工程できる人」でしょ。
Re:むしろ逆を聞いてみたい (スコア:2, 参考になる)
ニッチな業界の業務SEをやっています。
ユーザーは自社のことしか知らない人が多いため、自分の方が詳しいことが多いです。
お客様の代わりに業務を行って75点を取れるくらいの業務知識があるイメージです。
プログラマーが業務ヒアリングをおこなうことは難しいとは思いませんが、
その業界の言葉を知っているプログラマーでないと、1から言葉を聞くわけにもいかないため、
言葉を知らないと難しいと思います。
大規模開発の時は、外からプログラマーなどの人員を持ってくるため
自分のような業務SEが必要になるのだと思います。
Re:むしろ逆を聞いてみたい (スコア:1)
「プロフェッショナルであること」はふつう「プロフェッショナリティ」だから。
「プロフェッショナビリティ」ってどういう意味の用語なのかな。
profession-able の時点で今ひとつ意味がわからない。
模範解答をつくろう (スコア:1)
うんちくなどどうでもいい。
どう回答すべきだったかを考えよう。
問1「パブリック/プライベートキーによる暗号化の基本的なプロセスを説明せよ」
解答例:
・送り先が公開しているパブリックキーで暗号化して送り、送られた側はプラ
イベートキーで復号化して読む。
問2「あなたが非常に機密性の高い情報を私に送るとしたら、あなたは私が復
号する情報をどのように暗号化しますか」
解答例:
・非常に機密性が高い情報をネットで流すなどありえないので手渡し。
・USBメモリを2つ用意し、片方に復号用の鍵と復号化のためのツール、もう片
方に暗号化されたデータを入れて、別々に管理しろと言って渡す。
暗号化手段は、復号化ツールと鍵が揃っていなければ復号化が困難である
だけでよいので、長いだけの人間が覚えられないレベルのランダム生成パス
ワードで十分。CRC等でデータ破損がないことも確認できる手段があれば
更に良し。
※解答例は例であって正答ではありません。
経験者でも、そればっかりやってるわけじゃないし... (スコア:0)
>今日私はパブリック/プライベートキーによる暗号化の基本的なプロセスを説明するよう、
>20年以上の経験を持つエンジニアに質問したが、このエンジニアは何の知識も持っていなかった。
仮にそれを非常に高度な技術力で実装した経験があったとしても、
昨日今日、実装した人ばかりでは無い。むしろそうでない人の方が大多数だろう。
仮に知識も経験もあっても、やってから10年もたてば技術は陳腐化するし、なにより
人間は忘れる生き物だ。仮に覚えていても、突然質問されて10年前のことを上手く
説明するのは無理。
この求人が暗号化技術を専門とする技術者で、Requirementsの最初に
「公開鍵暗号」となっていない限りは、質問の方が不適切だろう。
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:2, 参考になる)
これは質問が悪いと思うんだよな。
用語じゃなく「何を意図した質問なのか」がさっぱり分からない。
仮に公開鍵と伝わったとしても、実装経験のある人間なんかおそらく0.1%もいない。
というか、ツールでも使った事ない技術者はいくらでもいると思う。
とりあえず20年システム屋さんやってるけど、「PGPで送りますか」って言って通じた事は残念ながら一度もないってのが正直な話。
「どのように暗号化しますか」の質問に対しては、圧縮ファイルにパスワードを掛けると回答する技術者が大半だと思う。
というか、企業の情報セキュリティガイドラインがそうなってる。
喩えるなら、自動車修理工場の整備士がどんなに腕が良くて経験があろうとも、タイヤがなぜ4つなのかの理由を答えられるとは限らないという事。
#リストランテの料理人に「なんでパスタって茹でる時に塩入れんの?」でも可
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:1)
公開鍵暗号のアルゴリズム自体はわからなくても、OpenSSLやGnuPGはソースを公開してる訳ですから、如何にして公開鍵暗号を使って暗号化し、復号化するか。と言う原理自体が分かっていれば、後はソースを見ながら実際のプロセスを実装したり、独自の関数式を暗号鍵の発行や暗号・復号に使うだけならば、当該ソフト・ミドルウェアにポーティング出来ますよね。
# 公開鍵暗号を一から実装しなくても、とりあえず使えれる物を寄せ集めてライセンス侵害しないように作り直せればなんとかなるよね。と云うこと。
そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。
現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:2, すばらしい洞察)
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:1)
>暗号化システムの独自実装ってでっかいセキュリティホール作る一番簡単な方法ですよね。
確かにそうですね。
只、そういうニーズは少なからずある訳じゃないですか。
クローズドな暗号化手順やアルゴリズムを実装して(試験的に)内輪で使うとか、組み込む側のライセンスの関係で流用が困難だとか。
このタレコミに引用されてる質問は、要はこういう事を出来る人を探していたのではないか?と、勝手ながら推測しておりましたので。
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:1)
> そういう辺りの話をしたかったんだと思いますが、公開鍵暗号を意識して使ったか、もしくはそれに興味を持った経験がある人で、そこそこ業務経験があれば、意を汲んで話せる気がするんですけどね。
ですね。でも、実装までは求めてないと思いますよ、元記事のramoneThePoolGuyさんは。公開鍵暗号に限らず、暗号システムの全般的な知識を要求したんだと思いますよ。なので、「3DESで暗号化して送ります、鍵は手渡しで」なのでも良かったんだと思いますね。
> 現実は予想の斜め上というか、そこまで好奇心旺盛な人がいなかったという辺りが、この話の肝なんじゃないですかね。
今の人達はフレームワークの使い方とかなんとか、色々お勉強が忙しいのでしょう。公開鍵暗号がどう機能するのかなんて、昔の人みたいな悠長な事をやってられないんだと思います。
それは塩入れて茹でた方がうまいから (スコア:1)
ググる先生に教えてもらいました。
パスタを茹でるときには塩を加えるべきか? [shokuikuclub.jp]
それは塩入れて茹でた方がうまいかららしいですよ。
Re: (スコア:0)
質問が悪い、に同意だな。
つーかさ、安全な方法で鍵を共有できるなら、共通鍵でもいいんだよね。
目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
状況によってはAES128(MS Office)やAES256(ZIP)の方が公開鍵よりも解読しにくいんだけどねぇ。
公開鍵の場合は、計算時間さえかければ必ずペアの鍵を見つけられるけど、
共通鍵は複合化できたかどうかの判断基準が必要だから。
Re:経験者でも、そればっかりやってるわけじゃないし... (スコア:1)
> 目の前にいて、安全な方法で鍵を共有できる相手に送るのに、「公開鍵で答えないとダメ」ってのは何でよ。
ストーリーの内容を見ると...
公開鍵に関する質問と、面接官に情報を送る質問とは、別の質問だと思われます。
また、面接官に情報を送る質問に対して、いまここで送る(別れてから後日送るという可能性はない、あるいは「あなた」「私」という言葉は単なる例として使った可能性はない)という意味に決めつけて解釈し、それに基づいた回答をするのが妥当でしょうか?
Re: (スコア:0)
いやいや、これは別の話題で言うなら、クイックソートの基本的な仕組みを聞かれてるのに
「Excelですか?それならA->Zって書かれたボタンを押すんですよ」って答えてくるアホの話だろ。
技術が陳腐化するとか求人条件に書く項目とかの話とか、そういう段階の問題じゃないね。
# 一応断っておくが、「パブリック/プライベートキーによる暗号化の基本的なプロセス」ってのは高度な技術力で
# 実装した経験者じゃないと分からないようなムツカシイ話じゃなくて、基本情報処理技術者レベルの試験でも聞かれる話だからね?
Re: (スコア:0)
いやいや、SSLの証明書をサーバに貼ったヤツのうち、PKIを本当に理解して操作したのなんて1/1000くらいだろ。
たんに理解する気がないだけだ。
その証拠に、ActiveDirectoryなんてできて15年経つが、まともにKerberos使えるヤツなんて見たことない。
どのように暗号化しますか (スコア:0)
私はツールを使うと答えると思う。
クライアントはそれでは満足できなかった。
それはしかたのないことでは。
Re:どのように暗号化しますか (スコア:1)
今時の圧縮ツール…rarや7zipなど…には、共通鍵暗号のオプションがあるので、それを使うか、もしくは、相手がgnupg辺りの公開鍵を出していれば、それで暗号化するでしょうね。
神経質な場合は(どの程度有効性があるかはともかく)、gnupgの前段に圧縮ツールの暗号化を噛ませる。
更に神経質な場合には、ワンタイムキーを(これまた暗号化して)別途やり取りするか、発行のシードを共有しておいて、圧縮ツールの復号パスワードにそこで発行したワンタイムキーを用いる。
…というレベルならば、インターネットを能動的に使ってきてるユーザはクリア出来てるだろう…と思った私が甘かったんでしょうね。これを読むとですが。
Re: (スコア:0)
質問に答えてないので問題外です
Re: (スコア:0)
ツールを使うにせよ、鍵の交換が必要なのでそのプロセスを訊かれてるんでは。
使い捨ての公開鍵を発行して電子署名付きの平文で相手に送り、相手の公開鍵を暗号化して送り返してもらう。
使い捨ての秘密鍵で相手の公開鍵を復号。
相手の公開鍵で自分の本当の公開鍵を暗号化して送信。
以後の送信は交換した公開鍵で行う。
とか。
Re:どのように暗号化しますか (スコア:2)
> 公開鍵を暗号化して
発想が斬新すぎて何とも(笑)
Re: (スコア:0)
電子署名は誰の?
設計開発したシステムにバグがあった場合 (スコア:0)
設計開発したシステムにバグがあった場合...
難しかったからバグは致し方無い
と自分を納得させる開発者。
Re:アリスがボブに秘密書類を送るケース (スコア:1)
CからIの人はどこ行った?