PPOP


公開 (UL): 2021-06-01
更新 (UD): 2021-06-01
閲覧 (DL): 2024-12-12

この記事のもくじ

→本文へ
当サイトは SNS の公式アカウントがないので,「議論ネタ」にする際は,皆さんのブログ,メーリングリスト,SNS や掲示板などで,適当にハッシュタグを付けたりリンクを掲載するなどしてご利用ください。

前の記事

2021-03-04
全角⇔半角の変換

次の記事

2021-06-01
Base54

最近の記事

2024-02-11
XMPP - 長く使える安心チャット
2023-09-15
Perl の正規表現での A と Z の扱い
2023-01-16
Android のキーボード・ショートカット一覧
2022-08-09
代表的な画像ファイル形式一覧
2022-04-04
サイトのローカル試験と実ウェブ上の差を縮める手法(Perl)
新着情報
She appears also the top page.

新着情報 Recent docs.

Sorry, but most of these pages are only Japanese.
「ぱそはだ」シリーズ «PASOHaDA: Parts Assignment and Soldering Only Handmade Design Assist.»
高度な技能不要の電子工作で自立介護 DIY。
簡単にできるネット防犯対策 «Simple measures against phishing mails and malwares.»
フィッシングメールを暴き,ウイルスの侵入を阻止する簡単な対策を紹介。
福祉改善を阻むオヤクショ思考 «Japanese subsidy system of communication aid device for disabilities cannot be applied those if it's with features except communication, IDK why.»
「意志伝達」しかできない高額な装置にのみ税金が使われる謎制度。
「理不尽採点」教育と「英語力低下」 «Japanese English skill ranking in the world has been down. I guess one of the reason is that the government's education policy lacks coherence.»
日本人の英語力が低下,しかも小学校から英語が必修になった世代ほど。「教育方針の一貫性のなさが原因」とする考察。
倫理意識の社会的低下 «One day, I set to stop DM from a banking corporation, but those continue to be sent after that. I'm feeling falling sense of ethics in Japanese society.»
某銀行からの DM が,およそ金融と関係ないもの多数。停止設定後も何ヶ月も配信が続く状況に,倫理意識の社会的低下を感じた話。
給使乖離現象 «"Server and User Design Gap" phenomenon (abbr: SUDG), it's the trend to lack of considerations in design for user of the service.»
愚かな経営者たちが考えた劣悪なウェブサービスにより,人々が一方的に不利益を被るという話。
日本の「IT 人材不足」の正体 «The simple reason why Japanese companies lack IT-skill.»
保険会社からのセキュリティガバガバメールが「IT 人材不足」の正体を暴く。

人気記事 Frequent view pages.

現在当サイト人気 No.1!
Android のキーボード・ショートカット一覧 «The list of Android Keyboard Shortcuts (EN ready).»
Android のスマホやタブレットにキーボードをつないだ時に知っていると便利なキー操作。
表計算で「令和」に対応する方法
How to adapt the Gengo era "Reiwa" on spreadsheet applicaiton.

古いアプリも OK。「表計算 令和」の検索結果上位御礼!
表計算ソフトで予定表を自動作成する超便利な方法 «How to make the schedule table automatically on spread-sheet.»
「毎月第○×曜日」的な法則は自動で作らせてラクしよう!
表計算ソフトに「個人情報保護機能」を仕込む方法 «Prevention to leak private-data with spread-​sheet macro function.»
「漏えい」のためのフェイルセーフ。「表計算 個人情報」の検索結果上位御礼!
Wary-Basher (ワリバッシャー)
DIY device that enables the handicapped to operate many things with a switch like push-button.

障害者の様々な操作をスイッチ操作で実現する器具。キットも発売中! 「作り方」PDF ダウンロード多数御礼!←地方教育委で人気。

おすすめ! Recommend

貧乏人を殺す行政の構造 «Structurally, the administrators kill the poors in Japan.»
ヘタすると多摩川に流されるところだった台風 19 号

この記事に対する → 調布市の反応
[PDF 118KB] 生活保護申請時のオヤクショ対策
申請の「水際作戦」を突破するための心得。「ホームレス総合相談ネットワーク」製作の図解を小サイズ化したもの。

