「公開鍵暗号方式」を含む日記 RSS

はてなキーワード: 公開鍵暗号方式とは

2018-12-01

anond:20181201204757

ちょっと調べた

電子署名公開鍵暗号方式も使われてるってのを知らなかった

電子署名ったって単純に判子やサイン画像貼り付けるだけだろとか考えてた自分が恥ずかしい

2018-05-11

10年以上ぶりに名探偵コナン映画を観てきた。

最後に観たのは探偵たちの鎮魂歌から、実に12年ぶりである

地上波はそれ以上に観ていない。


以下、ネタバレあり感想


まず、キャラの演技だいぶ変わってる気がする。

特にアガサ博士少年探偵団、灰原に違和感。まぁ10年以上も経てば変わるか。

それと、声に老けを感じてしまい、少し寂しく。そのうちドラえもんみたいに世代交代もあるのだろうか。

おっちゃんは声優も変わって演技も違うのだけど、そんなに抵抗はなかった。

ストーリーについては、「いやいやそうはならんやろw」とか「なんでやねんw」って突っ込みどころが多くて、内心突っ込みながら楽しんでいたんだけど、世間一般的には重厚ストーリーという評判らしい。マジか。

安室さんは初見だけど、29歳で(恐らく年功序列が色濃く残っているであろう)公安秘密組織で指示を出せるくらいの地位があるという日本中の才能とコネ特異点のような存在が、IoTテロ可能性に思い至らないものだろうか。あまつさえスマホにこっそり盗聴アプリを仕込む知識もあるというのに。

やたらコナン上げしていたのが気になった。(まぁ原作やら他のエピソード理由が描かれてるんだろうけど)

ついでにNW経由で操作されるだけで電子機器が爆発炎上までしちゃうあの世界の安全基準はどうなってんだ。

探査機パスワードを打ち込む瞬間、「よろしくねがいしまあああす!」と聞こえた気がした。そういえばあれも人工衛星GPS誘導によって落とす話だったか

ていうか探査機との通信に使う暗号方式って、パスワードによる共通鍵暗号方式なん?公開鍵暗号方式とか使うんでないの?そこらへん詳しくないから誰か教えて。

RX-7の頑強さとかキック力増強シューズで蹴り出されたボール威力とかはまぁ空想科学読本あたりで検証されるだろう。今も空想科学読本が残ってるかはわからないけど。

てな感じで、基本突っ込みながら楽しむ作品だと思ってるけど、100億に相当するかと言われたらちょっと微妙な感じ。

まぁ基本キャラ推しの力でどこまで伸ばせるかは興味深いところ。

2018-03-18

プログラミング歴とプログラミング能力ほとんど関係無い件について

ほとんどの人はもう既に気付いていると思うけど、あえてこの表題言及している人はあまり多くないんじゃないかと思ったので書く。炎上したら💩なのでここに書く。

結論から言うと、プログラミングを何年やったかプログラミング能力はこのぐらいと言うことは絶対にできない!

これは何もIT業界だけでなく他の分野でもそうだ。たとえば野球とか絵画かにも言えることで、ただ年数を重ねればいいってわけではない。勘違いしてほしくないのは、他の業種ではただ年数を重ねればいいといっているわけではない。

コンビニだったら始めはレジ打ちから入るだろうが、だんだん品出し、他者とうまく調整できv、何が売れるか・何が利益率を叩き出すかを把握し、接客態度は絶えず磨き……というように、能動的にスキルを身につけるなければあっという間に「経験した年数」などというものは何の武器にもならないであろう。(「やっても給料変わんない」とかそういうのは抜きにしても)

IT業界でもこれが言えるのだ。

その証

個人的経験によるサンプルしか無いが、ぼくの経験上では年数が高ければ高いほどいいと思ったことは全くない。もちろん2ヶ月の新人と5年目の人での比較はなかなか難しいが、情熱ある新人プログラマ半年で5年目を追い越すなどということはありふれた話だ。あたか大人小学生中学生さらっと数学英語能力で負けるように負ける。

