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

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

2019-04-24

公開鍵暗号マウントを取るくせに「回復逮捕」は知らない人達

そして他人馬鹿と呼びながら陰謀論を吹聴する。

醜いってレベルじゃないな。

典型的な「自分が詳しい分野は常識だと思い込み自分が詳しくない分野は常識であっても知らなくて当然の知識だと思い込み、そして前者の情報には莫大な価値があり、後者情報は知らなくても人生で何も困らないからどうでもいい、なんてことを平気で言い張るタイプ非常識極まる自分が賢いと思っているけど実際は単に自分がソレで飯食ってる分野の経験を積んだだけでソレ以外の事については何も知らないだけのちょっとオツムが残念な技術屋(?)さん」じゃないですかー。

救えないよー。

全くもって救えないよー。

算数問題が解けないのにポケモン沢山知ってるから俺はカーチャンより頭いーぞと言い張る小学生と同じレベルだよー。

その事に自覚がないのが駄目だよー。

2019-04-03

セキュリティクラスタって性格悪いよなあ

徳丸さんとか高木さんとか、いつまでも武雄市長に粘着して息吸って吐いてるだけで文句わめいてるし。

なーにがこんにちわ~~だよクソが

2018-08-07

anond:20180807220349

そなたは素数自然界の法則ではないと申すのか?

素数 - Wikipedia

長い間、数論、その中でもとりわけ素数に関する研究は、その分野以外での応用の全くない純粋数学の見本と見なされていた。

特にイギリスの数論研究であるハーディは、自身研究軍事的に何の重要性も持たないことを誇っていた。

しかし、この見方1970年代には覆されてしまった。素数公開鍵暗号アルゴリズム使用できると広く知られるようになったためである

現在では素数ハッシュテーブル擬似乱数生成にも用いられ、工学的応用上重要度の高いものとなっている。