出典 ☞ 路上からもできるわたしの生活保護申請ガイド (2017 年版) (外部リンク)
文字ベース天気予報 «Weather forecast in text mainly from JMA Json-data.»
古いブラウザやスマホ,音読ソフトでも大丈夫! 気象庁の JSON データを利用した文字ベースの天気予報(試験版)。
「事故防シート」について «Cared persons taking with "Jiko-​Bow-​Sheet" prevents from accidents.»
介護現場の負担軽減と事故防止のアイデア
【連載】 キーボードの「キー」の詳しい使い方 «The detial of usage each key on keybord.»
各キーの機能詳細。機能別五十音順一覧。
和易ゐ記 (WAI-WIKI) «WAI-WIKI is light­weight markup language for Japanese, and generates HTML on this server on-​demand.»
当サイトで開発/使用中の日本語向けに特化した軽量マークアップ言語

ご連絡 Contact

▼ メールフォームはこちら
SSL 証明書の更新に不具合が多いため,期限切れエラーが出た際は,お手数ですが「例外指定」をお願いいたします。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。

ファイルの暗号化
当サイト管理者(石川)宛にメール添付で送信するファイルを暗号化したい時は,唯一のパスワードを PPOP で取得できます。 PPOP gives a password for encryption of the file(s) attached your mail to the admini­strator of this site M.Ishikawa.
PPOP

MEMO / Email to the Author
あとで調べたい点のメモなどに利用可能。
下部ボタンでそのまま著者にメールできます。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。


CAPTCHA: easy math prob in Japanese

時事川柳 News Senryu

パーティー券  
民意も一緒に
  蹴り返し
Kick back both party tickets and people's opinions.

 自民党の一部(?)派閥がパーティー券のノルマを上回る分の売上げを議員にキックバックしておきながら政治資金収支報告書に不記載だった問題が広がりを見せている。なるほど,こうしたことが党内で常套化していたのだとすれば,岸田総理はじめ同党政治家にことごとく「民意を蹴り返すクセ」が付いているのは当然という感じもする。これっぽっちも「悪いこと」と思わなかったのだろうな。そんな人たちに誰が票を入れるのだろうか。少なくとも,岸田の広島と「頭悪いねぇ」と暴言を吐いた議員を選出した長崎に「ふるさと納税」はしないことにしよう。
参考: 自民県 絶対しないぞ ふるさと税

今回はもう一句!

危機感の  
ワリに二階は
  誰も居ず
Having sense of crisis, but nobody takes shelter of 2F.

 大雨などで危機感を持ったら二階のような高い所へ避難すべき的な話を聞いたよーな気がするのだが? パーティー券のノルマ上回り分キックバックの政治資金収支報告書不記載問題で,安倍派は何人も辞任したのに,同じく捜索を受けている二階派に辞任する話があるかというと,今のところ誰もいない。総理は「危機感を持って」とか言っているらしいが,どこが「危機感」なのやら。

(⌚2023-12-19)

ご支援 Support this site.

まだまだ コロナ失業中!!
CORONA-NEET, seeking works now!

この活動をご支援いただける方はこちらへ Could you support this site, see here (but Japanese).
都道府県庁さん, 地方自治体さんや教育委員会さん, 障害者就労支援機関さんやその他公的機関,省官庁さん, 「タダ見」しているだけでは, 格差が広がるだけだと思いませんか?
Welcome!
Amazon    Google
The companies, thanks for many accesses every months! Are the articles I wrote helping for increasing your income? Although, I cannot get even a penny and jobs from that.

 PPOP とは,以下の略。

 無理やり英訳するなら,Password encrypted file is sent and the Password is notified by the Otherway Protocol といったところか。なお,当サイトの管理者である筆者が勝手に考えた方式で,この記事の公開時点では一般に通用する用語ではないので注意。

 特徴としては,以下のような感じ。

 ここでは,そんなデータセキュリティ方式 PPOP を考えてみたい。

