  |
はてなキーワード: end-to-endとは
要するに1Gbpsと10Gbps論争
最近は10Gbpsを諦めて2.5Gbpsになってきているので、1Gbps越え論争の方が正しい
5/10Gbps提供はかなり広まっているのでここはそんなに問題無い
価格も1Gbpsと大して変わらない
実測としては10Gbpsは絶対に出ないが、2〜3Gbpsなら出る
ただし、それはスピードテストをしたときの話であってEnd-to-Endでそれだけでるかどうかは全く別の話になる
10Gbpsは依然としてまだまだだが、1Gbpsを越えるという意味では使えるようになってはいる
またType-C接続のRJ-45ドングルも2.5Gbps対応が出てきている
ノートPCだけでなくスマホでもWiFi 6（11ax）対応が増えてきている
11axなら理論上は最大9.6Gbps使えるが、これは160MHz帯域を8本同時利用した場合で、そんなPCは無い
現状では2本同時利用なので2.4Gbpsが上限となるので、1Gbps越え通信は可能である
本題のアプリケーションだが、単体で1Gbpsを越えるような通信をするアプリケーションは存在しない
8K映像を非圧縮で送れば72Gbps必要だがH.265だとせいぜい100Mbps、将来的な規格では50Mbpsほどまで圧縮できる
10部屋あって全員が8K映像を同時視聴すれば1Gbpsを越えるかもしれない
オンラインゲームでは遅延を嫌ってUDPでバカスカ送ることもあるが、それでも100Mbpsもあれば十分である
非圧縮で送るとコーディング遅延がなくなるが、そもそも伝送遅延がバカみたいに大きいので圧縮しても大差が無い
一方でファイルなどの送受信では帯域幅がそのままダウンロード・アップロード時間に直結する
5GBのイメージをダウンロードする時間は1Gbpsから2.5Gbpsにすればまぁ半分ぐらいにはなる
オンラインストレージをバカスカ使う人にとっては1Gbps越えが魅力的に思えるのだが
実際にはソフトウェア側の工夫（キャッシュなど）によってそれを体感できるかどうか怪しい
実際にDropBox, iCloudやOneDriveはどれもよくできているので帯域幅による違いを感じにくい（細すぎるとダメダメだが）
モデムで28.8kbpsで頑張っていた頃は1Mbpsも出れば夢のような未来が待っているという期待があった
ADSLで1〜10Mbpsもつかえ始めると「1Gbpsも使えるの？」と思っていたが実際には10Mbps越えの通信は十分に需要があった
なので今、「1Gbps以上必要あるの？」と思っていても、将来的には必要になるかも知れない
否定はしないが、1〜10Mbpsの頃から4Kや8Kの話やクラウドストレージのような話はあって
将来的に1Gbpsが使えたときの利用方法は山のように案があった
今、10Gbpsの利用法として合理的なものは知る限り全くない
特にコーディングに関する技術が進みすぎて映像伝送に帯域が不要となったのが大きいように思う
何より1Gbpsの状況が10年以上続いているのが好例だと思う
特に5Gでモバイル網のスピードが固定網に追いついてしまっているので
ハンドオフ等を考えれば全て5G（もしくは6G）でカバーする方が接続性・速度ともに満足度が高い
5Gアンテナを多人数で共有している限りは速度上昇は見込めないので
この業界に求められているのは5GC内蔵の屋内5GプライベートアンテナをeSIM認証で自由にハンドオフできる世界線だと思う
PCにeSIMが入るようになれば屋内でも屋外でもシームレスにネットワーク接続できるし
スタバでWiFiに繋がらなかったりドコモフリーWiFiに勝手に繋がってLINEが来ない、という未来もなくなる
ただ、そのときであっても家庭の屋内配線は1Gbpsで十分である
マンションや店舗のように複数人で共有するなら当然1Gbps以上の回線が必要だが、伝送距離を考えればファイバーの方が有利である
NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく
そもそもIOWNって何？っていう話については恐らくNTTの社員でも誰一人答えられないので割愛したいが
発端は電気によるネットワークルーティングに限界が来ていることから始まっている
このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ
IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること（All-Photonics Network: APN）が構想の発端である
電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる
1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった！」となるだろう
IOWNは100Gbpsを提供してくれる
ちなみに今でも企業向けに100Gbpsの専用線サービスは存在している
なのでIOWNは何も大容量サービスではないのだ
ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので
まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない
また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう
ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い
低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだが
低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである
さて、IOWN1.0の提供価格は月額198万円とのことである
現在提供されている100Gbpsの専用線サービスも198万円である
これも資料を見るとIOWN1.0では1.0倍とのことなので妥当な価格である
IOWN2.0では13倍（倍とは？）とのことなので価格も大幅に下がってくれるだろう
逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある
ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが
遅延に関してはIOWN1.0で1/200を目指している
これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる
さて、低遅延になって誰が嬉しいのかはさておき、現状では東京ー大阪間で15msぐらいである（往復）
これが1/200になると75μsとなるのだが、東京ー大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない
なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる
実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが
15msが8msになったのを「1/200」と言われるのはモヤッとする
そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている
つまりは大容量であることを活用して非圧縮で送信すればコーデック部分の処理遅延を減らせるとの主張である
コーデックの遅延は製品にもよるが200〜800msぐらいある
また、超低遅延のコーデックなら10msを実現できるらしい（使ったことはないが）
伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう
ただしそれは従来の100Gbpsネットワークでも実現できる
特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワークを研究する際によく使われた方便で
4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ
それが今の時代では、8K非圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである
ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう
問題なのはこの非圧縮リアルタイム映像伝送はほとんど使われていないということである
コーデックが進化することでコーデックにかかっている遅延は無視できるようになり
特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ
なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワークの試験で用いられているのが現状である
まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない
それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか
遠隔での演奏を実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる
この2mに価値があるのだろうか
また、人間の脳のクロック間隔は30msであるという研究結果がある
15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である
問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ
光の速度の限界なので当たり前ではあるのだが
限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ
普通の演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える
確かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている
そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが
そもそもe-Sportsのゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか
同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い
逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが
ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが
10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない
もちろんゲームによってはこの数msで価値が生まれる場合もあると思うが、あまり数は多くないように思える
結局のところ、IOWNは大容量かつ低消費電力、つまりは低価格のサービスとして進んで行くだろう
End-To-EndでIOWNが必要か、と言われると明確に答えはNOで
10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークはそもそも必要ない
一方でデータセンタ間のインフラネットワークとしては非常に価値が高い
データのレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ
特に災害が多い日本では地理位置分散をさせることは非常に重要で
そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる
こうしたインフラとしての重要性は明確に求められているのにもかかわらず
「IOWN」と標榜してまるで次世代のネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ （写真=AP） 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。
Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。
では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。
或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。
これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。
原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、
暗号A = XをA乗してYで割った余り、
暗号B = XをB乗してYで割った余り、
鍵AB = 暗号BをA乗してYで割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