なんで数学自然界の法則に含んでくれないの(´;ω;`)ウッ

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

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 サーバー確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます

2013-05-30

まねして本の紹介 その4(とりあえずラスト

http://anond.hatelabo.jp/20130530181122 からの続き。本の紹介。とりあえずこれで一区切り。書くのは時間がかかるけれど、得るものもあった。

このエントリでは以下の二冊を紹介します。

加えて、今までに本を紹介したURLを列挙しておきます

あなたに似た人

チャーリーとチョコレート工場」で知られるロアルド・ダールさんの短編集。翻訳田村隆一さん。

http://anond.hatelabo.jp/20130530181122 で紹介した「心の鏡」と同じく短編集なので、印象に残ったものだけ。

「味」「南から来た男」「毒」「お願い」が記憶に残っている。全体に人間の気味の悪い部分を誇張して書いた短編集なので、予めそう知った上で読んでも良いかな。

暗号解読

著者はサイモン・シンさん。翻訳青木薫さん。この著者の紹介は三作品目。「暗号」をテーマにしたノンフィクションだ。ただ、暗号と言ってもいくつか種類があったり、本来は暗号ではなかったもの暗号のようになってしまったものも取り上げられている。

暗号は仕組みが難しい。理解するのに時間がかかる。最初のほうは簡単だけれど、だんだんと複雑・巧妙になっていく。というのも、情報秘密にしたままやり取りするのが目的で、いったん解かれてしまうと自分の生存や国家の存亡にかかわることになるから暗号解読者は暗号を解読しようとあらゆる手段を講じるし、そしてそれを防ぐために自然と複雑なものになっていく。

翻訳者青木薫さんは、あとがきドイツ軍第二次世界大戦の時に使用した暗号機械エニグマ」の仕組みを説明した箇所のわかりやすさを絶賛しておられた。自分には、本質的な複雑さがあるので、深く理解することをあきめてしまった。(この本は手元にあるので、読もうと思えばいつでも読めるというのもあるんだけれど)

で、そんな状態でもこの本は楽しめるのだ。エニグマは単にこの本の中でいくつも紹介される暗号の一つにすぎない。

ほかにも、公開鍵暗号はもちろん(そしてそれを事前に発見していた英国人のトリオ)、第二次世界大戦米軍採用した「ナバホ・コードトーカー」の活躍古代文明の文字を解析する話、財宝が埋まっていると噂されるビール暗号、などなど――。いくつものトピックがある。

一番印象に残っているのは英国人のあの人だ。先に発表された三人が訪れたときの受け答えが格好良いね。まさにイギリス紳士といった受け答え。もう一人挙げるとすれば、「神は愚か者に報いたまう」の節のヘルマンさん。このガッツにはおそれいった。

あれば読みたいなあと思っている本

最後に、こんな本があったら読んでみたいなあ、というものを2つ記して終わりにします。良い本を知っている人がいれば教えてほしいです。

英語ではたくさんあるみたいだけれど、日本語でこなれた感じのを知る人がいたらぜひ。

たぶん無い。もしそういうものがあればということで。

2013-01-11

http://anond.hatelabo.jp/20130111014156

わかるよ。しんどいよね。

自分の周囲にいる人たちが重要視するような物事に意義を感じない

でも、そんな自分であることを知られて軽蔑されるのは怖い

かといって、一人ぼっちでいるのは寂しい

人付き合いって面倒くさい。

じゃあ誰にも会わなきゃいいって?そんなの寂しいじゃん。

から好かれるように、軽蔑されないように自分を磨けって?やだよ面倒くさい。

自分でもわがままだって分かってるよ。

人の話は聞きたいのに、人から自分の話を聞かれるのはイヤなんだもん。

一方的に話しまくる奴?そういう奴の話ってたいてい面白くないじゃん。

話を聞きたいって言ったけど、ただし話が面白いやつ限定ね。俺基準で。

...っていう自分自身を客観的に見たら、劣等感を感じちゃうよね。

つらいよね。苦しいよね。もっと楽になれないものかな。

何か良いアイデアがないかブコメから探してみよう。

b:id:bloominfeeling

すべての話を楽しむ必要はないと思う。楽しい話も興味のない話もある。自分楽しい話をできる人たちを大切にするのがいいのでは。あと最初にずぎゅーん来なくても好きになることはあると思う。

話してて楽しい人はもちろん大切にしてるよ。でも、そもそも友達が少ない。

気の合う仲間って、どうやったら増えるんだろう。面倒くさいのはイヤだなあ。

b:id:dagama

生への執着を捨てて刹那的に生きてみるといいと思う

別に死にたいわけじゃないです。

b:id:vid

擬態するのを止めれば楽になるよ! ぼっちが平気ならそっちの方がよっぽどか楽だよ!

ぼっちはイヤです。軽蔑されるのはもっとイヤです。

b:id:gdno

もっと浮いてる人と会えるとこに行ってみるとか。ベンチャー社長とか。

そういう人って、自分がやりたいことを突き詰めてる人でしょ。余計に軽蔑されそう。

b:id:ysync

趣味女性への興味がなくとも、暇で暇で仕方ないというわけでもなさそうだし、別にいいんじゃね?

うん。自分では別にいいと思うんだけど、やっぱり人の目も気になる。

b:id:era1978

自分は他人に興味無いけど、他人には自分に興味持ってほしいんだよね。わかるよ

あー、そうなのかも。

b:id:u_eichi

そのうちに、そういう悩みもどうでもよくなるよ。放っといても暮らしを続けていれば自分の御し方も身についてくる。歳をとることは、そういう意味ではすばらしい。そのときまでになにか悦びが見つかるといいね

うーん。時間が解決するのかもしれないけど、いま苦しいのは何とかならないかな。

b:id:nochiu74

情報工学オタクとだけ深く付き合うのはどうでしょう大学でしたらコンピュータサークルとかあるでしょうし。もしくはネットベンチャーみたいな所でバイトとか。興味ない話しをふられたら、ノッテるフリだけしとく。

これは元増田環境次第だね。

b:id:skgctom

本当は「どうでもいい」んじゃなくて「僕の人生に干渉するのはやめてくれ」と言いたいけど、言えずに疲れてしまっただけじゃないか。法と倫理に触れなきゃどんな生き方も自由だよ。正解の人生なんかない。

うそう。

b:id:kazsoga

泣けば良いんじゃないかなあと思いました。また、一度発散すると良い気がします。お酒の力を借りたって良いかなと。

「いやだから、泣かせてくれる相手が居ないんだって」と思うかもしれないけど、誰も見てないところで思いっきり泣くだけでも、けっこうスッキリするもんだよ。傍目にはみじめに見えるかもしれないけど、誰も見てないんだからいいんだよ。

b:id:moronbee

"客観視点に基づくアドバイス"←すべて「その人から見た主観」なので気にすることはない。興味がないことはしない方がいいですよ。

その通り。

b:id:bayassie

よくわかる。自分も似た気持ちだった/人に理解されるのを放棄して、人とは通じ合える話だけで通じ合えばいい(自分の好きなことは自分が好きであればそれでいい)と割りきって考えると心は少し楽になる、と思う

ブコメの中では一番良さそうなアドバイスかな。

他に、俺からアドバイスとしては

やりたいコトだけやればいいし、話したいコトだけ話せばいい

もしそれだけじゃ満足できなくて、誰かから認められたいなら、自分で一番自信のある分野で自分よりレベルの低い人が集まる場に参加してみよう

そういう場を探すのが面倒だったり参加するのが怖かったりしても、いずれ就職とか何かのキッカケで、新しい集団に参加するタイミングがあるはず

そんなに我慢できない。もっと安全赤の他人に思いの丈をぶちまけて、その上でありのまま自分を認めて欲しい。

もしそこまで思いつめてるなら、俺が話を聞くよ。

元増田に限らず、このエントリ最後まで読んでくれた人なら誰でも歓迎する。

このエントリトラックバックで意思表明してくれたら、エントリを使って連絡方法を交換しよう。

情報工学勉強している元増田なら、公開鍵暗号原理は理解できると思う。

2010-01-03

http://anond.hatelabo.jp/20100103182755

金融系は例外だね。もともと4桁の数字だけで成り立っている暗証番号に基づくシステムだし、『ネットよりも以前』からあるシステムだからな。

ネット以後のシステムや、ネットを中心としたサービスとは比べられない。

ただし、最近は、公開鍵暗号を使ったワンタイムパスワードに移行しているところが多いよ。あとは暗号表。

ただ、銀行システムから、Webシステム転職してそのノリでパスワードを平文という重役は老害

なにより、銀行システムサーバーWebシステムサーバー物理的な設置場所を含める硬さの違いに気がつけと。

大手町にある、どんだけ厳重なんだ?っていうサーバー管理システムと、そこいらの、隣のラックこじ開けようと思えばこじ開けられるんじゃね?っていう普通DC物理的に差があるって知らないからできる。

サーバーの設置場所くらい視察しろと

あと、プルートフォースアタックができないから、銀行系は。パスワードも2つだし。

監視カメラで客を見張るならWeb系でも平文でいいのかも。という話もある。銀行パスワード以外のセキュリティがカネがかかってる。という話。

ATMで金下ろすときにはカメラで撮影されてるしな、隠しカメラも沢山あるしな。

2007-01-19

Re:Re:?

http://anond.hatelabo.jp/20070119214005

http://e-words.jp/w/E585ACE9968BE98DB5E69A97E58FB7.html

ん?こういう感じで、いいんじゃないの?

面倒だからここに追記。

http://e-words.jp/w/E585ACE9968BE98DB5E69A97E58FB7.html

公開鍵暗号(Public Key Cryptosystem)

片方は他人に広く公開するため公開鍵と呼ばれ、もう片方は本人だけがわかるように厳重に管理されるため秘密鍵と呼ばれる。秘密鍵暗号化されたデータは対応する公開鍵でしか復号できず、公開鍵で暗号化されたデータは対応する秘密鍵でしか復号できない。

これはe-wordsが間違ってる。

一般に公開鍵暗号系の秘密鍵暗号化することは出来ない。実装されているようなものでは、ElGamal暗号やCramer-Shoup暗号なんかがそう。

電子署名のこと言ってない?

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