● 従来方式の限界

 これまでよくやりがちだった PPAP とは,以下のような方式。

 略して PPAP と言うんだそーだ。言うならば Password locked file send by mail, and the Password send After that Protocol 的な感じだろうか。「パスワード付きファイル」としては,よく ZIP が使われるとか。ある企業で「PPAP 禁止!」とお達しが出たというニュースを見て,一部のネット民は「そりゃ,みんなで豹柄の服着てペンやリンゴ持って踊っている場合じゃなかろう」などと解釈されていたようだが,そうではない。そもそもセキュリティ上,ほとんど意味の無いやり方のためだ。暗号化したファイルとそのパスワードの両方が同じメールサーバやソフトで扱われるのだから,漏れる時は両方が同時に漏れる可能性が高く,漏れた先で簡単に開いて読めてしまうことになるからだ。

 ではメールなどで使う機密保護の方法として何があるのかというと,S/MIME とか GPG と呼ばれるものが一般的らしい。が,どちらも一筋縄ではない。まず S/MIME のほうは,「認証局」と呼ばれる業者に登録料を支払って「証明」してもらう必要があり,それもそれなりの「投資」になるらしい。その点,GPG は無料という点では気軽に使えるが,どちらにしてもその手の方法は,セキュリティは堅固であるものの取扱いが複雑。調べた筆者が未だに本格的に手をつけあぐねるレベル。古くからあるワリにあまり使われない原因は,その辺りではないだろうか。

 原理的には,前述した PPAP のような一般的な方法……たとえば ZIP や PDF などのファイルを「パスワード」で保護してメールする場合,暗号化の時も開いて見る時も同じパスワードのデータを使うが,これは「対称鍵」と呼ばれる。だから,メールで送るデータを暗号化したら,「パスワードはこれを使ってください」と知らせれば済むという取扱い易さはあるが,同じメールの宛先に送ると,「盗み見」された時に両方が漏れてしまうため,セキュリティ的にはあまり意味がない。

 一方,メールでこのリスクを避けるように考えられた S/MIME や GPG などの方法は「非対称鍵」と呼ばれるもので,「暗号化」に使う「鍵」となるデータと,それを開く時「復号(元の読めるデータに戻す)」に使うデータが別々になっている。この一対の鍵ペアのうち,暗号化鍵は公開しておき,受信者以外の人に読まれたくないデータを送りたい人が誰でも暗号化できるようにしておく。復号鍵側は公開しないので,その暗号を復号して読めるのは受信者だけ……といった仕組み。
 「初めてメールする相手」はどうするのか? そうした時のために,「暗号化鍵」に当たるデータ公開用のサーバがある。もしそのサーバで相手の名前で検索などして「鍵」が見つかれば,それを使って暗号化することで,初めて出す相手でも本人しか読めないようにすることができる。逆に言えば,サーバに見つからなければ,少なくとも初回は暗号化していないメールを送り,その「鍵」データを知らせてもらう……などの手間がかかることになる。一方,サーバで見つけた「鍵」データも,相手のメールアドレスが確実に分かっていればいいものの,そうでない場合,同姓同名の別人のものである可能性も否定できない。最悪,別人が「なりすまし」て偽の「鍵データ」を先にサーバ登録してしまっている可能性もある。別人の「鍵」の使用を防止するため「ハッシュ値」と呼ばれるものを公開している人も居るが,それは「確実にその人が管理していると分かるサイト」などで確認できない限り,「誰でも」確実な暗号化データを作れるというわけではないことになる。
 もちろん「返信」を望むなら,自分も暗号化のための「鍵」を作り,何らかの方法……たとえば同じようにサーバに公開するなどして,相手に知られるようにしておく必要がある。
 つまり,従来のメールの機密保持の方法は,送受信と受信者双方が,その S/MIME や GPG の対応アプリなどを使える環境を整えておく必要があり,その設定も必要。しかも,相手に見せたいファイルを暗号化する際は,暗号化の「鍵」に当たるものは「相手が」作ったものを手元に置いておく必要がある。両方がそれぞれ自分宛のデータ暗号化のための「鍵」を作り,相互に知れる状態でないといけない。しかもその「鍵」というのも,1つあたり数百バイトほどの大きさがあり,機密データをやりとりする相手が多くなると,管理もたいへんになってくるだろう。

 いずれにせよ,メールで使う本格的なデータ暗号化方式は,送受信者双方がそれらを使える環境……つまり「暗号化」と「復号化」ができるソフトを備え,暗号化鍵データを公開していて,確実に当人が管理するサイトでハッシュ値などを確認可能……などの条件が揃っている必要があり,あまり「気軽に」使えるシロモノではないわけだ。
 結局,ファイルの暗号化と復号に同じパスワードを使う方法のほうが分かり易く,扱い易い面も多々ある……ということになる。とはいえ,最初に述べた PPAP のような従来のやり方だと,ファイルとパスワードが同じメールアカウントに送られてくるのだから,盗み見られれば一緒に漏れる可能性が高く,セキュリティとしての意味はほとんどない。

