パスワードを忘れた? アカウント作成
6488 story

暗号エキスパートPaul Kocher @本家 16

ストーリー by Oliver
ROT26愛用 部門より

oddmake 曰く、 "今回の翻訳企画は、国際的に著名な暗号研究者のPaul Kocher氏への本家でのインタビュー です。氏はDES暗号解読コンピュータの設計やSSLv3の仕様策定に関わった人物で、RSAやMicrosoftへもセキュリティついてコンサルティングを行っているそうです。
訳者はセキュリティについては素人に毛の生えた程度の知識しかないので、今回の翻訳も多くの方に手伝っていただきました。別に記して感謝もうしあげます。"

1)重大な脅威?
Prizmによる質問

暗号解析を勉強しているときに、私はTiming Attackや差分攻撃法といったいくつかの興味深い攻撃法を学びました(私の記憶が正しければ確かあなたの専門分野です)。こうした攻撃は確かにさまざまの暗号文の暗号解析に役立ちそうに見えます。が、実際のセキュリティという点でどのくらい実用的なのでしょうか。言い換えればこうした手法が攻撃者によって活用される可能性はどのくらいあるのでしょうか?

Paul:

それは標的によるだろうね。もし君が護ろうとしているシステムが攻撃者の努力に見合うものでないか、もっと簡単に侵入する方法があれば、その可能性はあまり無いだろう。一方、もし君が非常に価値あるデータ(金、株価に影響するような情報、Star Trekのエピソード、政府の機密情報、等)を保護しているのだったら、君は頭の切れる人達が君のセキュリティを攻撃するだろうと考えなければならないね。私達はクレジットカード会社やその他スマートカード会社を支援してテストプログラムを作るのに時間をたくさん費やしている。 -- 彼らの製品は差分攻撃法やtiming analysisや他の精巧な攻撃が本当の問題であるようなハイリスクの環境で動作させる必要があるんだ。

2)最悪の実装は?
burgburgburgによる質問

あなたがコンサルティングをしていて(実名を出さないで結構です)、あまりに出来が悪く、セキュリティ上あまりにも問題があって、脆弱性への対策があまりに無防備な企業のセキュリティ実装に出くわして、サーバをシャットダウンしてドアをロックしてセキュリティのSWATチームを呼びたいという抗し難い衝動を感じたことはありますか? 暴露してその会社の株価を暴落させたいと実際に感じたことは? 誰かの頭を上からボコするのを踏み止まらなければならなかったことは? セキュリティ担当がブラックハット・ハッカー/競争相手のスパイ/外国の秘密工作員でないと確信するために、人事に調査してはどうかと尋ねたことはありますか? あなたが見た中で最悪の実装はどのくらい悪いものでしたか?

Paul:

不快に思わなかったシステムをリストアップということにさせてもらわないと、タイプ数が大変なことになるね。

抜け目なく才能があって経験豊かで性根を据えた攻撃者なら、どんな標準的な商用製品からでも欠陥を見つけることができる。評価プロジェクトは概して非常に限られた予算しかつかないが、それでも私達がセキュリティ評価したものの半分以上から破滅的問題点が見つかっている。

もっともよくある状況はシステムのセキュリティ目標が、設計者も実装者もテスターも決してどんなエラーも起こさないとしたときにのみ理論的には達成できるようにしていることだ。例えばほんの僅かなパフォーマンス向上のために、オペレーティング・システムがカーネルへ膨大な複雑さを押し込め、デバイスドライバにシステムを自由にできる権限を与えるようなことをしている。もし技術者が誤謬を犯さないならこのアプローチは素晴らしいが、彼らが人間であるならばそれはトラブル製作法になるのだ。

