「ハッシュ値」を含む日記 RSS

はてなキーワード: ハッシュ値とは

2021-07-19

おお、ジーザス

ソフト音源ファイルがぶっ壊れた!

これじゃ演奏できない!!

そう思って。

問題ファイルメーカーサイトからダウンロードしてきた。

その容量、10G。

デカイのを落とすと回線絞られちゃうんだよな~なんて思いながら長い時間かけてダウンロードしたんだけど、試しにぶっ壊れた方のファイルダウンロードしたファイルとでハッシュ値比較したら一致しやがった。

壊れてなかったんかーい!!

何があかんかったんや。アクティベーションちゃんと済ませたぞ。うーむ。

2021-07-18

anond:20210718103715

たとえば、RSA暗号理論計算機の有限時間内の演算が難しいという特性を使っているわけじゃん。つまり暗号化されたものは確実に復号できるという特性を持ち、かつ有限時間以内に割り切れる可能性がほぼ無い」という特性を持つことは数学的にも正しく、計算機科学でも成り立つ事実じゃん。SHA-1ハッシュ暗号として脆弱なのは、異なるファイルで同じハッシュ値を作れることが PoC されたことであって、数学的に脆弱性が解読されたわけじゃないだろ?もし、数学的にこの脆弱性がわかっていたら、もっと早い段階でハッシュの衝突が起きていたと思うのだが、違うのかい?一応は SHA-1 で衝突が起こることは数学的に予期されていたが、これだけハッシュ破りに時間がかかったのだから有用性はあったとはおもうけどね。

2021-05-18

anond:20210517201151

パスワードを生年月日(8桁)にしておくぐらいあってもよかったかもね

摂取券番号と生年月日のハッシュ値検証したり

2021-03-30

anond:20210329154726

書き込む内容のハッシュ値を算出して、同一のユーザーIDかつ、一定間内に同じハッシュ値書き込みがあったらガードをかける、かな。

2021-03-25

anond:20210325111051

そういう類の作為を防ぐのがまさにトラストレス系の得意とする所である気がする。

合ってると思うよ。

運営の信用を担保としなくても、技術的にガチャ排出パターン恣意的操作をされていないことを保証できる。

基本アイディアとしては、イベント前に「ガチャ排出パターンハッシュ値」を公開して、イベント後に「実際に使われたガチャ排出パターン」を公開して、ユーザ側でハッシュが一致するか検証できるようにすればいい。

anond:20210325102715

「悪いことをしようしてもできない仕組み」で飯が食えるかという話。

オンライン麻雀ゲームでは実現されている、不正な積み込みがないことを後でハッシュ値から確認できる仕組みが

ソシャゲガチャではどこにも実装されていないように、邪悪でも儲かるほうが勝つのである

2021-03-20

anond:20210320145815

ツイートをNFTで売買するとかあったけどどういう仕組みなん?

他人のもんでもいけるというし、URLとかバイナリファイルハッシュ値かに早いもんがちでブロックチェーン上のアドレスみたいなのを紐付ける感じなん?

2021-02-25

anond:20210225024709

こないだ増田で、マイナンバー本体ICって教えてもらったよ

表面の番号は飾りなんだって

その増田は、今時みんなICリーダーたるスマホを持ってるんだから番号なんかいらなかったんじゃないかって言ってた

 

ハッシュハッシュ値あたりで増田検索したらツリーが出てくるよ。

2021-02-24

anond:20210224051025

学籍番号になっているということはシステム共有ではなく

此処から先はおなじ学生場所 他人のおうちってわかるだろ?

他人のうちからなにかを、もってきたら、許可がなければ窃盗ってわかりやすいだろ?

そっちのほうが犯罪を防げるだろ

公共物ってまちがえるようなハッシュ値とかだと、犯罪助長しているといわれちゃう

 

それにハッシュ値だと お友達のを見るつもりで、他人のを見てしまったとか、事故が起きやす