◆ メール暗号化が必要な理由

 とはいえ,当初はなぜメールに暗号化が必要なのか少々疑問も感じていた。というのも,だいたいメールというのは自分のアカウントに届いたものを読む時は,受信サーバで「認証」が必要……つまり,読もうとしている人がアカウントの持ち主本人であることを確認するのだから,原則として本人以外が読むことなどないはずだからだ。メールソフトを設定する時に「パスワード」が必要なのはそのためで,メールソフトが本人に代わって「認証」する仕組みになっているのだ。
 しかし,事情は違って来ている。特に Gmail や Yahoo! メールなどでは,サービスを提供する Google や Yahoo! 社などが,メール内容に関連する広告を利用者に向けて発信できるようにするために,サーバにあるメールをコンピュータが読み取り,登録されている広告に関係するキーワードが書かれていないか「探り」を入れて来る仕組みになっているらしい。つまり,読むのはコンピュータとはいえ「本人以外が読んでいる状態」だということだ。省官庁などお役所サービスでメールの利用が進まないのは,こうした点への懸念もあるのではないかと思われる。
 しかも,Gmail や Yahoo! メールのアカウント所有者だけではなく,そこで受信した他者のメールも対象とされる可能性が高い。するとたとえば,たまたま迷惑メールで「エロい」ものがドカドカ入ってきちゃったりすると……「エロい」広告がバカスカ表示されてしまったりことも起こりうるのではないか。迷惑千万! 子供には使わせられんわな。
 とはいえ,コンピュータが自動でパスワード保護された添付ファイルの中身まで読む可能性は低いから,そういう意味では,PPAP のような方式でも,「とりあえず」の保護にはなるのかもしれない。が,そこまで「絶対にやらない」という保証もされていない。あるいは,外部から調べようがないのをいいことに,既に「こっそり」そうしている可能性も否定できない。

▼ PPAP のリスク
PPAP のリスク

 だが,「通信の秘密」は憲法で保証されているはず。だから,これはある意味「違憲状態」が黙認されているようなものではないかと思う。しかし,どーせ目先の「儲け」しか考えていない Google や Yahoo! 社がヤめるとは思えない。ではどうするか……「自衛」する手段は,といえば,それはもうパスワードをメール以外の方法で伝えるしかないのではないかと思う。
 ここでは,これら従来方式に代わる,手軽な方法を考えてみたい。

● PPOP の考え方

 要するに,ZIP や PDF など「対称鍵」で暗号化したファイルのパスワードを同じアドレスにメールすると,「同じサーバ」や「同じ管理ソフト」で扱われ「一緒に流出」するリスクが高まるのが問題なわけだ。ならば,せめてパスワードを別の方法で受け渡しできればマシだろう。
 とはいえ,電話や FAX,郵送などでは手間がかかる。できればメール同様「ネットで」完結できたほうがラク。しかも「誰でも使える方法」……と考えると,思い当たるのはウェブページくらいだ。だが,ウェブページというのは「誰でも同じ内容を見れる」のが特徴。GPG のように暗号化と復号する鍵が別々なら,暗号化鍵だけでは「復号できない」から,「同じ鍵データ」を誰でも読めるよう公開しても差し支えないが,ZIP のような「対称鍵」……つまり,暗号化鍵と復号鍵が同一の場合,パスワードを公開すると復号もできてしまうから,そうもいかない。

 ただ,CGI というものを使うと違ってくる。CGI というのはサーバ上で動作するプログラムのことで,アクセスごとに異なるデータを作って送る……といったことも可能になる。昔の記事にはよく「アクセスカウンタ」と呼ばれる数字の画像が掲載されていたが,それも CGI の一種だ。それは「アクセスされる度に1ずつ大きな数の画像を作って送る」もの。マサにアクセスの度に異なるデータを送ってくる仕組みだったわけだ。すると,CGI を使えば,「誰でも同じ内容を見る」ためのものではないウェブページも作ることが可能になる。

▼ PPOP の考え方
PPOP の考え方

 というわけで,ここでは CGI をうまく使い,「A=あとでメール」で送るのではなく,「O=Otherway 他の方法で」対称鍵をやりとりすることで,簡単で安全に暗号化してやりとりできる方法を考えてみたい。

● 使い方

 ここでご案内するツールでは,当サイトの管理者(石川)へ送りたいメッセージやデータを他者が見れないよう保護したい時,ZIP や PDF,ワープロなどのファイルでパスワードとして使う文字の並びを生成します。他からのアクセスで同じ番号とパスワードは表示しないため,他者がそのパスワードを知ることはできない仕組みです。
 たとえばそのデータを監理者にメールでお送りいただくような場合,パスワードと共に表示される「PPOP 番号」だけ本文などに記載していただければ,パスワードは伝えなくても番号から分かるためファイルを開くことができます。パスワードそのものを記載していなければ,そのメールがなんらかの原因で外部に知られても,ファイルの内容まで知られることを防止できます。
 以下のページより,番号とパスワードの対を取得できます。