残念ながらしっかりした実証などはないので、周りの環境がそうではない場合は納得できないかもしれないが、以下は明らかであろう。

経験年数とは時間であり、重要なのは時間を代入すると成長度合を求められる関数(ここではFとする)の違いである。(F: time -> ability)

Fの方が大事理由も明らかだ。timeケチをつけようとする例外を除けば誰にとっても同じであり、おもしろくもなんともない。

Fの次元が違う場合は、能力次元文字通り違う。そのため、かなり重要だ。

プログラミング歴が増えることは恥だと思いたい

プログラミング歴2年だからこんなことを知っている」と周りから評価されるというのは、要は「プログラミング2年生」だということだ。これははっきり言って侮辱である。2年プログラミングをやったから知っているんじゃなくて、2年の間で勉強したことたまたま別の箇所で出現したということだ。決して2年やったからではない。2年の間に獲得したスキルがいっぱいあるからだ。2年は重要じゃない。どれだけやったかだ。2年という期間それ自体は全く重要ではない!

プログラミング歴2年なのにそんなことまでできるのか」というのが真の評価なのだ

これはまあまあ高い評価である。「プログラミングを始めてまだ半年なのにそんなことできるのか」という評価はより容易く得られる。年数を重ねれば重ねるほどこの評価に達するのは難しくなる。したがって「プログラミング10年なのにそんなことまでできるのか」という評価ほとんど得られない。ほとんどの場合、「10年やってるからできるんだな」とか、ひどい場合10年やってるのにこんなこともできない」という評価になる。

これもある種、年数というもの全然重要じゃないとみなされている証左であろう。みんな知らず知らずのうちに周囲の人々の経験年数と能力とでおのおの相関図を作り上げて、標準偏差をなんとなく作り出して、「45歳……クソコード……チーン!こいつは偏差値37!落第!死刑!」みたいなことをやってるんだろう。

プログラミングも慣れてくると、特に新しいことを勉強しなくてもなんとなくできるようになってきはじめる。これが危険シグナルだm

謙虚でありたい

自分プログラミング歴が長いのに、HTTPSの仕組みもTCPの仕組みも詳しく知らず、JavaScriptもまともに書けず、WebAssemblyは全く知らないし、RDBのことは知らないし、もちろんRDB以外のDBちんぷんかんぷんで、デスクトップアプリは作ったことがない、サーバサイドはRailsしか知らない。Railsがどう作られているかも知らない、gitの触りぐらいしか知らない、AWSGCP全然使いこなせない、公開鍵暗号方式もよく知らないし、アルゴリズム簡単ものしかからない。デザインパターン勉強してないし、関数型言語もわからないし、C言語全然読めない、アセンブリはやろうと思ったことすらない、正規表現も複雑なものはいまいちわからないし、機械学習はわからないし、そもそも数学不安で、AndroidアプリiOSアプリもまともなものリリースしたことがなく、エディタは人が作ってくれたプラグインをただインストールするだけで、英語ほとんどできず、セキュリティに関してはザルもいいとこ」

のように自分を見直すべきである。もちろんほとんどの人はそうしているとは思う。そもそも自分プログラミング歴が長いのに」という部分はもはや要らないだろう。

あとはただ穿つだけである能力は、どれだけ、何を、どうやったかとの方と強い相関を持つ。能力とは現在状態であるのだから、強い相関を持つのは最最もである

結論

少年老い易く学成り難しである

一刻も早く「プログラミング歴」でなんとなくの判定するのをやめて、プログラミング歴1秒の人に対しても、プログラミング1000年の人に対しても、そのFを見るようにし、自分はとっとと次元を越えて昇華したいものである

結局、「いっぱいやればいっぱい成長する」という自明結論自体は変わらないんだが(高)

2017-11-28