私がもっとも腹立たしく思うのは悪いソフトウェアではない -- 私達が企業に重大な問題について告げてもNDAにサインしているから問題が露見せず売上げに影響しないと、彼らが無視を決め込む、そういう状況だ。もし君の会社が承知の上でセキュアでないまたは信頼できない製品を、セキュアだと広告していたら、それについて何かしてくれ。意図的に顧客を誤誘導することは違法で、非道徳で、巨大な賠償責任リスクでもある。(キーワード:Enron,アスベスト,タバコ)

自身のセキュリティについて誤誘導したり支持されない主張をした企業の製品を、ユーザが買い続けるのも腹立たしいことだ。もしユーザがセキュリティに金を払わなかったら、企業はセキュアでない製品を売り続けるだろう(そして私達の市場は比較的小さなままだろう:-)

最悪のセキュリティの例として、私は次のパスワード検証コードをノミネートする。


gets(userEntry);
if (memcmp(userEntry, correctPassword, strlen(userEntry)) != 0)
return (BAD_PASSWORD);

ROT13 SPOILER: Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratgu bs gur hfre ragel, abg gur yratgu bs gur pbeerpg cnffjbeq. Bgure cbgragvny ceboyrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre. [Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevgl rkcrevrapr, pbzzhavpngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr) pbzcnal, ivfvg uggc://jjj.pelcgbtencul.pbz/pbzcnal/pnerref.ugzy.]

ROT13してあるネタばれ:(このコードは正規のパスワードの長さではなくユーザ入力の長さを使ってしまっているため、空のパスワードがこのチェックを通過してしまうだろう。他の潜在的な問題点(バッファーオーバーフローとか)は読者への練習問題として残しておく。[厚かましくも追記: もし君がこういう問題を楽しめて、強固なセキュリティの経験があって、会話ができて、楽しい(そして儲かる)会社での仕事を欲しているなら、 http://www.cryptography.com/company/careers.html に来てくれ。])

3)インターネットは壊れてる?
bpfinnによる質問

インターネットは元来似たようなプロジェクトで協同作業する研究者が利用するために設計され、そのためセキュリティはデザインの一部になっていません。セキュリティを主要な設計上の目標とするような現在とは異なるインターネットの設計と構築を提唱する気はありませんか? あるいは私達は現在のインターネットを微調整して今そこを流れている悪意の量を減らすことができるのでしょうか?

Paul:

私は核となるインターネットが問題とは思わない。いくつかのプロトコルはアップグレードが必要だが、インターネットは認証も品質保証もしないコミュニケーションを提供するという大きな仕事をしてきている。セキュリティポリシーをネットワーク層に適用しようと試みることは、インターネットを偉大なものしている自発性とオープンさを破壊することになるだろう。言い換えれば、私達にはインターネットが常に危険がつきまとうものであり続けるという事実に対処する方法を考える必要があるということだ。

私が改良されたセキュリティが本当に必要であると思う部分はプロトコル、アプリケーション、そしてインターネットを利用する装置だ。例えば、ムーアの法則で計算能力はとても安価なものになり、全てのWebページを暗号化してもいいくらいになった。同様にIPSEC,VPNトンネル,暗号化電子メールはもっと広く使われるべきだ。

もちろん、大きなネットワークにはいつも予測不能な複雑なセキュリティリスクがあるだろう。であるから、もし君がクリティカルなシステムを扱うなら、可能な限りネットワークから遮断するべきだ。

4)飛び込め
Accidental Hackによる質問

新入りは何をしでかすでしょうか? 私はサーバセキュリティに幾分かの責任のある立場に、正しい背景知識無しに置かれて(そして責任はしっかりかぶって)ます。いかにすれば私は頭を整理して重要な問題に集中し、ドアをしっかり閉め誰かにやりたい放題にさせないようにしたと確信が持てるでしょうか? 本や記事を読むことは十分ではないようです。しかしもしそれが一番の出発点なら、お勧めは何ですか?

Paul:

君は実際には二つの質問をしているね:いかにしてセキュリティについて学ぶかということと、何をしたらいいかわからない状況に置かれ時、君は何をすべきかということと。