▼ PPOP(取得ページ)
https://treeware.jp-help.net/ppop

 記事内のボタンを押した後に表示される「パスワード(Password)」の文字の並びをパスワードとして使って,ZIP や PDF などのファイルを保護してください。管理者には,一緒に表示される「PPOP 番号」だけを伝えます。ファイルをメール添付で送る場合は,同じメールに番号を記載しても構いません。
 得られたパスワードは,引き続き使用する可能性があります。少なくとも,当サイト管理者側からの返信などでパスワード保護する時は同じものを使いますので,保存/スクショ/印刷するなどで保管して,パスワードの側をメールに記載したり,他人に知れる状態に置かないようご注意ください。なお,メールサーバやソフトから漏えいする可能性がゼロではないので,自分宛メールで保存するのは避けたほうが無難です。

 ただ,当サイトで採用している SSL に未対応なブラウザでは表示できないことがあります。未対応ブラウザのご報告が多数あれば,回避策を検討いたしますので,管理者までご一報ください。

◆ 文字数オーバーの場合

 安全性を考えて 20 文字とちょっとのパスワードが生成されますが,使用するアプリの制限によってそれより少ない文字数しか使えない場合は,先頭から使える文字数分だけをパスワードとして,その旨メールなどに記載して伝えてください。

◆ 特定のパスワードを使いたい場合

 「部署内(あるいは『企画上』など)で統一して使っているパスワードがあるから,それに合わせたい」といった事情がある場合,その旨を共通パスワードと共に記載したファイルを作り,上記 PPOP のパスワードで保護して,メール本文のほうに PPOP 番号を記載して添付で送っていただければ,それ以降こちらから送信するファイルには,その「共通パスワード」を使うことができます。送信の際に,同時にその共通パスワードで保護したファイルを添付することも可能です。ただ,どちらも「パスワードそのもの」はメール本文などに記載しないようにします。

● 当サイトの PPOP

 ここでは,当サイトで開発して使っている PPOP システムについて,少し詳しく述べてみる。

◆ セキュリティ

 パスワードそのもののデータはサーバに保存していません。そのため「データファイルが流出してパスワードが漏れる」こともありません。パスワードは「ハッシュ」という方法で番号を元に作られていて,その「作る」部分は HTTP ではアクセスできない場所に置かれています。
 とりあえず,生成される「パスワード」は,数字と,アルファベットから(大/小文字を含め)数字と紛らわしい I(アイ),L(エル),O (オー),S(エス)を除いた 54 文字を使用し,「見間違い」による誤入力防止も図っています(「コピペ」が確実ですが)。ハッシュなど任意のバイト列を文字列にする方法として Base64 がありますが,記号類(+,/,= など)も使わないため,アプリによるパスワードで使える文字の制限を受けることもありません。Base64 より少ない 54 文字を使うため,筆者は「Base54」と呼んでいます。詳しくは,以下を参照。

▼ Base54
http://treeware.jp-help.net/?ssss10

 POPP 番号は,cookie を利用してブラウザに保存していますが,パスワードのほうは保存されないため,cookie を見ただけでは分からない仕組みです。
 通常ブラウザでは,他者が勝手に他人の PPOP 番号を自分のブラウザに設定することはできませんが,まれに可能な場合があります。ただ,「パスワード」を全て再表示するためには,パスワードの一部(4文字以上)を覚えていて入力する必要があるため,cookie を設定しただけでパスワードが知られてしまうことはありません。入力を何度か間違えると該当番号の再表示機能は凍結され,以降の入力は受け付けないことで,「総当たり攻撃」を防止しています。

◆ プライバシー

 個人情報登録のため入力を求める内容もありません。ただし,番号とパスワードの対を取得した IP アドレスは記録されます。これは,無闇に取得を繰り返して機能の妨害を狙う攻撃を防止するためです。特定の IP から頻繁に「取得」があると,その IP から新規の「取得」を当面凍結します。

● 短所

 PPOP は,「堅固さ」では,従来のメールで使われる S/MIME や GPG (PGP)などには適わないものの,PPAP とほぼ同じ取り扱いの容易さでセキュリティを強化できる点は最大の「長所」と言えるんじゃないかと思う。では,セキュリティ強度以外の短所は何が考えられるだろうか。現段階で思いつくのは,以下の二点。次節以降で個々に考察してみる。