みてもいい、みてはだめ、それをはっきりと本人が自覚できるようにする それも犯罪防止策 ハッシュ値などよりも、そっちのほうが事故を減らして犯罪を未然に防止できる

/temp そりゃみるだろ?こんなディレクトリ

/home/u11112222 見ちゃだめだろうなって わかりやすいだろ

2021-02-19

名前ハッシュ化して匿名で生きたい

anond:20210219101113

名前は生まれた時にランダムもの付与されてさ、ICとして体内に埋め込んで、通名はそれをハッシュ化したものを使いたい。

場所ごとに名前を使い分けたい。

小学校で使う名前中学校で使う名前書道教室で使う名前会社で使う名前、著書で使う名前……を分けたい。

役所管理する時の個人番号も、名前から生成した数字にしてほしい。で、何か漏洩とかのトラブル?があったときは、届け出を出して新しいものに変えてもらうの。

犯罪がしやすくなるとか、そういう問題が考えられるけど、それはITの力で解決できるんじゃないかな。

ただ名前コロコロ変わると本人としても混乱しそうだから、書面上の通名ハッシュ値を使うとして、呼び名としての通名自由に名乗りたい。外国人サインとか好きな記号で済ませるじゃん。ああ言うふうに自分で決めたりしたい。ちょうど「名前」と「ID」みたいな関係かな。書面上の識別子は@masumasu123で、普段呼び名は「ますたろー」みたいなさ。

そもそも識別子と通称が同じってのがガバガバすぎるよね。分けて欲しい。未来人が戸籍と氏名みたいな化石制度使って生きてたら絶望ちゃうよ。

 

はやく名前ハッシュ化する時代が来て欲しい。正直さっさと死にたいけど、そんな時代が来ると思えばワクワクして生きたくなってくる。

一生増田太郎として生き続けるのって怖くないか?俺は怖い。すごく怖い。耐えられない。

はてなー諸君だって自分名前はてなID紐付けられたら死にたくなるでしょ。

2021-02-18

anond:20210218172517

マイナンバーカードICはそう言う仕事してるよ。

ICカードの中には誰も取り出すことのできないメインのカギが入ってる。カードリーダーを使ってICに問い合わせると、誰も取り出せないメインのカギからICカード自身計算し、毎回違ったハッシュ値を返す仕組みになってる。

で、そのハッシュ値は別のカギを使うと、確かにそのICカードから作られたと言う事が保障できると言う仕組みがあって、認証に使うことができるというわけ。

マイナンバー数字は飾りです。本体マイナンバーカードICの中にある。マイナンバーICカードが読み取れない場合に使う為の番号でしかないので、これだけスマホという名のICカードリーダーが普及した今、もう廃止を目指してしまってよいと思う。

偉い人にはそれが分からんのです

2021-01-23

クッキーセッションを使うとサーバからセッション無効化できない?

https://oauth.jp/blog/2013/09/26/rails-session-cookie/

結論を書くと、cookieセッションでもサーバから無効化はできる。

cookieの中身はサーバ暗号化していて、クライアントからは復号ができないものとする。

こういう前提であれば、サーバからセッションに「パスワードハッシュ値を種としたハッシュ値」をセッションに埋め込んでおく。リクエストを受け取るたびに、セッション内のハッシュ値ログインユーザに対して検証をすれば、パスワード変更以前のセッションなのかは判定ができる。

もし、検証に失敗すればセッションを破棄すればOK

1ユーザパスワードを変更したら全部のセッション無効になるので、セッションを1つずつ無効にすることはできない。この制約をクリアできるなら、サーバ暗号キー漏れない限りはcookieセッションへのリスクってほとんどないと思うんだよね。

2020-12-21

乱数操作されていると疑われることが多いオンライン麻雀ゲームでは、乱数が正しいことを証明するために配山生成・配山のハッシュ値を公開する仕組みが存在する。