セキュリティや暗号技術について学びたいと欲する人々にとって、私は実地経験の確かな提供者だ。君がセキュリティバグについて聞いたとき、いって何が実際におかしくなったかを見なさい。DES,AES,RSAそして君の任意精度ライブラリを実装しなさい。貧弱に構築されたLinuxマシンを2台セットアップし、それらに侵入するんだ。スニッファをインストールして君自身のネットワークのトラフィックを監視するんだ。ソフトウェアプログラムを観察し修正するんだ。C/C++を学ぶんだ。オープンソースの暗号コードの既知のバグを研究し新しいのを探すんだ。もし君が仕事で予算がつくのなら、セキュリティの専門家を雇いたくさんの質問をするんだ。君が何をするのせよ、法律に慎重に(君が同意しないものであっても)従って倫理的に振舞うんだ。

君の技術水準を越えた状況に君が置かれたとき何をするかという質問は、究極的には関わってくるリスクによるものだ。普通のサーバ(会社の電子メールやそういったもの)の場合、もし君がきちんとバックアップをとっているなら時折起きる問題は破滅的ではない。

一方、失敗の結果や成り行きが深刻なものである場合には、君は、開胸手術やボーイング747の操縦を私が試すべきではないように、ただ「やってみる」ことはできない。例えば、もし君がクリティカルなインフラや攻撃目標になりやすいマシン、ペイテレビのネットワーク(か、海賊行為と関わるもの全て)とか大きな顧客データベースを扱っているなら、助けを得るんだ。たとえ君が経験豊かだったとしても、君は誰か君の仕事をチェックしてくれる人を必要としているんだ。君が誰かを雇うときには、彼らが質問に答え、君を教育し、良いドキュメントを提供してくれるように念を押すんだ。マッドサイエンティスト、本格的なエンジニアリングをしたことのない人々、セキュリティ監査を脅威とか侮辱とかと受け取る人全てを避けるんだ。

5)量子コンピュータと暗号
Nova Expressによる質問

量子コンピューティングの進歩は現代の最新の暗号技術でさえ時代遅れにしてしまうのでしょうか? 暗号技術が量子コンピューティングが示しだす挑戦に打ち勝つ方法はあるのでしょうか? そして、もし量子コンピュータが現代の最新の暗号を破れるとするなら、そうなるまでにはどのくらいかかるのでしょうか?

Paul:

量子コンピューティングはこの十数年の理論計算科学上、おそらくもっともクールな発見だろう。なぜならそれは計算のルールを完全に変えてしまうからだ。

しかし、実用的問題に関する限り、私達が心配しなければならない他の問題に比べるとそれは際立ったセキュリティリスクにはならない。私は量子コンピュータが従来のコンピュータを次の50年のうちに(例えば)RSA解読で凌駕することは非常に起こりにくいことだと考えている。私の懐疑の理由は、実用になる量子コンピュータを製作するのに関わってくる課題が眩暈がするようなものであるということだ。例えば、量子コンピュータは逐次動作しないため巨大にならざるを得ないが、(フリップフロップ無しの、組み合わせロジックだけのハードウェアを想像してみなさい)コンピュータが大きくなればなるほどデコヒーレンスはより大きな問題となっていく。エラー訂正テクニックは提案されているが、それはさらに回路の複雑性を増していく。

もし誰かが任意に大きな量子コンピュータを製造する方法を見つけたら、それはほとんどの現存する公開鍵暗号スキームの終焉となるだろう。共通鍵暗号は、セキュリティを同じレベルに保つために鍵の長さは倍になるだろうが、機能し続けるだろう。

注:量子コンピューティングは量子暗号とは違う。後者は盗聴を防ぐ方法であり、偏光された光子とエンタングルメントをふつう利用している。量子暗号は実装は可能であり素敵な研究対象になるのだが、私は、それが通信者に光子を直接交換することを求めるために、どんな実用的利用法も見出せない。その結果、それはパケット網では機能しない。さらに、AESといった現在のアルゴリズムは同じこと全部をでき、さらに他のこともできる。結果として、量子暗号が意味あるものになるような唯一のシナリオは、暗号学を葬り去るような信じ難い奇怪な発見、例えば誰かがP=NPを示すような場合だけだろう。