◆ 提供には「サーバ」が必要

 PPOP では,パスワードそのものはメールなどで伝えず,ウェブサーバを経由させるわけだから,当然ながらサーバの設定が必要になる。つまりこれは,サーバ設定のできる人でないと「受け取り手になれない」ことを意味する。
 ただ,「サーバが必要」という点は,考えようによっては S/MIME や GPG などもそうではある。長く使われてきた方法であるだけに「専用のサーバ」が用意されているため,「専用サーバ」がまだない PPOP ほど困難ではないが,専用のツールで,時として「公開鍵(暗号化鍵)」を公開用の専用サーバにアップロードする必要はある。

◆ パスワードの数が多くなる

 S/MIME や GPG などの「非対称暗号化」では,「暗号化鍵」と「復号化鍵」を使う。すると全体としては,やりとりする人がそれぞれ2つずつ「鍵」を持つことになり,人数×2だけの「鍵」データが要る。
 ではこの PPOP では? 人数によってはかなりの数になる。「暗号化鍵」と「復号鍵」が同一の「対称鍵」だから,自分も相手も同じ「パスワード」を使うため,2人の間で使うなら「1つ」で済む。が,「やりとりする人ごとに別々のパスワードが必要になる」ため,人数が増えると二次曲線的に増える。たとえば,N人が PPOP でやりとりする場合,N×(N-1)÷2 だけのパスワードが必要になる。これは,5人までは GPG など従来方式以下の数で済むが,6人以上になるとグンと増えることになる。

▼ 必要な「鍵(パスワード)」の総数
必要な「鍵(パスワード)」の総数

 上記の表を見ると,9人の間でやりとりするのに必要になる「鍵データ」はちょうど倍で,以降は人数が増えるごとに増え方も大きくなる。
 ただ,「1人が管理すべき鍵の数」を考えると,相手の人数分だけで済むため,考えようによっては GPG などの既存の方法とそんなに変わらない。というのは,9人で互いにやりとりする場合,自分以外の8人の相手分だけパスワードを手元に置いておけばいいだけだからだ。
 なぜ数が増えるかというと,GPG などでは,特定の人に送信するデータには全て同じ「暗号化鍵」を使える。9人の間でやりとりする場合,ある人に送信するための「暗号化鍵」は,他の8人が同じものを持っている。それを「1つ」として数えるから「数」としては少なく見えるだけの話だ。「復号」は「復号鍵」を持つ受取人本人しかできない仕組みだから,「暗号化鍵」が同一でもいいわけだが,結局同じ「暗号化鍵」を,(8人の)送信者が別々に手元に置いて管理することになる。これを「8つ」と数えると,PPOP と変わらなくなる。
  PPOP でも,相手が8人なら8つのパスワードを手元で管理するという点は同じだから,管理手間的には大きく変わらないとも考えられる。GPG では,特定の人宛に使う「暗号化鍵」は同一だが,PPOP では全て異なるため,パスワードの「総数」を見ると多くなるわけだ。POPP は自分用の「復号鍵」の管理が不要な分,取扱いは容易かもしれない。

 しかも,述べた例は,データをやりとりする2人の間で,全て別々の「鍵(パスワード)」を使うことを前提としているが,たとえば特定の「企画(プロジェクト)」に関わる複数人数で,統一したパスワードを使うような場合,多人数間でもパスワードは「1つ」で済む。この場合 PPOP なら,元々が対称鍵のため直ぐそれができるが,GPG などでは,それ用の「対称鍵」を別に作る必要が生じるだろう。

● 詳細

 アクセスの度に異なる「文字の並び」を作って表示するだけなら簡単だが,それを「パスワード」としてファイルの暗号化に使う場合,ファイルを受け取った側でその「パスワード」が分からないと意味がない。完全なデタラメでは分かりっこない。番号と「パスワード」との間に,何らかの「結びつけ」が必要になる。どのように結びつけるか……その辺りも含めて考えてみたい。

「詳細を知りたい」というご希望が多数寄せられるようであれば,ここに追記して行きたいと思います。

● おわりに

 この方法(PPOP)は,今のところサーバに直接設定する方法のみなので,PPOP を組織的に導入したい場合は,当サイト管理者(石川)までご相談ください。

▼ このサイト監理者の連絡先
このサイト監理者の連絡先


© M.Ishikawa; TREEWARE 2024.