  |
はてなキーワード: 公開鍵暗号方式とは
＞各電報には、**送信元の情報（識別コード）**を付加し、なりすましを防ぐ仕組みが取られた。例：軍の電信では、送信者の認証コードを含めることで、偽のメッセージを排除。
これはどういうことですか？
電信通信では、悪意のある第三者が偽のメッセージを送信し、受信者を騙すリスクがありました。
これを防ぐために、**送信者が本物であることを証明する仕組み（識別コード・認証コード）**が導入されました。
敵国やスパイが偽の軍事命令を送る可能性があった。例えば、**「本日午後3時に攻撃を開始せよ」**という偽の命令を送れば、相手を混乱させることができる。
送信者が「本物」であることを確認しないと、受信者はメッセージが信頼できるかどうか判断できない。そのため、送信者の識別情報（認証コード）を追加し、受信者が確認できる仕組みが作られた。
送信者ごとに 「ユニークな識別コード」 を設定し、電報の最後に付加。受信者は識別コードをチェックし、本物の送信者であることを確認。
ATTACK AT DAWN. [CODE: XJ-472]
「XJ-472」が正しい識別コードなら、本物のメッセージと判断。
偽の電信を送る者は、正しい識別コードを知らないため、識別される。
送信者ごとに 決められた特定の「符号（モールス符号のパターン）」を入れる ことで、なりすましを防ぐ。
SIGNATURE: -.. .- ... .... (DASH)
送信者の識別符号「DASH」がついているため、受信者は本物のメッセージと確認。
受信者が送信者に「合言葉」を求め、それが正しく返答されるかで識別 する方法。軍事通信やスパイ活動で頻繁に使われた。
送信者が事前に決めたコードを送ることで、正しい相手であることを証明。
事前に送信者と受信者だけが知っている「秘密のキーワード」をメッセージに含めることで、改ざんを防ぐ。
「BLUE SKY」というキーワードを知らない者は、正しいメッセージを送れない。
送信者の識別技術は、現代の**セキュリティ技術（デジタル署名、認証コード、ハッシュ関数）**につながっています。
ワンタイムパスワード（OTP） 使い捨ての認証コードで本人確認
デジタル署名（電子認証） 送信者が本物であることを暗号的に証明
公開鍵暗号方式（PKI） 送信者の識別とメッセージの改ざん防止
識別コード・認証コード事態を盗み見されたら意味がないように思えます
例えば
１．ATTACK AT DAWN. [CODE: XJ-472]
を盗み見して
２．STOP ATTACKING. [CODE: XJ-472]
識別コードをそのまま盗み見されてしまうと、攻撃者が本物のコードを使って偽のメッセージを送信できる という問題があります（リプレイアタックの危険性）。
これを防ぐため、以下のような 追加の認証対策 が導入されました。
あなたが指摘したように、単純な識別コード（例：「XJ-472」）を毎回使うと、盗み見された際に敵がそのコードを使って偽の命令を送る ことが可能になります。
この問題を防ぐため、コードを使い捨てにする、または動的に変化させる 方式が考案されました。
識別コードを1回しか使えないようにする（ワンタイムパスワード方式）。
メッセージごとに異なる認証コードを生成し、同じコードを再利用できない ようにする。
1回目の通信: ATTACK AT DAWN. [CODE: XJ-472]
2回目の通信: ATTACK AT NOON. [CODE: QL-839]
もし敵が「XJ-472」を盗んでも、2回目の通信ではすでに無効になっている ため、偽のメッセージを送れない。
受信者は「すでに使われたコードかどうか」をチェックし、同じコードが2回使われた場合は無効とする。
受信者が送信者に**ランダムな質問（チャレンジ）**を出し、正しい認証コードを返すことで識別 する。
送信者：「昨日のコードが XJ-472 だったので、今日は QL-839」
送信者は コードのルール（シーケンス、数学的な計算）を知っているので正しく答えられる。
しかし、敵はルールを知らないため、コードを盗んでも次のコードを予測できない。
識別コードをハッシュ関数で計算 し、毎回異なるコードを生成する。
受信者はハッシュの元の計算方法を知っているため、確認が可能。
送信者：「ATTACK AT DAWN. [HASH: 2A7B3C]」
敵は「2A7B3C」を盗んでも、次のメッセージでどんなハッシュが使われるか予測できないため、なりすましが困難。
メッセージの中に、送信者と受信者だけが知る 「秘密のキーワード」 を隠しておく。
これにより、敵が単純に識別コードを盗んでも、本物のメッセージを偽造できない。
本物のメッセージ：
ATTACK AT DAWN. [SECRET: SKY BLUE]
偽物のメッセージ：
STOP ATTACKING. [CODE: XJ-472] ← 本物のコードを使っていても、秘密のキーワードがないので偽物と判定。
送信者が**個人の特徴（音声、特定のモールス符号の癖）**を利用する。
例えば、モールス符号の打ち方のリズムが本人独特のものなら、なりすましが困難。
-.-. --- -.. . --- ... -.-.-- (CODE OK!)
受信者は「この符号の打ち方は司令官の癖と一致する」と判断し、本物と認識。
7. まとめ
識別コードが盗まれた場合の対策として、以下の方法が使われました：
方法 内容
ワンタイムコード 一度使ったコードは再利用不可（盗まれても無効）
チャレンジ＆レスポンス 受信者が質問し、送信者が正しい答えを返せるか確認
＞フィルタ回路を追加し、雷や外部ノイズによる誤信号の混入を低減。
フィルタ回路とは何ですか？
1. フィルタ回路とは？
フィルタ回路は、不要なノイズ（高周波・低周波の干渉）を除去し、必要な信号だけを通す回路 です。
電信通信においては、雷、誘導ノイズ、地磁気変動などによる不要な電流をカット する役割を果たしました。
2. ノイズの種類と影響
(1) 雷（サージノイズ）
雷の影響で強い電圧変動が発生し、電信線に一瞬大きな電流が流れる。
これがモールス符号の「短点（・）」や「長点（―）」に誤認される 可能性がある。
複数の電信線が並行して走っていると、お互いの信号が干渉することがある。
これにより、「H」を送信したつもりが「I」に誤認されるなどのエラーが発生。
近くに高電圧の電線があると、電磁誘導によって不要な電流が発生 し、電信信号が乱れる。
3. フィルタ回路の仕組み
フィルタ回路には**「特定の周波数帯の信号だけを通し、それ以外を遮断する」** という働きがあります。
これにより、ノイズを除去し、純粋な電信信号だけを伝送することが可能になります。
一定以上の周波数をカットし、低周波信号（モールス信号）だけを通す。
これにより、高周波ノイズ（雷や誘導電流）が影響しにくくなる。
低周波のノイズ（地磁気変動など）をカットし、必要な信号だけを通す。
例えば、低い電圧の誤信号（地磁気の変化による微弱な電流）を防ぐ。
モールス信号の周波数帯域（例：300Hz～800Hz）のみを通し、それより高すぎる or 低すぎる信号をカット。
(1) 受信側にフィルタ回路を追加
モールス電信の受信機の前にフィルタを挿入し、ノイズを除去してから信号を受信する。これにより、オペレーターが不要なノイズを聞かずに済む。
(2) グランド（接地）回路の強化
電信線の片側を地面に接続し、雷や外部ノイズを地面に逃がす「避雷回路」 を導入。雷が落ちた際、フィルタを通じてノイズをグラウンドに逃し、受信機が誤動作しないようにした。
(3) ツイストペア線の導入
電信線を「ツイストペア（2本の導線をねじる）」構造にすることで、電磁ノイズの影響を減らす。これにより、隣の電信線からの干渉（クロストーク）が大幅に軽減。
5. 現代への応用
電話回線のノイズフィルタ アナログ電話回線では、低周波のノイズをカットするフィルタが使われる。
インターネットのルーター 高周波信号だけを通すフィルタを搭載し、データ通信の信号品質を向上。
Wi-Fiのバンドフィルタ 必要な周波数（2.4GHz, 5GHz）だけを通すことで、干渉を防ぐ。
ツイストペア線（Twisted Pair）の仕組みとノイズ低減の原理
電信線を「ツイストペア（2本の導線をねじる）」構造にすることで、電磁ノイズの影響を減らすことができます。
これは、電磁誘導と干渉の原理を利用した技術で、現在のLANケーブルや電話回線にも応用されています。
ツイストペア線では、2本の導線をねじることで、外部ノイズの影響を打ち消す効果があります。
(1) 外部ノイズの影響を平均化
例えば、電信線の周囲に**外部ノイズ源（電磁波、雷、他の電線の影響）**があるとします。
2本の導線が平行に配置されている場合、片方の導線だけに強くノイズが影響する可能性がある。
しかし、導線がねじられていると、外部ノイズの影響が導線全体で均等になり、結果として平均化される。
（図示：外部ノイズが発生する例）
平行な電線: 外部ノイズが不均等に影響 ─────────── ← ノイズ（強い影響） ─────────── ← ノイズ（弱い影響）
ツイストペア線: ノイズが交互に影響し、平均化 ＼／＼／＼／＼／＼／＼／＼／ ← ノイズ（平均化） ／＼／＼／＼／＼／＼／＼／＼
(2) 電磁誘導の打ち消し
電線に流れる電流は、周囲に**磁場（電磁波）**を発生させる。
ツイストペアでは、隣接する部分で磁場の向きが逆になるため、互いに打ち消し合い、ノイズが発生しにくくなる。
＞乱数表を使ってモールス符号を変換し、意味を隠す方法が開発された（ワンタイムパッド方式の先駆け）。
ここを詳しく教えてください
モールス電信では、盗聴のリスクを防ぐために暗号化技術が発展しました。その中でも、乱数表を利用した暗号化は、後に「ワンタイムパッド（One-Time Pad）」として発展する重要な技術の先駆けでした。
乱数表を使った暗号化は、送信する内容を事前に用意したランダムな数列と組み合わせて変換する方法です。
これは、一度しか使えない乱数を使うことで、解読がほぼ不可能になるという特徴があります。
(1) 暗号化の手順
２．事前に用意した乱数表を使う
例えば、「HELLO」に対して「37492」という乱数を割り当てる。
「H（8）+3 = 11」、「E（5）+7 = 12」、「L（12）+4 = 16」……
「11-3 = 8（H）」、「12-7 = 5（E）」……として元のメッセージを復元。
2. 具体的な暗号化の例
(1) 乱数表の例
文字: A B C D E F G H I J K L M
乱数値: 3 7 4 9 2 5 8 3 6 1 0 4 7
文字: N O P Q R S T U V W X Y Z
乱数値: 2 5 3 9 1 4 7 8 6 2 3 5 0
H（8）+ 3 = 11
E（5）+ 7 = 12
L（12）+ 4 = 16
L（12）+ 4 = 16
O（15）+ 5 = 20
(1) 非常に強力な暗号化
事前に用意された 完全にランダムな数列 を使うため、乱数表を持っていない第三者が解読することは不可能。
暗号文のパターンが存在しないため、頻度分析による解読ができない。
同じ乱数表を繰り返し使用すると解読されるリスクが高まるため、使い捨てにするのが基本。
「ワンタイムパッド（One-Time Pad）」の基礎になった技術。
(3) 盗聴対策
たとえモールス符号が傍受されても、受信者が持つ乱数表なしでは意味を解読できない。
送信者と受信者が 同じ乱数表を持っていないと通信できない。乱数表を安全に配布する必要があり、これ自体が盗まれるリスクがある。
(2) 一度しか使えない
同じ乱数表を何度も使うとパターンが発生し、解読される可能性がある。通信ごとに新しい乱数表を準備する必要がある。
5. 歴史的な応用
軍隊では、電信の盗聴を防ぐために乱数表暗号を採用。特に第一次世界大戦、第二次世界大戦では、機密電報の暗号化に利用された。
乱数表暗号のアイデアは、後に「ワンタイムパッド暗号」として正式に確立。これは理論上、絶対に解読不可能な暗号方式であり、現在でも**超機密通信（政府・軍・外交通信）**に使われている。
6. 現代への影響
ワンタイムパッド（One-Time Pad） 完全に安全な暗号方式（数学的に解読不可能）
現代のエンドツーエンド暗号通信 メッセージごとに新しい暗号キーを使う発想
この仕組みについて、さらに詳しく知りたい部分（例えば乱数表の作り方、実際の軍事暗号の事例、現代の暗号技術との関係）があれば、ぜひ質問してください！
乱数表を事前に共有するのは分かったのですが、送信者がどの乱数表を使ったのか分からないので受信者もどの乱数表を使えばいいのか分からなくないですか？
乱数表を事前に共有している場合、送信者と受信者はどの乱数表を使うのか？
乱数表を使った暗号通信では、送信者と受信者が同じ乱数表を選んで使う必要があります。
これを実現するために、以下の方法が考案されました。
送信者と受信者がどの乱数表を使うかを決める方法には、次のような方法があります。
(1) 事前に順番を決めておく
送信者も受信者も、現在の通信で 何番目の乱数表を使うのかを把握しておけば、同じものを使える。
送信者と受信者が 同じスケジュールに従って進めば、どの乱数表を使うべきか分かる。
送信者が乱数表「ID: 23」を使った場合、受信者は 「乱数表23」を選んで復号する。
例えば、通信のたびに1ページずつ破棄しながら進むことで、送信者と受信者が同期できる。
使用したページは破棄することで、再利用を防ぐ（安全性が向上）。
(4) 日時を基準にする
例えば「2024年2月17日」のメッセージには、事前に決めた「2024/02/17用の乱数表」を使用。
送信者と受信者がカレンダーを共有していれば、追加の情報なしで同期が可能。
スパイや軍事通信では、「数字放送」と呼ばれる短波ラジオ放送を利用し、乱数表の識別情報を事前に送る方式が使われた」。
ラジオで**「本日のキーは56」と送れば、受信者は「乱数表56」を使用する**ことができる。
一度使用した乱数表は必ず破棄し、再利用しない（ワンタイムパッド方式）。
乱数表が盗まれると危険なので、軍事やスパイ通信では 使用後に物理的に燃やす（焼却処分） こともあった。
3. まとめ
事前に順番を決めておく（1回目の通信→乱数表A、2回目→乱数表B）
メッセージ内に乱数表の識別番号を含める（例：「ID: 23」を記載）
ワンタイムパッドの冊子を作り、ページ番号順に使う
日付ごとに対応する乱数表を使う（例：2024/02/17 → 乱数表A）
ナンバーズステーションのような方法で、事前に識別情報を伝える
＞各電報には、**送信元の情報（識別コード）**を付加し、なりすましを防ぐ仕組みが取られた。例：軍の電信では、送信者の認証コードを含めることで、偽のメッセージを排除。
これはどういうことですか？
電信通信では、悪意のある第三者が偽のメッセージを送信し、受信者を騙すリスクがありました。
これを防ぐために、**送信者が本物であることを証明する仕組み（識別コード・認証コード）**が導入されました。
敵国やスパイが偽の軍事命令を送る可能性があった。例えば、**「本日午後3時に攻撃を開始せよ」**という偽の命令を送れば、相手を混乱させることができる。
送信者が「本物」であることを確認しないと、受信者はメッセージが信頼できるかどうか判断できない。そのため、送信者の識別情報（認証コード）を追加し、受信者が確認できる仕組みが作られた。
送信者ごとに 「ユニークな識別コード」 を設定し、電報の最後に付加。受信者は識別コードをチェックし、本物の送信者であることを確認。
ATTACK AT DAWN. [CODE: XJ-472]
「XJ-472」が正しい識別コードなら、本物のメッセージと判断。
偽の電信を送る者は、正しい識別コードを知らないため、識別される。
送信者ごとに 決められた特定の「符号（モールス符号のパターン）」を入れる ことで、なりすましを防ぐ。
SIGNATURE: -.. .- ... .... (DASH)
先生何でも知ってるな
(1) 口伝（くでん）と使者 (2) 狩猟・戦争における合図 (3) 狼煙（のろし）
(1) 楔形文字（メソポタミア）・ヒエログリフ（エジプト） (2) 郵便制度の発展
(1) 紀元5世紀～15世紀 (2) 烽火（ほうか）・のろし (3) 飛脚制度（日本）
(2) 交換機の導入
グリエルモ・マルコーニが無線通信（ラジオ通信）の実験に成功。
1901年、大西洋横断無線通信を達成し、船舶や遠距離通信で活躍。
1920年代にAMラジオ放送が開始され、大衆向けの放送メディアとして普及。
腕木通信の仕組みについて教えてください
1. 基本構造
通信塔（セマフォア塔） 高い場所に建てられ、見晴らしの良い地点に設置される。直線上に複数の塔が並び、情報をリレー方式で伝える。
腕木（アーム） 一般的には2本または3本の可動式の木製の腕。腕の角度を変えることで、異なる文字や数字を表現する。
制御機構 塔の内部には腕木を動かすためのハンドルやロープがあり、通信員が操作する。
2. 通信の流れ
腕木通信では、腕木の角度を組み合わせてアルファベットや数字を表す符号が決められていました。
例: ある位置の角度が「A」、別の角度が「B」を意味する。組み合わせることで単語や文章を伝達。
(2) 視認と伝達
発信者（通信員）が塔の上で腕木を特定の角度にセットする。隣の通信塔の通信員が望遠鏡でその信号を確認する。確認した通信員が同じ符号を自分の塔で再現する。これを繰り返し、情報が数十～数百km先までリレー方式で送られる。
3. 腕木通信の特徴
(1) 速さ
馬や飛脚より圧倒的に速く、良好な天候なら数百km先まで数分～数時間で伝達できた。例: フランスでは、パリ～リール間（約230km）を約3分で通信可能だった。
(2) 天候の影響
晴天時は遠くまで見えるため有効だったが、霧・雨・夜間は利用できなかった。これが電信の発明へとつながる大きな要因となった。
フランスではナポレオン戦争（1803-1815年）の際、軍事通信に活用された。ヨーロッパ各国でも行政・軍事目的で導入。
アルファベットや数字を表すために、腕木の角度を組み合わせた符号表（コードブック）が用意されていました。
ここでは、腕木通信で「HELLO」を送る具体的な手順を説明します。
腕木（アーム）：通常、2本または3本の可動アームが使われる。
符号表（コードブック）：各アルファベットや数字に特定のアームの角度が割り当てられている。
A = 10° / 30°
B = 20° / 40°
C = 30° / 50°
...
H = 80° / 120°
E = 50° / 90°
L = 70° / 110°
O = 90° / 130°
2. 「HELLO」を送る手順
腕木通信は 1文字ずつ順番に送信 し、隣の塔がそれを読み取り、次の塔に伝えるリレー方式で情報を伝達します。
(1) Hを送信 通信塔のオペレーターが腕木をHに対応する角度（80° / 120°）に設定。隣の塔の通信士が望遠鏡で確認し、同じ符号を再現。
(2) Eを送信 次に、腕木をEの角度（50° / 90°）に変更。これを隣の塔へリレー。
(4) Oを送信 最後に、Oの符号（90° / 130°）を送る。
文字ごとに送ると時間がかかるため、短縮コード（例：「HLO」で「HELLO」とする）を使うこともあった。軍事通信では暗号化された符号も使用。
エラーチェック
送信ミスを防ぐために「確認信号」を送ることがあった。受信者が「正しく受信した」ことを示す信号を返す方式も採用。
単なるアルファベットだけでなく、「数字」「特別な記号」も符号表で定義。
A = 10° / 30°
とはどういう意味なのですか？
10度のこと？30度のこと？
「A = 10° / 30°」という表記は、腕木（アーム）が複数ある場合に、それぞれの角度を指定する方式です。
通常、腕木通信には2本または3本の可動アームがあり、それぞれのアームを特定の角度にセットすることで、1つの文字や数字を表現します。
例えば、2本の腕木（上側と下側）がある場合：
上のアーム：10° 下のアーム：30°
＞受信者が「正しく受信した」ことを示す信号を返す方式も採用。
これはどのような仕組みですか？
腕木を「A」に対応する 10° / 30° の位置にセットし、隣の塔に見せる。
確認信号（例：「了解」を示す特定の腕木角度、または短い「OK」信号）を送信する。
例えば「50° / 90°」のように、「受信しました」の意味を持つ角度が設定される。
受信者からの確認信号を見て、正しく受信されたことを確認 する。
もし確認信号が来ない場合、または誤りを示す信号が来た場合、もう一度「A」を送信し直す。
腕木通信には、以下のようなエラーチェックの方法も考案されました：
(1) 再送要求
受信者が符号を読み取れなかった場合、「もう一度送ってください」という特定の信号（リクエスト信号）を送る。
例：「不明瞭」や「再送」を示す角度（例：60° / 120°）を使用。
(2) 確認の二重チェック
受信者だけでなく、次の塔が再び「A」を送ることで、送信者が正しく伝わったことを確認できる。
これにより、1つの塔で間違いがあっても、別の塔で補正が可能。
電鍵（モールスキー） 手動のスイッチで、押すと電流が流れる。押す時間の長短で「短点（・）」や「長点（―）」を作る。
(2) 通信線
電線（単線または複数線）送信機と受信機をつなぐ導線。初期の電信機は1本の電線と地面（アース）を回路として利用。
電磁石
送信側でスイッチが押されると、電流が流れて磁場が発生。電磁石が作動し、紙に記録する装置が動く。記録装置（スタイラス ＆ 紙テープ）スタイラス（針） が上下に動き、紙テープに「短点（・）」や「長点（―）」を記録。初期は音ではなく、紙テープに記録する方式が使われた。
モールス電信機の受信機は、以下の主要な部品で構成されています：
(1) 電磁石
送信者が電鍵（モールスキー）を押すと、電流が流れ、受信側の電磁石に電流が到達。電磁石が磁力を発生し、アームを引き寄せる。
電磁石の磁力によってアームが動く（電流が流れた瞬間に引き寄せられる）。電流が切れると、バネの力でアームが元の位置に戻る。
(3) スタイラス（記録針）
アームの先端には スタイラス（記録針） が付いている。アームが動くことで、スタイラスが紙テープに接触し、点や線を刻む。
(4) 紙送り装置
受信機には ロール状の紙テープ がセットされており、一定の速度で送られる。紙テープが一定の速度で進むことで、信号が「短点（・）」や「長点（―）」の形で記録される。
記録の流れ
(1) 短点（・）の記録
送信者が電鍵を短く押す（例：0.1秒）。受信機の電磁石が一瞬作動し、アームが紙に軽く接触。紙に小さな点が刻まれる（・）。電流が切れると、バネの力でアームが元の位置に戻る。
(2) 長点（―）の記録
送信者が電鍵を長く押す（例：0.3秒）。受信機の電磁石が長い間作動し、アームが長時間紙に押し付けられる。紙に長い線（―）が刻まれる。電流が切れると、バネの力でアームが元の位置に戻る。
(3) スペース（間隔）
電鍵を押さない時間が長いと、記録装置には何も刻まれず、文字の区切りが生まれる。一定時間（例：3単位）何も信号がなければ、単語の区切りとみなされる。
初期のモールス電信では、紙テープに記録された符号を手作業で解読していた。
しかし、受信機のアームが動くと「カチッ」という音がすることに気づき、オペレーターが耳で直接モールス符号を聞き取る方式（サウンドレシーバー方式）が生まれた。
これにより、紙に記録しなくてもリアルタイムでメッセージを受信できるようになった。
電線に電流を流す仕組みを聞いた限り距離が制限されそうに思えます
これについて詳しく教えてください
モールス電信機は電流を電線に流して情報を伝えるため、通信距離にはいくつかの制限がありました。特に、長距離になると電流が弱まり、信号が減衰（減少）するという問題がありました。
ここでは、電信の通信距離の制限と、それを克服するための技術について詳しく解説します。
長距離の電信通信において、電流の減衰（弱まる）原因として次のような要因がありました。
(1) 電気抵抗
電線の長さが長くなると、電気抵抗（電流の流れを妨げる力）が増えるため、電流が弱まる。銅や鉄などの導線を使用していたが、特に鉄線は抵抗が大きく、距離が長くなると信号が伝わりにくくなる。
19世紀の電信では、片側の導線＋地面を電流の経路として使用（単線電信方式）していた。しかし、湿気や土壌の違いによって電流が地面に漏れ、信号が弱くなることがあった。
近くに他の電信線があると、電磁誘導によって信号が干渉することがあった。雷や電磁気の影響によって信号が乱れることもあった。
こうした問題を解決するために、いくつかの技術が導入されました。
「リレー（中継器）」を使って信号を増幅する方法が発明された。1835年、ジョゼフ・ヘンリーが電磁リレーを開発。リレーは、受信した信号を増幅して再送信することで、長距離通信を可能にした。例えば、100kmごとにリレーを設置すれば、電流の減衰を防ぎ、信号を遠くまで伝えられた。
初期の電信では低電圧（数V程度）だったが、より高い電圧（数十V～100V）を使うことで信号を強くし、距離を延ばした。ただし、高電圧は電線の絶縁性を高める必要があるため、ゴムやガラスを使った絶縁技術が発展した。
初期の電信では鉄線が多く使われていたが、鉄は抵抗が高いため、導電率の高い銅線が採用されるようになった。銅線の採用により、長距離でも電流の減衰が少なくなり、信号が安定。
長距離の海底電信ケーブルでは、さらに電流の漏れを防ぐ工夫が必要だった。1858年、最初の大西洋横断海底ケーブルが敷設されたが、当初は絶縁技術が未熟で、短期間で故障。1866年、改良された絶縁材（ガタパーチャ樹脂）を使用したケーブルが成功し、長距離通信が可能になった。
1844年 64km（ワシントンD.C. - ボルチモア） 初期の電信
1861年 約3,000km（アメリカ大陸横断電信） リレー技術の発展
1866年 約4,000km（大西洋横断海底ケーブル） 絶縁技術と増幅器の進化
1900年 数万km（グローバル電信網） 高電圧、改良ケーブル、無線通信の併用
電信通信において、距離が長くなると電流が減衰し、信号が弱くなる問題が発生しました。この問題を解決するために開発されたのが 「リレー（中継器）」 です。
リレーは、弱まった電流を利用して新しい電流を作り、信号を増幅して次の区間へ送る装置 です。ここでは、リレーの仕組みを詳しく説明します。
(1) 電磁石
入力側から微弱な電流が流れると、電磁石が作動 する。これにより、リレー内部のスイッチ（接点）がONになる。
電磁石の磁力でスイッチが閉じる（ON）と、新たな強い電流が流れる。つまり、弱い信号をトリガーとして、新しい電流を発生させる。
(3) 新しい電源
大企業ではほとんど採用されていると思うが、メールゲートウェイ型のセキュリティアプライアンスで、添付ファイルが
ついていたら暗号化解除して中に含まれるファイルに悪意があるマクロ、プログラムが含まれるものがないか検査して
OKだったら送信許可、NGなら削除されましたの通知だけを送るなどをしている。
従いスキャンできないと、一律でメールは削除、若しくは添付ファイルは削除されましたの通知のみ送られる。
企業のセキュリティポリシーとしてこうしているところはあります。ウイルス感染対策の検知対策確度を上げるため。
さらに、ローカルPCにウイルススキャンが入っていて添付ファイルをローカル保存するとき、開くときにスキャンが
メールゲートウェイ型アプライアンスで、企業のインバウンド/アウトバウンドメールを一律、
チェックしたいんじゃないのかな。それなりに意味はあると思いますが、例えばgmailだと、
これまで暗号化解除(解析&解除)でチェックしていたと思われるが、CPUリソース食いまくりな事
や実効性への疑問(ほかの対策若しくは、複数対策を組み合わせる事での効率化)があって、
添付ファイルはチェックされず送られるか、削除されて何も通知されないみたいです。
> 3、なんで毎回同じPWじゃないの？
同じパスワードだとそれが漏れたり、第三者に知れたら容易に暗号化解除して見れてしまうから。
> これは1の通り、プロキシサーバーでスキャンできる仕組みを作る必要があるってことでいい？
プロキシーサーバではなくてメールゲートウェイ型アプライアンス(古くはオンプレでInterscanなり、、最近は知らんけど)
> この場合既存の仕組みを使えないし、クラウドサービスにロックインされるし
> 腰が重いのもわかる気がする
なにか同等のサービスがあると思う。
とりあえず、G Suite(旧google apps)だとgmailのメールフィルタ機能が標準装備でゴミメールはだいぶ減る。
メールソフトへの実装があまりはやらなかったのもあるし、暗号化強度の問題もあったのでは。(推測)
公開鍵暗号方式の実装したもので使いやすいもの、若しくは この手の送り手/受け手が正しい人かつ、
悪意を持ったプログラムが含まれないことを担保できるメール送受信の仕組みを作ればよいと思う。
インターネット自体は、自律分散系システムなので送ったものが必ず届くという確証もないし、
元エントリーの人がどこまで理解しているか不明だけど、自分が初心者だったときこういう説明がほしかったという話をしてみる。
暗号方式、特に公開鍵暗号の理解が難しいのはいくつか理由がある。
②素朴な利用例が少なく応用的な利用がいくつもある
また、ざっくりした概念以上のものをきちんと理解しようと思うと
④何がどのくらい安全で何がどのくらい危険かセキュリティ的な概念の説明
ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。
まず、物理的な錠前や書留郵便をイメージするのはあきらめてほしい。
あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。
公開鍵暗号登場以前は、パスワードを使って変換（暗号化）して、同じパスワードを使って元に戻す（復号化）という共通鍵暗号の時代が長く続いた。
それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。
・特殊な数学的アルゴリズムでパスワード１から、それと対になるパスワード２を生成する
・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）
今はその数学的アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。
パスワード１（秘密鍵）を自分以外が見られないように保管して、パスワード２（公開鍵）を通信相手に渡せば暗号通信ができそうということは理解できると思う。
ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的。
ツールで生成すると千文字程度のテキストファイルが秘密鍵用と公開鍵用の2個できる。
これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。（※）
（※） このあたりは一般的な公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照
次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。
誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。
(b)僕にメッセージを送るときは僕の公開鍵で暗号化してね（いわゆる公開鍵暗号）
メッセージの送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。
メッセージに返信するときは今度は「僕」ではなく相手の公開鍵を使って暗号化する。
(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵で暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号で通信しよう（鍵交換）
共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネットに流れるリスクを排除した良いとこ取りの方式。
(d)暗号化しない本文と、本文から計算したハッシュ値を秘密鍵で暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。
それからこの暗号化は僕しかできないから確かに僕から送られた文書、僕から送られた内容であると保証できるよ。（電子署名）
この「電子署名」の実現により、さらに次のような応用が可能になる。
(e)ログイン時に毎回パスワードを打つと見られたりして危険だからユーザ名等に署名したものを送るね。公開鍵で復号（検証）OKならログインさせて（公開鍵認証）
(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き。検証してみて。
Aさんは信頼できるよ。これがBさんの署名入りのお墨付き。検証してみて。
Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き。検証してみて。
（サーバ証明書）
前項のようなやりとりはほとんどアプリが自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵や秘密鍵を直接扱う機会は現状ほとんどないと思う。
ウェブブラウザのアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マークを右クリックすると証明書を表示できる。
メールアプリでも最近は自動的に鍵交換やサーバ証明書が使われている。
もしメールアプリにPGPの設定オプションがあればそこで公開鍵と秘密鍵を設定すると特定の相手と本格的な暗号化メールがやり取り可能になる。
サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵をサーバに登録してログインに利用してる。
最後に観たのは探偵たちの鎮魂歌だから、実に12年ぶりである。
地上波はそれ以上に観ていない。
まず、キャラの演技だいぶ変わってる気がする。
特にアガサ博士と少年探偵団、灰原に違和感。まぁ10年以上も経てば変わるか。
それと、声に老けを感じてしまい、少し寂しく。そのうちドラえもんみたいに世代交代もあるのだろうか。
おっちゃんは声優も変わって演技も違うのだけど、そんなに抵抗はなかった。
ストーリーについては、「いやいやそうはならんやろｗ」とか「なんでやねんｗ」って突っ込みどころが多くて、内心突っ込みながら楽しんでいたんだけど、世間一般的には重厚なストーリーという評判らしい。マジか。
安室さんは初見だけど、29歳で(恐らく年功序列が色濃く残っているであろう)公安の秘密組織で指示を出せるくらいの地位があるという日本中の才能とコネの特異点のような存在が、IoTテロの可能性に思い至らないものだろうか。あまつさえ、スマホにこっそり盗聴アプリを仕込む知識もあるというのに。
やたらコナン上げしていたのが気になった。（まぁ原作やら他のエピソードで理由が描かれてるんだろうけど）
ついでにNW経由で操作されるだけで電子機器が爆発炎上までしちゃうあの世界の安全基準はどうなってんだ。
探査機のパスワードを打ち込む瞬間、「よろしくおねがいしまあああす！」と聞こえた気がした。そういえばあれも人工衛星をGPS誘導によって落とす話だったか。
ていうか探査機との通信に使う暗号方式って、パスワードによる共通鍵暗号方式なん？公開鍵暗号方式とか使うんでないの？そこらへん詳しくないから誰か教えて。
RX-7の頑強さとかキック力増強シューズで蹴り出されたボールの威力とかはまぁ空想科学読本あたりで検証されるだろう。今も空想科学読本が残ってるかはわからないけど。
てな感じで、基本突っ込みながら楽しむ作品だと思ってるけど、100億に相当するかと言われたらちょっと微妙な感じ。
「量子コンピューターが一般化したら 」というと焦点がぼやけるから
という前提でいこう。
何か中央集権的な手段で、過去の取引履歴を保護してやらないかぎり
ビットコインでは過去の取引履歴から口座の残高を求めるので、取引履歴が捏造されると
ある人はあなたの口座には100BTCがあると言い、
別の人はあなたの口座には1BTCも入っていないと言う状況になる。
しかし、過渡期に量子コンピュータでも有効なハッシュ関数などを使って
「『正しい』過去の取引履歴」が中央集権的に確定させることはできる。
そうすれば前述の問題は発生しなくなる。
ブロック生成の仕様を、量子コンピュータでも解けない計算に切り替えれば、
運用も続けられる。
試験、受けました。
ことさら話題にするようなことでもないかもしれませんが、せっかくなので書きます。
これから受ける人などの参考になれば幸いです。
30代。
製造業。
プログラミング歴は数ヶ月。
それまではExcelWordがちょっと分かるくらいだった。
初受験。
内製のソフトがC++でできていて、これを色々弄くれるようになればあんなところやこんなところまで自動化できるなあ、でも何も知らないまま弄るのはちょっと怖いなあ…
そうだ、勉強しよう！
8月半ば、受験申込期間の締め切りギリギリに試験の存在を知り応募。
勉強期間は2ヶ月ほど。
平日は1日1〜2時間。土日は1日3〜5時間。まったく勉強しなかった日が10日ほど。
最初に、ネットで評価の高かった合格教本という本を買って読んでみた。
基本情報の知識もない状態だと、書いてあることがもうほんとにまったく分からず、挫折しそうになった。
方針を変えて、応用情報技術者試験ドットコムで過去問道場をひたすら回した。
分からない言葉はネットで調べて、これはと思う説明に出会ったらOneNoteにひたすらコピペした。
最後の2週間はドットコムでユーザー登録をし、理解度で問題を色分けするようにした。
最後の1週間でピヨ太くんのサイト(正式名称長い)を見つけ、分からない言葉はまずこのサイトで検索するようにした。
受験前は、
…のどれかを選ぼうかなと考えていた。
いわゆるストラテジ、マネジメント系科目だけで固めても良かったのだけど、組込みなんかは普段の生活からイメージしやすいし、2時間半の長丁場ならテクノロジ系科目を間に挟んだ方がほどよく頭のリフレッシュになるかなーと思っていた。
実際の試験では、
…を選んだ。
机上に置けるような時計は持っていなかったし、まあ午前だけなら時計が無くても大丈夫だろうとタカをくくっていた。
問題を順当に最後まで解いて、全て順番通りにマークされてることを確認してから、手を挙げて外へ出た。
15分ほど余っていた。
さすがに午後は時計が無いとマズイと思い、休憩中に買ってくる。
セキュリティ(必須問題)の設問1で長考してしまい、20分ほど経っても解答用紙の半分が埋まっていない状態。
とりあえず他の問に移り、最後に余った時間でセキュリティに戻る方針にシフト。
経営はぱっと見簿記の知識が生かせそうだと思い選んだのだけど、「固定長期適合率」がどういう計算式なのか見当がつかない。
早々に切り上げる。
組込みの設問1でまたも長考、ほぼ解答を埋められたものの、結局40分ほど費やす。
サビマネ、監査は焦りから問題文の通読ができず、設問を最初に読むようになり、結果読み返しが増えてしまった。
監査を終えたところで5分くらい余ったので、這々の体でセキュリティに戻る。
午前とは逆に、始終時間との戦いだった。
午前は78.75点。
午前は問題用紙に選んだ選択肢に○する余裕があったのだけど、午後はそれがなくなって、問題解くのに必死で自分が何を書いたかしっかり思い出せない。
色々と書いたけれど、そういう訳で正直受かってるかまったく分からない。
配点、部分点次第といったところ。
怖い。
午後の対策が難しい。
午後対策でよく見られるのは「国語の読解力をつける」というアドバイスだが、読解力というのは漠然としていてレベルの向上も分かりづらい。
今の私なら、以下の順番で勉強を進めるかもしれない。
そもそも、「試験に合格するための勉強」に終始して、最初の動機がなおざりになっちゃった感が否めません。
…でもそれらがなんなのかはよく知らない、みたいな。
一つ確実に「分かった」と胸を張って言えることは、
分からないことは、調べればいい。
分かる人に、聞けばいい。
ってことですかね。
受かってなかったとしても、もう受けないかもしれませんね。
はぁ…10万欲しいなぁ…
以上で終わりです。
最後まで読んでいただきありがとうございます。
お疲れ様でした。
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
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.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
恥ずかしすぎてハンドルネームでやってる自分のブログにすら書けず、かと言ってどこかに吐き出したくはあったのでここに書いておく。
見た人は存分に笑い飛ばして欲しい。
先週、趣味で立てたVPSサーバー(CentOS 6.5)のCPU使用率が、気付くまでの9時間ずっと100%になっていた。
作動中のプロセスを見ると、2つのperlプロセスがその原因であることが分かった。
そのプロセスはユーザー「postgres」によって実行されたプロセスだった。
postgresは、PostgreSQLをインストールすると勝手に作られるユーザーだ。
先日自分でPostgreSQL9.4をインストールしたので、このユーザーの存在自体は問題無い。
その時このpostgresに、「postgres」という簡素なパスワードを、passwdコマンドで設定した。
「まぁ無いよりはマシなんじゃね？サーバー内でしか使わないユーザーだからハッキングの心配とかないしどうでも良いけど〜。」
と言ってたと思う。
その程度の認識だった。
これにより下記コマンドでpostgresとしてサーバーに入れてしまう状態になっていた。
$ ssh pos[email protected]
実行するとパスワードを求められるが、もちろんそれは前述のパスワード「postgres」だ。
それまではパスワードを設定していなかったので逆に助かっていた。
パスワードが設定されていないユーザーにはsshでは入れないからだ。
「もちろん」というが、それまではユーザーのパスワードがsshで入る時のパスワードになることを知らなかった。
そしてそれだけで接続可能になる可能性があることを知らなかった。
sshサーバーの設定はひと通り、自分が使っているVPSサービスがやってくれており、多分大丈夫だろうとそのまま使っていたからだ。
それでハッキングされ、そいつに謎のperlスクリプトを走らされていた。
具体的なスクリプトファイルや.bash_historyは消されていたようで、どんなものを走らせられていたのかよく分からない。
ハッキングであることを知ったのは、/var/log/secure を見たからだが、そもそもこの自体に陥るまで /var/log/secure の存在とその役割を知らなかった。
「ポスグレ(PostgreSQL)がなんかバグったわ〜でも原因がよく分からんわ〜ヒマだしハッキングの可能性も考えとくか〜でも絶対ポスグレがバグったんだわ〜」
でググって初めて知ったぐらいだ。
それで見たらパスワード設定してから9日間でそれぞれ別の端末23件から不正アクセスを受けていたことが分かった。
VPSサービスのコントロールパネルを見ると、その内の1件が侵入した3分後にCPU100%現象が始まったので、十中八九そいつの仕業だろう。
それ以外の連中が何をやったのかは分からない。
分からないのでOSを再インストールした。DoS攻撃だったらあとで攻撃先に訴えられるかもしれないので、全データを家のパソコンにDLする事で証拠（？）を保存してから。
/etc/ssh/sshd_config には、sshサーバーの設定が書かれている。
その中のPasswordAuthenticationをnoにし、公開鍵暗号方式による認証のみ受け付けるようにした。
他になんかやることとかある？おしえてぴょーん
もともとはUNIXに使われていたCrypt,DESのブロック長が８バイトだったのと
当時はそんなにディスク容量もなかったので便宜上バスワードは８バイトまで。（８バイトで切られる）
という歴史的仕様だった時の名残。今はSHA256かSHA512だから６４文字ぐらいまでなら何の問題もない。
もっとも、当のUNIXの世界ではとっくの昔に公開鍵暗号方式とワンタイムパスワードの組み合わせになってるので
直接パスワードを送信したりはしない。
３０年か４０年ぐらい昔の仕様が今でも残っているのが８文字なんじゃないかなぁ。いくらなんでも、時代に追いついてなさすぎだよね。
ちなみにDESなんてもう使わない。３DESですら脆弱、MD5,SHA-1ですら脆弱と呼ばれる時代っすからね。
ただ銀行系の人は、そんな知識もないでしょ（技術屋じゃないからね）。下手すりゃ証明書はベリサインだよね。とかまだ言ってるとおもう。
彼らの知識を更新するのは、とんでもない重労働だからSEは誰もやらないと思う。そんな事しなくても古い技術で金がもらえるのにわざわざ危険を犯してまで進言する奴はもう銀行業界にはいないだろ。