6)SSLとForward Security
Effugasによる質問

Paul、第一に、ここでインタビューを受けることを承諾してくれたことに感謝します。非常に嬉しいことです。

私は、RSAの秘密鍵の妥協のためにSSLのセキュリティアーキテクチャーが破滅的な失敗をしてることをあなたがちっとも気にしないとしたら、好奇の念を抱きます。攻撃者は文字通り、一年の間全てのトラフィックを監視して、一回だけ解読し鍵を盗み、そしてその年の全てのトラフィックだけでなく次の年のぶんも全て非能動的に労せずに解読することができるのです。そしてもし彼がもっと能動的な攻撃をしたければ -- セッションハイジャックとか、悪意あるデータの挿入とか、その他いろいろ -- それもたやすいことなのです。

つまり、なぜでしょう? とても多くの努力がセッションごとの秘密鍵をセキュアにすることに払われているというのに、何が非対称暗号(公開鍵)を脆弱なままにしているのでしょうか? ええ、PGPはこうした故障に対して同じように脆弱です。しかしPGPは他のホストへのソケットといった特長を持たないのです。

より重要なことですが、この他は賞賛すべきアーキテクチャーの、この欠点に神経質な人々にたいして何をしてやれるでしょうか? 私はDSAモードを見ましたが、それはいっこうに広まらないように見えます(そのことはもっともそれを必要としているサイトにとっての妥当性を無くしています)。短期的RSAは興味深くみえますが、Rascolaのドキュメントによると最大でも512ビットのセッションごとの非対称鍵(不十分です)をサポートしているに過ぎないのです。もしVerisignが毎日新しく生成した鍵に署名するのなら、それは機能するでしょう -- ですが、おそらくそのサービスを得るために会社の一部の売却手続きに署名することになるでしょう。一個の完全修飾ドメイン名に結びついた一個の長い鍵にサインし、長時間の証明書から割り振った時間割の中の一時的な鍵にいくつでも署名できるようにするというのは可能でしょうか?

あなたの示してくださるであろうご明察に重ねて感謝もうしあげます。

敬具

Dan Kaminsky
DoxPara Research

Paul:

私はSSL3.0のDSAオプションつきの一時的Diffie-Hellmanを特にperfect forward secrecy(PFS)を提供するように設計した。DSAのパフォーマンスが懸念材料だったことは確かだが、それはもはや問題ではない。

[*]もし君がDSAを避けたいなら、君は通常のRSAハンドシェイクをしてその直後に認証されていない一時的Diffie-Hellmanハンドシェイクで再ネゴシエートすればいい。(SSL3.0とTLS1.0はいずれも、通信者に任意の時期に再ネゴシエート要求を出すことを認めており、その場合の再ネゴシエートのプロセスは最初のハンドシェイクの元に保護される。)君の質問にもあるとおり、一時的な証明書は適切な認証局が提供するなら機能するだろう。

SSL3.0でのPFSの義務づけは、パフォーマンス上の必要条件や、レガシーRSA証明書との互換性の維持の必要性や、ライセンス問題(1996年当時、RSAは特許になっておりほとんどの会社は特許のライセンスではなく限られたRSAツールキットのライセンスを持っているだけだった)のために実現できなかった。

全体として、私はSSL3.0がとてもたくさんの方法で使われ、世界でもっとも広く展開されている暗号プロトコルとなっているのを見て喜んでいる。私のした設計上の選択について討論すべき理由があるものの、私はプロトコルのPFSの扱いがその一つであるとは思わない。いくつかの実装についてはバグがありerror-analysis攻撃に対処するガイドラインが付加されるべきだが、全体としてプロトコルはよくできている。