https://anond.hatelabo.jp/20171128044314

量子コンピューター一般化したら

ビットコインは上がるの?下がるの?関係ないの?

前提

量子コンピューター一般化したら 」というと焦点がぼやけるから

現行の公開鍵暗号方式秘密鍵や、

ハッシュ関数の逆変換が簡単に求められるようになったら

という前提でいこう。

 

考え方

何か中央集権的な手段で、過去取引履歴保護してやらないかぎり

下がるというか、価値ゼロになる。

なぜならば過去取引履歴自由捏造できるようになるため。

 

ビットコインでは過去取引履歴から口座の残高を求めるので、取引履歴捏造されると

ある人はあなたの口座には100BTCがあると言い、

別の人はあなたの口座には1BTCも入っていないと言う状況になる。

そして、どちらが正しいかを判定する手段は無い。

 

しかし、過渡期に量子コンピュータでも有効ハッシュ関数などを使って

「『正しい』過去取引履歴」が中央集権的に確定させることはできる。

そうすれば前述の問題は発生しなくなる。

ブロック生成の仕様を、量子コンピュータでも解けない計算に切り替えれば、

運用も続けられる。

 

結論

中央集権的な仕組みを入れないとする原則を貫くなら、無価値になる。

しかしその原則を破って価値を保つことは可能である

実際にはビットコイン価値を保つ方を、人々は選ぶだろう。

2017-10-18

応用情報技術者試験を受けてきました

anond:20170911232449

上の日記を書いた増田です。

こんにちは

試験、受けました。

ことさら話題にするようなことでもないかもしれませんが、せっかくなので書きます

これから受ける人などの参考になれば幸いです。

プロフィール

30代。

普通科高卒

製造業

プログラミング歴は数ヶ月。

それまではExcelWordがちょっと分かるくらいだった。

言語VBAVBバッチ

一ヶ月に100行書いてるかどうかといった感じ。

製造現場身体を動かしながら、改善の種を探している。

所持資格はTOEIC700、日商簿記2級など。

基本情報は受けたことがない。

受験

動機

内製のソフトC++でできていて、これを色々弄くれるようになればあんなところやこんなところまで自動化できるなあ、でも何も知らないまま弄るのはちょっと怖いなあ…

そうだ、勉強しよう!

合格すればついでに報奨金(10万)も貰えるしね!

勉強期間、学習時間

8月半ば、受験申込期間の締め切りギリギリ試験存在を知り応募。

勉強期間は2ヶ月ほど。

平日は1日1〜2時間。土日は1日3〜5時間。まったく勉強しなかった日が10日ほど。

体感的な総学習時間100時間ほど。

学習方法

最初に、ネット評価の高かった合格教本という本を買って読んでみた。

基本情報知識もない状態だと、書いてあることがもうほんとにまったく分からず、挫折しそうになった。

方針を変えて、応用情報技術者試験ドットコム過去問道場をひたすら回した。

からない言葉ネットで調べて、これはと思う説明出会ったらOneNoteにひたすらコピペした。

最後の2週間はドットコムユーザー登録をし、理解度問題を色分けするようにした。

最後の1週間でピヨ太くんのサイト(正式名称長い)を見つけ、分からない言葉はまずこのサイト検索するようにした。

午後対策過去問を本番と同じ時間で4回分解いたくらい。

合格教本は結局ほとんど読まなかった。

午後の選択問題

受験前は、

…のどれかを選ぼうかなと考えていた。

いわゆるストラテジ、マネジメント系科目だけで固めても良かったのだけど、組込みなんかは普段生活からイメージやすいし、2時間半の長丁場ならテクノロジ系科目を間に挟んだ方がほどよく頭のリフレッシュになるかなーと思っていた。

実際の試験では、

…を選んだ。

試験当日(午前)

試験会場に時計がなかったので、時計が無い状態受験した。

机上に置けるような時計は持っていなかったし、まあ午前だけなら時計が無くても大丈夫だろうとタカをくくっていた。