https://tenhou.net/stat/rand/

このように技術的に可能であり実装例も存在するにも関わらず、乱数操作されていると疑われることが多いガチャには乱数が正しいことを証明するための仕組みが存在しない。

 

有名無実ガチャガイドライン策定する費用があれば、ゲームサーバに組み込んで使える正当性証明可能乱数生成ライブラリでも作ってもよさそうに思うが誰もそれをやらないのは、ガチャの結果が操作されているという(消極的な)証拠だと思う。

2020-12-04

anond:20201204012300

クラスに関しては自分が老人だから異論はあるけど、

とりあえず動くソースコードでそれなりの規模のが欲しければGitHubからcloneしてくればいいんだよなあ。

と言っても、元増田が「gitって何?」のレベルだとそこで話が折れてしまい、

gitとは?バージョン管理とは?ハッシュ値とは?みたいになってしまうので説明する側も辛い。

自分説明される側でも説明する側でも辛いのは、それだけ専門性が高い分野ではあるのだろうけど。

自分だって自分の専門外のことをそれ専門の人にまくし立てられて説明されるの辛いw

ソフトウェア命名規則天邪鬼でなければ、スタート地点はmain.cppみたいに類推もできるはず。

その後はデバッグ情報付きでビルドして、

デバッガでメインルーチンからブレークポイント打つなりしてポチポチ動作させたり変数の中身の変化を確認していく。

あと、ソースコードコメントも参考になる。

色々なクラスとかソースコードを眺めて全体像を把握し、そこからコアとなる機能自分が知りたい箇所を目指す。

ソースコードがある、デバッグ情報があるなら、当たり前だが変数名や関数名があるので類推やすい。

Javaとかで難読化してると、逆コンパイルできても変数名や関数名は分からなくされていて読み辛かったりする。

いや、だから難読化なんだけどwでも、.classファイルしかなくてもそれで中の肝心のアルゴリズムは読めてしまったりする)

自分には大した技術はないと自分でも思ってるけど、普段やってることをまったく知らない人に説明するのは難しいだろうね。

というか、できる人やプロだって新しいビルド方法なんて分からない。

C++ならcmakeやpremakeは分かるけど、ninjaってなんじゃ?みたいなw

そこで新しい道具に手を出して躓くことも多々あるし、

他人他人自分の知らない道具、好きでない道具を使ってたりもするわけで、ビルドするために嫌々最低限即席で学んだりする。

そういう点でフロントエンドとかJavaScript界隈に流石についていけない、歳だなあと思ったり。

2020-10-17

anond:20201016210005

問題意識共感するけど使い方が分かりづらすぎる。投票するのにURL手入力するとは思わなくて誤操作した。でも作ったのは(素人からだけど)すごいと思う。

改変コピペ匿名性のため?)に説明を足すと、これは検索結果を投票数順で表示するサービス。ただし投票計算時間必要から大量のスパムは難しくなる(と期待している)。にぎやかしのためかGoogle検索結果も下部に表示される。

Salonaへの投稿は「はてなブックマーク」ぐらいしか確認できなかった。うまくいくとは思えないけど、作った人と話はしてみたい。

追記

投票計算時間必要

厳密には、有効投票にするのに計算時間必要

(追々記)

投票数順じゃなくて(記事ID+nonce)のハッシュ値の小さい順だった。有効票の強さ順。

anond:20201017081722

からだけど

投票費用がかかる」というのは、多分管理者投票料を取るということじゃなくて、投票計算コストがかかるということを言っているんだと思う

文書IDとノンスの連結からSHA-256でハッシュを生成し、既存ハッシュよりも小さければノンスが更新されていく

本文の上の説明から推測するに、投票が成立するためには既存ハッシュ値よりも小さいハッシュ値を生成するノンス(=任意の値)を計算する必要があるということ。