[*]1996年(SSL3.0仕様が出来た時)、コンピュータは現在の速度の4%しかなかった。(ムーアの法則は7年間で速度の倍増が4.67回あると予測している。)今日、どんな現代のCPUも毎秒200個以上の2048ビットDSA認証を十分にこなせる。平均10ハンドシェイク/秒は負荷5%にしかならないが、それでも1CPUにつき864,000コネクション/日に等しい。君が最大級のWebサイトのひとつを動かしているので無い限り(あるいはセッションの再開を無効にするように設定ミスしていない限り)、これは問題にはなりにくい。本当に大容量サーバのためには、SSLアクセラレータがコスト的に見合いでき、それはとても高速だ。概して、今日標準的な暗号操作のスピードが実際に問題となる状況はほとんど無い。

7)開かれたP2Pコミュニティ内での信頼
smd4985による質問

オープンソースのP2Pアプリ(gnutella)を製作しているソフトウェアエンジニアとして、私達は大きな問題に直面しています:プロトコルを実装しているアプリケーションならいかなるものでも参加することのできる開かれた環境で、どうすれば信頼を確立することができるでしょうか? 私達は信頼状態を確立するためにさまざまな暗号システムを考えてみましたが、それはいくつもの致命的な欠陥がありました -- 何らかの一極集中(P2P環境では絶対駄目です)を必要する、「信頼できない」ベンダを排除する、などです。

私達は開かれた環境を維持しつつ通信者間で信頼を確立するために何ができるでしょうか?

Paul:

確かに分散型の信頼の確立(PGPのWeb of Trustが頭に浮かぶ)の方法が存在している。しかし君は信頼と完璧な匿名を同時に得ることはできない。君ができるもっとも信頼に近いことは過去の行動と主張に基づいて参加者を評価することだ。君は設計を始められるようになる前に、何を可能にしようとしているか、何を防ごうとしているか、合法的な行動と違法な行動をどんな自動化されたルールで分別するかについて、明確に定義する必要があるのだ。

(注:私は質問が合法的なP2Pアプリケーションについてのものだと推定しているが、P2Pシステムでの海賊行為は、著作権保有者達を立法府による法的救済を求める方向へと駆り立てている。インターネットが大規模に知的財産権を犯すことに使えるという事実は、その行為を道徳的にするわけではない。)

8)どう思います?
Charles Dodgesonによる質問

私が最初にある脆弱性の発見(例えば、私はあなたの名前をあなたの発見報告のMD5から覚えています)について読んだときから、私はつねにシステムの設計者やその時点でのコミュニティの枠組みを超える発想に衝撃を受けています。同じ衝撃をTiming攻撃やそれに似たようなことについても受けています。私が百万年かかっても思いつかないことがあるのです。私にあなたのような精神がいかに働くかについて、そしてこれがどこまで訓練可能な技術であるか何か教えてくれませんか。

私はふつうは、「枠にはまらない考え方」という決まり文句が嫌いです。でもここでは完璧にあてはまると思います。

Paul:

セキュリティの仕事は複数のレベルでシステムを理解することが必要だ。例えば、差分攻撃法の発想は、トランジスタレベルの特性が論理回路に影響し、それがマイクロコードに影響し、さらにそれがCPUに影響し、暗号アルゴリズム、プロトコルと影響していって、それがビジネスの要求に影響するということに関連があるのだ。単一のレイヤで仕事をするのに慣れたエンジニアにとってセキュリティ分析の結果はしばしば驚くべきものに見える。幅広い経験も重要だ。セキュリティ問題は、別々の人々によって設計された領域間の意外な相互作用が関わっているものが数多く、大部分だからだ。

私にはしばしば二つの事柄が無視されていると思えてならない、低レベルのプログラミングと統計だ。これはいかにモノが実際に働くかということを理解し、システムが故障する可能性を評価するのに必須だ。懐疑的な意識も重要だ。あなたが納得するまで、物事は悪いと考えるようにしてみなさい。