問題を順当に最後まで解いて、全て順番通りにマークされてることを確認してから、手を挙げて外へ出た。

出てからスマホの電源を入れて時間確認した。

15分ほど余っていた。

試験当日(午後)

さすがに午後は時計が無いとマズイと思い、休憩中に買ってくる。

セキュリティ(必須問題)の設問1で長考してしまい、20分ほど経っても解答用紙の半分が埋まっていない状態

とりあえず他の問に移り、最後に余った時間セキュリティに戻る方針シフト

経営はぱっと見簿記知識が生かせそうだと思い選んだのだけど、「固定長期適合率」がどういう計算式なのか見当がつかない。

早々に切り上げる。

組込みの設問1でまたも長考、ほぼ解答を埋められたものの、結局40分ほど費やす

この時点で残り1時間と少ししかなく、かなり焦る。

サビマネ監査は焦りから問題文の通読ができず、設問を最初に読むようになり、結果読み返しが増えてしまった。

監査を終えたところで5分くらい余ったので、這々の体でセキュリティに戻る。

なんとか穴埋めしフィニッシュ

午前とは逆に、始終時間との戦いだった。

自己採点

午前は78.75点。

午後は厳しめで53点、甘めで66点(TAC基準)。

セキュリティ、サビマネ監査の点数がかなり流動的。

午前は問題用紙に選んだ選択肢に○する余裕があったのだけど、午後はそれがなくなって、問題解くのに必死自分が何を書いたかしっかり思い出せない。

色々と書いたけれど、そういう訳で正直受かってるかまったく分からない。

配点、部分点次第といったところ。

怖い。

感想

午前の対策簡単だ。

ただ過去問を解くだけのロボットと化せばいいだけ。

体感3割〜4割くらいは過去問の流用で問題ができあがる。

いわゆる一般常識で解ける問題も多い。

午後の対策が難しい。

午後対策でよく見られるのは「国語の読解力をつける」というアドバイスだが、読解力というのは漠然としていてレベルの向上も分かりづらい。

今の私なら、以下の順番で勉強を進めるかもしれない。

ま、受かってたらやらないんだけどね!

そもそも、「試験合格するための勉強」に終始して、最初動機なおざりなっちゃった感が否めません。

公開鍵暗号方式といえば、RSAだよね!知ってる知ってる」

…でもそれらがなんなのかはよく知らない、みたいな。

一つ確実に「分かった」と胸を張って言えることは、

からないことは、調べればいい。

分かる人に、聞けばいい。

ってことですかね。

受かってなかったとしても、もう受けないかもしれませんね。

はぁ…10万欲しいなぁ…

以上で終わりです。

最後まで読んでいただきありがとうございます

お疲れ様でした。

2017-08-03

https://anond.hatelabo.jp/20170802230319

普通に公開鍵暗号方式S/MIME使えばいいんじゃないのかな

対応メールクライアントも多いし

セキュリティに気を使ってますというポーズけが重要で、新しいことは一切覚えたくないという人が多いだろうから導入に反対されそうな気はする

2015-10-15

LINE Engineers' Blog掲載された記事を読み解こうとして力尽きた

http://developers.linecorp.com/blog/ja/?p=3591

Letter Sealing って何でしょうか。私気になります

必要範囲で、原文を引用しています。原文は先に引用元アドレスと閲覧日時を記し、引用記法によって地の文識別できるようにしています

長すぎ;読まない

ECDHAES256-CBC 使ってみた。通信相手の認証については読み取れない。

暗号通信の流れ

図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています

この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものLINEサーバーが受信したところで復号されて平文で保存され、サーバーから信者までの通信路は暗号化されていると理解できます文脈から、この流れを変えたいのであると推測できます

SSL公開鍵暗号

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っていますユーザーに対してLINEアプリ提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバ接続されたときだけLINEサーバでのみ解析できる暗号化された安全チャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全暗号化を実現できます