ハッシュ値というのは実際に計算してみるまで結果が予測しにくいので、条件を満たすノンスを求めるためには当てずっぽうでたくさん計算するしかない。

まり計算コストがかかる。

これによって、スパム行為は割に合わなくなり、計算コストに値するだけの質のいい投稿にだけ投票が集まる、というのを期待しているんだと思われる。

(個人的には全くうまくいきそうにないと思うけれど)

本文でも触れられているけど、Bitcoinでも使われているPoWの仕組みに近い。

(PoWのものかもしれん わからん)

2020-10-16

Googleを超える検索エンジンを作ったので使ってみてほしい

表題の通り、検索エンジンWebアプリ)を作ったので、使ってみて感想を聞かせてほしい、というのが投稿目的だ。

ただ、せっかく増田投稿するのだから制作物の宣伝に終始するのではなく、開発していて考えたことや制作背景を書き添えたいと思う。ここにはエンジニアデザイナー、また技術職でなくてもWebサービスに携わる人、インターネットを使って遊ぶことが好きな人が多いはず。そんな人たちの向けの四方山話として、思考一助となれば幸いだ。

検索エンジンについて

SalonaというGoogleを超える検索エンジンを作った。

https://salona.org

機能を一覧してもらうと分かる通り、Hashcashによって支えられている。後述する課題認識があってもやもやしていたところに、あるキッカケでHashcashを思いつき、それを考えているうちに上記機能実装が思い浮かんだ。

Hashcash.org

http://www.hashcash.org/

(けっこういろいろ応用されていて、ビットコインで使われているだけでも素晴らしい。)

今後追加しようとしている機能

他にこんな機能があったらもっと良さそう、というアイデアがあれば教えてほしい。

開発していて考えたこ

こんな検索エンジンをつくるのだから当然だが、わたしSEOが大嫌いだ。いま、この検索エンジンには毎日何の投稿もされない。DBウォッチしていて、まれ投稿があるとその文書を読み、ノンスの有無について調べ、ハッシュ値を見る。ローンチして4ヶ月が過ぎ、数十件の投稿がされているが、全ての投稿をきちんと読み、そこで語られる内容やハッシュの値について調べている。これがたまらなくつまらなくて、気づくと一月が終わっている。

“一月が終わっている”はさすがに比喩で、サービスデザインを作ったり追加機能設計を考えたりユーザー増加施策を講じたりとしているが、集まってこない投稿を待っていると泣けてくるし、その状況をなんとか好転させるためにと機能改善・追加機能アイデア自然と出てくる。

こういった熱中・没頭状態は、少女時代MVや、自社サービスをやっていたベンチャー企業を横目に昼夜開発に勤しんでいた日々にもあった。好きな分野でものづくりをしていると陥る状態で、経験者も多いと思う。

長いことオープンソース界隈には「普遍的ソフトウェアを作ってスターをもらって社会貢献!」みたいな夢があって、ここ何年かはそれ自体エンジニアリングやデザインを学ぶとき目的と化している人の割合も増えてきた。興味のない分野でも攻略していくこと自体が得意で、淡々技術を学べる人は凄いと思われるが、もしそれが苦手だと感じた人は、諦める前に「好きなもの、作りたいもの」を見つけることをやってみてほしいと思う。

プログラミングスクールに通うにしても、作りたいものがあるとないとでは大きく違う。もちろん、どうしたら何が作れるのかという知識がなければイメージもわかないかもしれないが、その場合は何かを解決したいとか便利にしたいという思いを持っているだけでもいい。特にこれから時代は具体的な技術習得よりもそういった見聞を広めることが、何より開発を楽しいと思える素地になると思われる。