問いかけて役立つような質問は次のようなものがある:

  • どんな情報や可能性が攻撃者に利用されうるか?
  • まだ隅っこに隠れていて誰も調べていないような事例には、どんなものがあるだろうか?
  • システムを設計したの技術者は、怠惰あるいは未熟な設計者ではなかったろうか?
  • 利用者はどんな状態に置かれるだろうか?
  • セキュリティ防衛線のもっとも複雑な部分はどこだろうか?(複雑な部品はもっとも故障しやすい。)
  • どんな暗黙の仮定がなされているだろうか、そしてそれは正しいだろうか?

もし君がどんな風に評価をはじめていいか不確かな時には、設計の概略を書き出してみたまえ。君はそうすれば目標と自分のした設計とを比較することができる。そこでの相違点は大抵、君のやった間違いを明らかにする(良い学習方法だ)か、あるいは目標のシステムの問題点を明確にする。

9)テクノロジーは私達を追い越しているのでしょうか?
Cozによる質問

質問をする機会を与えてくださってありがとうございます。

最近20年間で暗号技術は、主要な政府機関やビッグビジネス、また変わり者のホビイストや研究者のものから、誰も参加できる(している)大きな公共的な産業へと移り変わり、ほとんど毎週のように新しいアルゴリズムや新しいアプリケーションが発表されています。その一方で、暗号システム自体の原理的欠陥の発見に努めている人についての話は、さまざまな暗号システムの実装の脆弱性ほど頻繁には聞かれません。

これらの事実から、私達には(他でもないあなたのSSL3.0などの)暗号システムの実装を検証し「推奨」することに視点を移す必要がある、とお考えになりますか? それとも「暗号コミュニティ」の重点は引き続き、暗号システムの革新とそれを用いた新しいアプリケーションに置かれるべきなのでしょうか? 暗号システムがきちんと実装されているかを検証する者がいることの重要性について、どのようにお考えですか?

Paul:

検証は間違いなく、もっとも重大な、セキュリティ分野における未解決問題だ。

私はセキュリティを確率的問題と見ている -- 失敗する可能性は常にある程度存在するが、検証は失敗の公算を減らす唯一の方法である、とね。例えば、よくテストされたコードは、テストされる前の同一部分と較べてよりセキュアになっている。

革新は研究者側にとって偉大なことであるが、現実世界のシステムは可能な限りよくテストされた技術を使うべきだ。たとえば、アルゴリズムでは、何か別のものを使わなければならない(稀だ)のでなければRSA、triple DES、AESやSHA-1をCryptography Research社では使う。私達はこれらのアルゴリズムを、皆よくレビューしてあり、予測できない暗号解析的な攻撃のリスクが低くなっているから使う。対して、新しいスキームの破滅的欠陥はとてもよくあることだ。

君が基本的アルゴリズムの段階を超えると、検証は不幸にも多くの理由により極端に難しくなる。

  • ソフトウェアの複雑さは指数関数的に増加するが、熟練のセキュリティ専門家(と彼らの知性と生産性)はおおむね一定のままだ。
  • 多くの設計は貧弱に構築もしくは実装されており検証できない。
  • 検証は新しいコードを書くよりもっとずっと難しい(そして楽しくない)だからほとんどの人々はそれを避ける。
  • 技術者はテストしきれないほどの多量のコードを書いていく。
  • 今ある検証ツールは本当に貧弱なものだ。
  • ほとんどのユーザはより良いセキュリティに余分の金を支払わないため、セキュリティテストのコストは正当化し難いだろう。
  • ユーザにとってよくテストされた製品とそうでない製品の区別をつける簡単な方法はない。
  • テストには長い時間がかかり、製品の立ち上げを遅くする。
  • 攻撃者は標準に自分自身を限定することは無いので、セキュリティ評価を標準化する簡単な方法はない。
  • 90%の欠陥を捕捉する事は、もし攻撃者が欠陥を見つけるのに10倍の努力を集中する気があるなら役に立たない。
  • 開発者はリスクの結果を引き受ける者ではないから、セキュリティのために苦痛に満ちた犠牲をはらう動機に乏しい。