SSL はすでに時代遅れの代物で、 2015年現在は皆さん TLS を利用されていることでしょう。 Web ブラウザSSL 2.0SSL 3.0 を有効にしているそこのあなた、今すぐ無効しましょう。

TLS では、公開鍵暗号方式共通鍵暗号方式電子証明書暗号学的ハッシュ関数といった複数暗号技術要素を組み合わせて安全通信路を確保しています

RSA代表される公開鍵暗号方式一般的AES代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります

このため TLS では、通信路を流れるデータ暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージ暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータ暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータ暗号化すると、第三者メッセージを見ることができなくなります

これは上で説明したとおり SSLTLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージ暗号化に用いられている暗号スイートアルゴリズムの種類、鍵の長さ、ブロック暗号場合暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全である判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

既存RSA方式秘密データの共有に使う安全方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSLTLS でも実装されており近年では広く使われていますSSL より軽いと主張し、 SSLTLS公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明実装に比べると、大きな改善です。

なお SSLTLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています

まり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。

共通鍵暗号暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ここでメッセージ暗号化に使用している暗号アルゴリズムAES-CBC-256という方式で、現在一般に使われている暗号アルゴリズムの中で最も強度が高いと評価されています

メッセージ認証と組み合わせない CBCビット反転攻撃に弱いことが知られていますGCM ではデータ暗号化と認証を同時に行うためビット反転攻撃に耐性がありますAESGCM で利用するのは、 最近TLS実装では広く用いられており、 Googletwitter も利用しています

CBCCBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります

解決されない鍵管理問題

図6 のとおり、 ECDH共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここから安易パターン想像ですが、通信相手の公開鍵情報LINE ユーザー情報の一部として LINE サーバー管理されており、必要に応じて安全通信路を用いて LINE サーバーから取得するようなものではないかと思います公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバークライアントの両方が認証されていて、現在の水準から見て妥当レベル暗号スイートが用いられていることを願うばかりです。

公開鍵秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービス要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数必要します。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります

2015年10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全通信路を確立する目的で ECDH 鍵を用いる場合LINE サーバーが用いる秘密鍵漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージ暗号化する場合ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH漏洩リスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信たか (または、していないか) という情報も守りたくなります。宛先を LINE サーバー確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます

2015-02-02

不正アクセスされた

まえがき

恥ずかしすぎてハンドルネームでやってる自分ブログにすら書けず、かと言ってどこかに吐き出したくはあったのでここに書いておく。

見た人は存分に笑い飛ばして欲しい。


不正アクセスされたことについて

先週、趣味で立てたVPSサーバー(CentOS 6.5)のCPU使用率が、気付くまでの9時間ずっと100%になっていた。

作動中のプロセスを見ると、2つのperlプロセスがその原因であることが分かった。

そのプロセスユーザー「postgres」によって実行されたプロセスだった。

postgresは、PostgreSQLインストールすると勝手に作られるユーザーだ。

先日自分PostgreSQL9.4をインストールしたので、このユーザー存在自体問題無い。

その時このpostgresに、「postgres」という簡素パスワードを、passwdコマンドで設定した。

特に理由はない。その時理由を聞かれていたとしたら、

「まぁ無いよりはマシなんじゃね?サーバー内でしか使わないユーザーからハッキング心配とかないしどうでも良いけど〜。」

と言ってたと思う。

その程度の認識だった。

これにより下記コマンドでpostgresとしてサーバーに入れてしまう状態になっていた。

$ ssh postgres@my.server.address.com

実行するとパスワードを求められるが、もちろんそれは前述のパスワード「postgres」だ。

それまではパスワードを設定していなかったので逆に助かっていた。

パスワードが設定されていないユーザーにはsshでは入れないからだ。

「もちろん」というが、それまではユーザーパスワードsshで入る時のパスワードになることを知らなかった。