開発背景(このプロダクトをつくった理由

わたしGoogleを利用しており、本当に膨大な情報を探すことができるようになったが、その反面、SEOスパムが少なかった時代と比べると、Google検索結果に対して深い信頼を抱くことがなくなってしまったなあと感じるようになっていた。検索で出てくるページが、宣伝という存在の域を出ず、自分の役に立ってくれない。検索をしているが、虚構を消費しているだけのような気がして、真実自分の間の関係希薄になりつつある気がしている。これはロボット型検索エンジン限界によるものなのか、Googleの加齢による革新性の低下なのか判断がつかないが、前者が理由仮定して作ってみたのが今作だ。

検索で出てきた結果について、自分投票のノンスを計算する費用を掛けること。投稿自身投票でアップボートされていく様子は、平成時代ビットコインの上昇を眺めていたときを思い出す。Googleを「たくさんのゴミ出会空間」とするならば、Salonaは「出会った情報の中から気に入った情報を連れてきて、褒めて伸ばす空間」と位置付けることができる。この二つの営みは最初共存し、SalonaがシームレスGoogleに置き換わっていくことで人間情報関係を良好にしていくはずだと考えている。

最後

法人主体がないとプレスリリースに制約が発生することを知らなかった(社会で使われているようなプレスリリースサービスを利用しようとしたら、まともな人格がないと無理だった)。仕方なく幾つかのメディアに直接プレスリリースメールで送ってみたけれど、当然のごとく梨のつぶてだ。つまり現状は利用者が誰もおらず、その状況を打破したくて増田投稿してみたという次第だ。この文章SEO嫌いの人たちに届くことを願っている。

anond:20201016172103

7, 投稿者ユーザIDハッシュ化。

利用者はそのハッシュ値を指定して画面から自分にだけ見えないように消すことができる。

1年以上増田を利用している利用者11から消されたユーザは、BANされる。

2020-09-21

anond:20200921124203

マイナンバー個人に関するユニークハッシュ値

マイナンバーカードは偽造困難な暗号鍵でリモートでセキュアな本人確認手段

たったこれだけなのよね

シンプル有益だと思うんだが、あんまり要点を理解してる人がいないのが辛い

NHK日曜討論見た限りは平井大臣はそれなりに理解できてた印象

2020-08-31

anond:20200830172134

登録番号って感染者かどうかに関わらず貰えるもんなん?それならなりすまし(陽性者騙り?)も可能だし問題だと思うが。

ただ単に「別人が貰った感染者の登録番号を総当りで入力出来る可能性がある」ってだけなら国内感染者が7万人弱で人口の1%未満なんだから、3回の入力ミスでアプリが終了するなら結構な手間がかかって「容易」とは言い難いんじゃあないか。そしてその登録番号にはハッシュ値が含まれてないんか?

ツール使用でどうにかできるかもしれんが、そこまでして悪用するやつを運用の想定に入れるかどうかって事になるわな。もちろん悪用出来ないに越したことはないんだけど。

anond:20200830172134

登録番号って感染者かどうかに関わらず貰えるもんなん?それならなりすまし(陽性者騙り?)も可能だし問題だと思うが。

ただ単に「別人が貰った感染者の登録番号を総当りで入力出来る可能性がある」ってだけなら国内感染者が7万人弱で人口の1%未満なんだから、3回の入力ミスでアプリが終了するなら結構な手間がかかって「容易」とは言い難いんじゃあないか。そしてその登録番号にはハッシュ値が含まれてないんか?

ツール使用でどうにかできるかもしれんが、そこまでして悪用するやつを運用の想定に入れるかどうかって事になるわな。もちろん悪用出来ないに越したことはないんだけど。

2020-08-30

新型コロナウイルス接触確認アプリ(COCOA)で攻撃できる問題

はじめに

#COCOAボランティアデバッグ に尽力されている皆様に深い敬意を表します。

併せて、 OSS コミュニティへの悪影響を残している関係行政機関・各社担当者を強く軽蔑します。

project dead? · Issue #773 · Covid-19Radar/Covid19Radar · GitHub

COCOA が抱えるアプリケーション設計上の問題点

攻撃者が COVID-19 感染者になりすまして「陽性情報登録」を比較的容易に行える設計であること
接触記録の条件である「概ね1メートル以内で15分以上」の距離条件を大きく逸脱している可能性があること

(注) これはアプリケーション固有の問題ではない( Apple-Google API問題)が、前項の問題点と併せることで脅威となりうるので便宜的に示しておきます

COCOA が抱える運用上の問題点

※一部で報じられている「保健所から COCOA への陽性情報登録必要な処理番号が即日発行されない」などの問題もありますが、ここでは省略しま

上記で挙げた問題点悪用することで行えること

※以下はあくまシミュレーションであり、 COCOA悪用助長する意図はありません


かい説明や具体的な表現は控えましたが、この攻撃を仮に受けたとして致命傷に近いダメージを受ける事業者は少なくないと思います

事業所単位COCOA の導入を推奨している管理者直ちに見直すことを推奨します。

まとめ

本日より COCOA の導入を促すテレビCMが放映されているようです。( #検察庁法改正案に抗議します で一躍有名になったきゃりーぱみゅぱみゅ氏などが出演されているようです)

一方で COCOA アプリケーションリリース2020年7月13日リリースされた v1.1.2 を最後アップデートが途絶えており、不具合ととれる多数の事象解決されず、上記に挙げたような問題点払拭されることも残念ながら当面は無さそうです。

世間では高ぶる正義感からCOCOA の導入を声高らかに勧めたり、従業員ビジネスパートナーに導入を強いている管理者も現れているようです。

このエントリを通じて、そのような方々へ抵抗出来る材料提供できれば幸いです。

余談

冒頭のように COCOA の原型であるとされる Covid-19Radar/Covid19Radar プロジェクトOSS にあるまじき「放置状態」が続いています

これが GitHub を買収した企業所属する人間所作ですか?

IT/ICTOSS を通じて昨今の COVID-19 感染拡大を発端とする諸問題解決する動きは支持したいですが、このような杜撰サービス運営により IT/ICTOSS に対する世間の期待を悪化させることを強く憂慮しています

2020-06-29

よく知らんドメインからハッシュ値みたいな件名のメールが届いた。

しか添付ファイル付き。

開かないように注意して、ゴミ箱、そして削除。

そして、ドメインをググってみると、ドメイン名が売りに出されていた。

色々、謎。

2020-06-19

COCOAインストールなんてするわけがない

インストールしてなんのメリットがあるんだよ

わざわざ意味ねーアプリなんてインストールするかよ

したところで電池バカ食いしてそうだからアンインストールして終わりだよ

まぁ反対意見ばかり言ってもしょうがないので代案を

すれ違った芸能人一覧表示機能

夜の10時に「今日すれ違った芸能人」を教えてくれる機能

いつ、どこでは教えてくれない

また、2日連続とかだと教えてくれない

ただ、実はあなた橋本環奈とすれ違った、と教えてくれて、なんかワクワクできる機能

しかしたら同じ電車に乗ってたのかもしれない

同じ飲み屋で飲んでたのかもしれない

ただすれ違っただけかもしれない

でもワクワクする

これがあるならインストールする

芸能人にイイねできる機能

すれ違った芸能人の中には知らない人も多いと思う

でも、みんなでイイねしあうことで

「え?この女の子ってやたらイイねされてね?どんな子?」

っていう新しい推しを探すことができる機能

しかも知らない間に会っているから親近感も湧く

すれ違った人にステマできる機能

もちろんこれだとインストールする芸能人側にメリットほとんどない

から芸能人は好きなメッセージを送ることができる

YoutubeURLを教えてあげてもいいし、新しいアルバムの告知をしてもいい

そしてそれを受け取ったユーザーリダイレクトできる

ただし3ホップまでに限定する

あなたの受け取った橋本環奈映画の告知は、あなたの3ホップ以内の橋本環奈から実際に届けられたものだと思うとワクワクする

まるでウイルスのように伝搬していく広告

ニューノーマルにふさわしい

作り方

Bluetoothでもなんでもいいから近くの人にランダムハッシュ値を送りつける

受け取った側はそれを保存しておく

10時になるとそのハッシュ値芸能人から公開される

次の日はハッシュ値を変える

ストーキング防止のために1時間毎に変えてもいいかもしれない

2020-06-09

公開鍵暗号方式理解するのってなかなか難しい

anond:20200608212713

エントリーの人がどこまで理解しているか不明だけど、自分初心者だったときこういう説明がほしかったという話をしてみる。

暗号方式特に公開鍵暗号理解が難しいのはいくつか理由がある。

物理的なものに例えられない

②素朴な利用例が少なく応用的な利用がいくつもある

③実際の利用例はアプリの一機能になっていて見えづらい

また、ざっくりした概念以上のものをきちんと理解しようと思うと

④何がどのくらい安全で何がどのくらい危険セキュリティ的な概念説明

数学的な仕組みの説明

必要になり、これがまた挫折の原因になる。


ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。

利用者から見た公開鍵暗号の特徴

まず、物理的な錠前や書留郵便イメージするのはあきらめてほしい。

あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。

公開鍵暗号登場以前は、パスワードを使って変換(暗号化)して、同じパスワードを使って元に戻す(復号化)という共通鍵暗号時代が長く続いた。

そこに、ひとつの大発明があった。

それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。

特殊数学アルゴリズムパスワードから、それと対になるパスワード2を生成する

パスワードからパスワード1を逆算することは困難

パスワード1で暗号化したものパスワード2で復号できるだけでなく、その逆つまりパスワード2で暗号化したものパスワード1で復号できる(※)

今はその数学アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。

パスワード1(秘密鍵)を自分以外が見られないように保管して、パスワード2(公開鍵)を通信相手に渡せば暗号通信ができそうということは理解できると思う。

ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的

ツールで生成すると千文字程度のテキストファイル秘密鍵用と公開鍵用の2個できる。

これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。(※)

(※) このあたりは一般的公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照


応用的な利用

次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。

(a)秘密鍵暗号化した文書を送るね。公開鍵は〇○○だよ

誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。

(b)僕にメッセージを送るときは僕の公開鍵暗号化してね(いわゆる公開鍵暗号

これだと「僕」以外は秘密鍵がなく復号できないので安全

メッセージ送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。

メッセージに返信するときは今度は「僕」ではなく相手公開鍵を使って暗号化する。

(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号通信しよう(鍵交換)

共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネット流れるリスク排除した良いとこ取りの方式

(d)暗号化しない本文と、本文から計算したハッシュ値秘密鍵暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。

それからこの暗号化は僕しかできないから確かにから送られた文書、僕から送られた内容である保証できるよ。(電子署名

この「電子署名」の実現により、さらに次のような応用が可能になる。

(e)ログイン時に毎回パスワードを打つと見られたりして危険からユーザ名等に署名したものを送るね。公開鍵で復号(検証OKならログインさせて(公開鍵認証

(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き検証してみて。

Aさんは信頼できるよ。これがBさんの署名入りのお墨付き検証してみて。

Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き検証してみて。

サーバ証明書

アプリの一機能としての見え方

前項のようなやりとりはほとんどアプリ自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵秘密鍵を直接扱う機会は現状ほとんどないと思う。

ウェブブラウザアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マーク右クリックすると証明書を表示できる。

メールアプリでも最近自動的に鍵交換やサーバ証明書が使われている。

もしメールアプリPGPの設定オプションがあればそこで公開鍵秘密鍵を設定すると特定相手と本格的な暗号メールがやり取り可能になる。

サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵サーバ登録してログインに利用してる。

ログイン ユーザー登録
ようこそ ゲスト さん