長い目で見て、私はセキュリティが薬品もしくは航空産業のようになるだろうと思っている。法規制と保障責任が安全を課すが、製品開発を非常に高くつくものにするだろう。現在行われている状況よりどれだけいいか悪いかには関係なく、それは避けられないものに見える。

10)Re:fhnlsfdlkm&5nlkd%Bvbcvbc
Annoymous Cowardによる質問

0eefa Uv, V'z jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher...
(やぁ、僕はあなたがROT13の未来をどう考えているんだろうと思っているよ。僕はそれはとってもセキュアだって聞いているんだけど…)

Lbh pna ernq guvf? Qnza!
(これを読めるの? なんてこった!)

Paul:

すごい! Juvyr lbh znl unir svtherq bhg zl fhcre-frperg EBG13 pvcure, abobql jvyy rire penpx *guvf* zrffntr orpnhfr V fjvgpurq gb bhe hygen-frperg cyna O: nccylvat n Pnrfre pvcure 13 gvzrf :-).
 (だが君は私の極秘のROT13暗号を解けるかもしれないが、私は私達のチョーひみつ計画Bに移行したから、誰も*この*メッセージを解読することはできないよ。それはシーザー暗号を13回適用するんだ。)[訳注]

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by fengshen (11985) on 2003年09月10日 16時13分 (#395014) 日記
    非常に価値あるデータ(金、株価に影響するような情報、Star Trekのエピソード、政府の機密情報、等)

    >Star Trekのエピソード
    Σ(゚Д゚);
    なるほど、確かに。人によっては明日の株価よりはるかに
    価値があるかも。
  • by unaz (2331) on 2003年09月10日 16時44分 (#395034)
    >長い目で見て、私はセキュリティが薬品もしくは航空産業のようになるだろうと思っている。法規制と保障責任が安全を課すが、製品開発を非常に高くつくものにするだろう。現在行われている状況よりどれだけいいか悪いかには関係なく、それは避けられないものに見える。

    長い引用すまないけれど、やはりきちんとアプリケーションにセキュリティを施すには強制力が必要だと痛感します。
    だって、めんどくさいんだもん.....本当に。
  • by Anonymous Coward on 2003年09月10日 11時40分 (#394841)
    ROT13 SPOILERの翻訳文を平文で書くのはよろしくない。

    回答のネタバレ部分を意図的にROT13化することで、
    このアンケートが暗号専門家に対するものだという雰囲気を
    醸し出しているのに、
    そんなネタバレを平文で垂れ流していたら台無し。
    • ROT13 SPOILERの翻訳文を平文で書くのはよろしくない。

      そこまで言うなら,もう一押しして, 「やっぱり,日本語部分は rot47 しないと!」って言わなきゃ.

      rot47 も,もう忘れられた技術なのかしら.

      親コメント
      • by Anonymous Coward
        せっかく往古の技術を懐かしみながら楽しむチャンスだったのに
    • by Anonymous Coward
      ROT13 で戻すのがめんどうなので、平文で書いてもらって OK。

      てゆーか、しょーもないケチつける輩が多すぎ。
    • by Anonymous Coward
      雰囲気を台無しにされると思ったら原文を読めばいいのに…。
      • by Anonymous Coward
        > 雰囲気を台無しにされると思ったら原文を読めばいいのに…。

        ネタバレに対する苦情に対してその返し方はまずいと思うが…。

        ネタバレに対する価値観は人それぞれ大きく違うみたいですね。
  • by Anonymous Coward on 2003年09月11日 2時28分 (#395374)
    CASTを使わずtriple DES
    MD5を使わずSHA-1
    というのが意外

    CASTオタとしてはそのあたりの更なる意見を聞いてみたい
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...