そしてそれだけで接続可能になる可能性があることを知らなかった。

sshサーバーの設定はひと通り、自分が使っているVPSサービスがやってくれており、多分大丈夫だろうとそのまま使っていたからだ。

それでハッキングされ、そいつに謎のperlスクリプトを走らされていた。

具体的なスクリプトファイルや.bash_historyは消されていたようで、どんなものを走らせられていたのかよく分からない。

踏み台としてどこかにDoS攻撃していたんだろうか。

ハッキングであることを知ったのは、/var/log/secure を見たからだが、そもそもこの自体に陥るまで /var/log/secure の存在とその役割を知らなかった。

「ポスグレ(PostgreSQL)がなんかバグったわ〜でも原因がよく分からんわ〜ヒマだしハッキングの可能性も考えとくか〜でも絶対ポスグレがバグったんだわ〜」

でググって初めて知ったぐらいだ。

それで見たらパスワード設定してから9日間でそれぞれ別の端末23から不正アクセスを受けていたことが分かった。

VPSサービスコントロールパネルを見ると、その内の1件が侵入した3分後にCPU100%現象が始まったので、十中八九そいつ仕業だろう。

それ以外の連中が何をやったのかは分からない。

からないのでOSを再インストールした。DoS攻撃だったらあとで攻撃先に訴えられるかもしれないので、全データを家のパソコンDLする事で証拠(?)を保存してから

不正アクセスに気付いてからやったこと
1. パスワードによる認証原則不可にした

/etc/ssh/sshd_config には、sshサーバーの設定が書かれている。

その中のPasswordAuthenticationをnoにし、公開鍵暗号方式による認証のみ受け付けるようにした。

2. ユーザー「postgres」のパスワードを削除した


3. http://www.websec-room.com/2014/02/09/1822 を全て適用した




他になんかやることとかある?おしえてぴょーん

2014-04-22

http://anond.hatelabo.jp/20140422184326

もともとはUNIXに使われていたCrypt,DESブロック長が8バイトだったのと

当時はそんなにディスク容量もなかったので便宜上バスワードは8バイトまで。(8バイトで切られる)

という歴史的仕様だった時の名残。今はSHA256かSHA512だから64文字ぐらいまでなら何の問題もない。

 

もっとも、当のUNIX世界ではとっくの昔に公開鍵暗号方式ワンタイムパスワードの組み合わせになってるので

直接パスワードを送信したりはしない。

 

30年か40年ぐらい昔の仕様が今でも残っているのが8文字なんじゃないかなぁ。いくらなんでも、時代に追いついてなさすぎだよね。

ちなみにDESなんてもう使わない。3DESですら脆弱MD5,SHA-1ですら脆弱と呼ばれる時代っすからね。

ただ銀行系の人は、そんな知識もないでしょ(技術屋じゃないからね)。下手すりゃ証明書ベリサインだよね。とかまだ言ってるとおもう。

彼らの知識を更新するのは、とんでもない重労働からSEは誰もやらないと思う。そんな事しなくても古い技術で金がもらえるのにわざわざ危険を犯してまで進言する奴はもう銀行業界にはいないだろ。

2011-06-24

公開鍵暗号方式みたいなファイル暗号ツールとか無いかなあ

公開されたネット上のやりとりで、メールメッセンジャーを使わず任意の相手だけにファイルを渡したい場合がちょくちょくある。

こんな感じでやりとり出来るといいんだけどな。

  1. 渡したい相手、自分の公開鍵を公開する。
  2. 俺、その公開鍵で渡したいファイル暗号化し、どこかにアップロードし、渡したい相手にそのアドレスを知らせる。
  3. 渡したい相手、ファイルダウンロードして秘密鍵で復号化する。
    秘密鍵を知らない第三者がファイルを入手しても復号化不可能。

あと、最近流行GPUを駆使したらZIPファイルパスワード解析速度ってすんげー上がりそうだよね。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん