今日の項目
11月23日の何か 勤労感謝の日
佐和文香（お願いお星さま）　誕生日〜☆ミ

レールガンは､あたしとしては､結構昔から知っていることだったけど､
その最初が何だったかは覚えてない。

デモ、昨今は､国防の武器として考えているとかで､国家予算がどうとかなんか言っている。


レールガンを使うに当たって､膨大な電力が必要と言っているのも、あれがどうとか、これがどうとかっていう話になっているのにも､なんか実にくだらない理由に思える。

砲弾（鉄片）を打ち出す際に､電磁力で引っ張るか､押すかして打ち出すからですよね？

打ち出す前の状態はどう考えても、速度０
速度０の物を限られた砲身の長さで、マッハ超えまで加速するから大変だとは思いませんか？？


たとえば、初めから､時速が１００ｋｍ／ｈ以上有ったら、もっと簡単だと思いませんか？？

世界には､加速器と呼ばれる物があります。

物理の実験で使うヤツですね。

これ、小型のを作って､ある程度の速度まで出せるようにしておけばいいと思いませんか？？

加速器その物も､結構な電力を使いますけれど、何メートル有るか分からない砲身のたいしたことの無い長さで加速するよりは､電力かから無いと思うんですよね？

実際に､レールガン的に使うのはその砲身で良いにしても､砲身へ入れる時に初めからある程度の速度にまで上げておいて､砲身本体の方で打ち出すだけにしておけばいいと思うのです。

加速器の方は､ある程度の長さと､自由に曲げ伸ばしが出来る様な構造にしておいて・・・

何だったら､１００ｍくらいにしておいても良いわ？

そこから、加速していって、砲身に入る頃には､時速数百キロにまで上げておけば、そこから､更に速度を上げるだけならば､０からマッハいくつまで揚げるよりも、全然楽だと思うの。

遠くにいる敵を物理で破壊するだけなら､スイッチオンから、実際に射出されるまでに多少の時間が合っても何の問題も無いわ？


ミサイルを打ち落とすとかだと､押して直ぐ飛んでいっても､命中させるのは難しいだろうけど、
航行中の船とかなら楽勝でしょ？
航空機とかでも､問題無く出来ると思うわ？

装置が大きい（長い）ほど、充電する余地も出来るし、部位が分かれていた方が、楽よね？

開発中の装置が､一体どのくらいのサイズなのかとか､知らないけれど､もっと色々とやりようは有ると思うのよね？

PSO2のことの前にVRChatとAnimazeの事を書きましょうか？

１６日（前回）に書いたように、この週末は色々と試してみたのです。

その結果として、
Animazeにおいて東北ずん子のVRMの表示が破損するのは、良く分からない。
他のアバターは破損しないものも有る。

ずん子のVRMはかなり古いものですから、仕様が確定していない部分があったとか、Animazeでは対応していない作りをしていたのかもしれないけれど、まぁ推測だとか憶測でしか有りません。

それはそれとして、

色々と選んだ結果、

なっふな堂の「ルシナ -Rushina-」オリジナル3Dモデル

を選びました。

まだ、Animaze Editorの使い方がイマイチ分かっていないので、そのまま変換して、そのまま使っています。

Live2Dと違って、VRMというか？avatar形式のデータは、動きがとても速く、またかなり忠実に動きを再現していることが分かりました。

その結果、東北ずん子にはかなり無理をさせていたことが分かりました。

webカメラは液晶モニターの上に載せているのですが、その所為で、あたしの頭は常に下を向いている様に判別されていました。

それじゃぁ、頭が常に下を向いているのは当然ですよね？

そして、もう一つ、

モニターはあたしから結構離れているのですが？
それの所為か、常にのけぞっているとされていました。

画面の中のルシナは仰け反って俯いている訳ですから、姿勢が悪い悪い。
後ろ髪は物理演算か何かで動きますが、サイドの髪が、体に埋もれていることにしばらく気がつきませんでした。

これをなんとかするにはどうしたら良いでしょうか？

という事になります。

ハッキリ言って思いつきません。

モニターがやや高いのが悪いのだと思います。

モニターのトップは完全にあたしの頭よりも上です。
下部の方が近いくらいです。

また、24型のモニターはかなりのサイズがありますから、離れてみるのは当然だと思うのですが？
距離感はどうやって判別しているのでしょうか？
ただのwebカメラには、深度を測る機能は無いと思うのですが？

う～ん、
調べてみると細かいオプションがあるみたいですね
https://www.animaze.us/faq/desktopjpn/advancedwebcamjp

まぁ、距離については今夜試してみましょう。

問題は、顔の角度です。

もちろん、顔のロール？　ピッチだったかな？　の値を制限して上げれば、それだけで顔は上を向くのですが、カメラを出来れば顔の高さに近づけたいんですよね？

このカメラは、液晶などの縁置きだけでなく、テーブル置きも出来るので・・・って事もあるのですが、液晶はテーブルに直置きではないので、それはそれで、下過ぎる。

まぁ、元々距離があるので、上の縁に、初めから下向きで設置出来れば、それが一番だと思うのですが？

まぁ、下の縁でも良いのですけれど（付けられるのであれば）
微妙なDIYをしないとダメなのかも知れません。


そうそう、とくに書いていませんでしたが、
ずん子のVRMをAnimazeで読み込むと破損するのですが？
買ったルシナは破損しないのです。

まぁ、これはある意味賭けですね。

ぷるぷるしながら、決済を実行して、
読みが終わるまでの時間は結構ドキドキしました。


それはそれとして、この子にはオプションがいくつかあるのです。
胸のサイズとか、耳の有り無しとか。

シェイプキーというもので調整するらしいのですが、
animazeでどうやって編集すれば良いのかが判らない。

まぁ、胸のサイズも、耳のサイズも、調整しなくても良いかもしれませんが、
あとは、服のバリエーションの設定の仕方が分からない。

たぶん、Animaze Editorで先に該当部位をOFFにしてから出力すれば良いんじゃなイカと思うけれど、

例えば、袖だけ消してみるとか？
そういうのが、どうすれば良いのかが判らない。

そもそも、操作しているモードが根本的に違うのかも知れない。

XYZ、たぶん座標だと思うけれど、これ以外の編集項目は何が書いてあるのかが分からない（笑）

先日、editorを日本語に変更出来るみたいな事が書いてあったので、これも今晩あたりに試してみる予定。
ただ、ポリゴンの用語とかは、英語のままだったり、カタカナになるだけの気がする・・・？


何はともあれ、VRMでの挙動が行えるようになりました。

Animazeはまだまだやりたいことが出来きってはいないのですが？
それなりに満足が出来る動作も出来ている訳です。

Animazeのサブスクリプションは特別高い訳ではありませんが、年間２０ドルを払うのかどうかは、やはりある程度出来てからじゃ無いと困りますからね。
まぁ、１００円／ドルとすれば、２０００円です。

OneDriveなどに比べれば全然安いですからね。

問題ありません。

毎回パラメータをリセットされるのが、これほどまでに面倒とは思いませんでしたよ（笑）

パラメータを保存する代金が２０ドルと考えると、とても高いのですが・・・
本来は有料のソフトウェアをタダで使っているのですから、お試しが無期限で出来て、ちゃんと使いたいならお金を払えというのであれば、２０ドルは特に高くないと思います。



次、VRChatですが・・・

重い・・・訳では無いと思うのですが？
動作がもっさりしている。

あと、結局Steam版を利用しています。

アバターのアップロードが出来るかどうかは、アカウントの問題らしくて、Steam版のアプリでも問題が無いようです。


何気なく、目の前にあるクッションを押したら、持ち上げてしまって・・・
それをおくことが出来なくなってしまって、それ以降使っていません。
（宙に浮いたまま放置ですよ）

名前の変更は出来るようですが・・・Googleのアカウントから行ったので、名前がね・・・？
公開されているのは本名ではありませんが、名前が出てしまっているので、とても外では使えない感じで？

また、使い方がさっぱり分からない。

前後左右に動くことは出来ますが？

マウスクリックをすると、いろいろとおきるのですが、
ハッキリ言って判らない。

VR関係のは用語が分からないのが多すぎて、何も出来ないのがね～

と言うことで、VRChatは当面使わない。
二度と使わないかも知れない。

VRM関連というのであれば・・・
ライブラリが公開されていますよね？

これを使って、仮想空間を自分で作った方がマシな気がしてきました。


分からないなら作ってしまえ


・・・プログラマの悪い癖ですね？

ある時？を境に同期が取れなくなりました。


いつ頃？と聞かれても困るのですが？

推測で言うならば、PCを買い換えて、入れ直してからの気がします。

もっと前からでしたか？
良く分からないのですが、結構前からです。

で、これまでも色々と探していたのですが、結局分からず、JustSystemにあるFAQに書いてある事をAtokのバージョンが違うのにも拘わらず、ファイルを見つけ出してやったりもしましたが出来ませんでした。

特に問題なのが、修復すれば、同期が出来ることです。

修復して、直ぐであれば同期が出来るのです。


であれば・・

使用中に何か壊れたデータが作成されるって事ですよね？
それを、あれこれと探してみましたが、結局分からず、
あっちを弄ったり、こっちを弄ったりして、同期出来ることを確認してって事を続けていたのですが？

ついに別のＰＣでも同期が出来なくなってしまったのです。

この２台のＰＣと、後はスマホでATOKを使っている訳ですが、同期が取れないと意味が無いじゃ無いですか？？
Atok Passportはなんのために１０台まで入れられるのか？？

ってことで、再度探し始めたのです。

すると、見つけたのはこちら・・・

https://shumaiblog.com/mac-troubleshooting-atok-sync-error/

これまでにも、確定履歴は何度か消したこともあったのですが・・・
すでに鯖にある確定履歴のデータが壊れていたんじゃ無いかと思うのです。

それ以降・・確定履歴は、全てのAtokで同期しないように設定しました。

詳しいことはこちらを・・・・って書こうかと思ったけど、どうやら書いただけでアップしていない記事がありました。

なので、この辺りに貼り付けておきます。


Resizable BARの説明
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ReBarもしくは Resizable BAR
AMD的に言うならSAM もしくは Smart Access Memoryと呼ばれる物

これはPCIeのVer.2.1あたりで制定されたもので、PCIeの仕様で言うならResizable BARであって、それにAMDが専用の名称を付けたのがSmart Access Memoryということで、基本全く同じ物だそうです。

さて、これが何かと言われても、分からない人が多いでしょう。
もちろん、ググれば色々と出て来ます。

簡単に言うと、メモリにアクセスする際に、
従来の物だと、所々境界があって扱いづらいので
全体にアクセス出来た方が楽だよね？　ってことでPCIeに追加された仕様という訳です。

ようするに、PCIeの仕様です。

だけど、当然ながら、

PCIeを提供するCPU
物理配線をするマザーボード
対象となるGPU
実際に動作させるOS

と色々な物が対応している必要があります。


まぁ、とりあえず、Resizable BARが何故必要なのかという説明をしましょうか


最近は大量のデータを送受信する関係で、GPUには数Gのメモリが搭載されていることが殆どです。
当然、その大量のデータをストレージから読み出して、GPUのメモリにいれておいて上げないと、GPUは画面に表示するデータが足りないことになってしまいます。

しかし大量のデータを送信するには、PCIeの仕様が微妙だった。
今でこそ、PCIeのストレージも有り、大容量データの送受信が当たり前ですが、初めはそうでは無かった訳です。

なので、上位アドレスを指定して、そこに対してデータを送信する。
上位アドレスを変更し直して、次のデータを送る。

とても面倒だし時間が掛かったのです。

そこに追加されたResizable BARは何かというと・・・

Resizableはサイズの変更が可能という意味ですね。　まぁ、それだけだと何の意味もありませんが？
問題は、BARの方
Base Address Register

ここで言うベースアドレス　と言う物が何かというと、上で書いた「上位アドレスを指定」の部分です。
Registerはレジスタ。CPUにも沢庵有りますが、値をいれる場所ですね。

実際にこれらがどう言う風に実装されているのかは分かりませんが、
ベースアドレスを指定し直さなくても、メモリ全体にアクセス出来るということです。

でも、そこまでしか考慮しなかった場合、大した違いは出ない。
一部のアプリケーション（主にゲーム）は大量のデータを使うので多少の効果はあるかもしれませんが、ベースアドレスの再指定がそこまで時間が掛かる訳がありません。

ミリ秒単位の誤差でしか有りません。

でも、PICe4.0の特徴は以前（3.0等）に比べて帯域が広い。


Resizable BARは全体に対して大量のデータを一気に書き込むのに非常に適している訳です。


－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

さて、当然ながら、ゲーム等も対応していなければ成りません。
DXに任せて全く何も気にせずデータを書き込んでいるようなゲームでしたら、自動的に対応するかも知れませんが？

アグレッシブにデータを入れ替えるアプリケーションほどResizable BARの恩恵はすさまじいのです。

すでにSAMや3060でResizable BARを使ったいくつかのベンチマークがありますが？

少ないものでも数％　大きいものでは数十％のパフォーマンスがアップすることが分かっています。

nVidiaも困ったでしょうね～

AMDはRyzen 5000シリーズにて満を持して発表した訳です。

しかし上で書いたようにResizable BARはPCIeのVer.2.1頃に導入された機能です。
帯域の狭いそんな頃合いに実装されても大した意味は無かったでしょうけど4.0なら大きな違いがあります。

そして、愚直にその機能を導入していたAMDのCPUとintelのCPUは実は既に対応していました。
intelとしては、使われない機能だとしても、導入せざるを得なかったのでしょうね？

その辺りを特に気にしていなかったマザーボードメーカーはたまったものでは有りません（笑

一応気にしてある程度機能はあったのでしょうね？
AGESAの更新と共に各メーカーは無事に対応させました。

そして、問題はGPUですよ。
RadeonにてSAMが発表されて・・・・発表するくらいですから、Radeonは当然対応している。

対応していないのはnVidiaだけになってしまいました。

テストをしない訳にも行かないので結局最下位の3060から導入を開始し、半月のテストを経て全モデルへの導入を行いました。

まぁ、Resizable BARの実装その物は、大した面倒でも無かったでしょうが？
今まで無かったVBIOSの配布と更新機能の提供。

これらも含めて大変な一ヶ月だったでしょうね？


さて、ここまで書いてきたのですから、当然書く訳です。


あたしの使っている
Ryzen7 3800XTでも問題なく動作しています。
AMDもそろそろサポート対象として発表すれば良いのに？

これが対応前（BIOSで機能は有効済み、有効にしていないとそもそも出ない）


これが対応した結果

後は、NGSが対応してくれれば何の問題も無い。

要望を送るだけです。


※追加　❌１

それにしても
0830000000 - 7FFFFFFFFFという膨大なメモリ空間はすごいですね～
ＧＰＵはそのうちの
7C00000000 - 7DFFFFFFFFしか使っていませんけどね、
では、計算してみましょうか？

7E00000000 - 7C00000000 = 200000000
ではこれを10進数に直しましょうか？
8388608
ですね。
これを1024で割っていけば綺麗に８Ｇとなります。

後ろに８Ｇの空きがありますが・・・？
ようするにリソースの要求範囲としては最大容量の3060あたりの16Gを想定しているのでしょうか？

ただ、3090になると24G実装している訳ですから、範囲が違うと思いますけれど？

単純に考えると
7A00000000 - 7FFFFFFFFF
になっているか？後ろを空けておいて（３２Ｇ実装を考慮して）
7800000000 - 7DFFFFFFFF
あたりでしょうか？

そのうち誰かが公開するでしょう。


それはそれとして、
7800000000 - 7FFFFFFFFF　で　３２Ｇな訳ですから？
7000000000 - 7FFFFFFFFF　で　６４Ｇ


1000000000 - 7FFFFFFFFF　で７倍の４４８Ｇ

0830000000 - 0FFFFFFFFF　で２０９６Ｍ

４５０Ｇと４８Ｍの容量ですね。


この大容量メモリを使いこなせるＰＣは生まれるのでしょうか？？


※追加　❌２

因みにResizable BARその物はPICeの機能。
アプリケーションとして特別対応させなくても、それなりに効きますが？

当たり前な話しですが、

ギリギリまでチューニングしたアプリケーションは、
２５６Ｍずつデータを用意して、２５６Ｍずつデータの差し替えをして動くように作られて居ます。

ようするにResizable BARの恩恵を受けにくい。

ギリギリのアプリケーションほど恩恵を受けず、データを大量に使用するほどほどのアプリケーションほど恩恵を受けやすい。

「DX11もDX12関係なく、全てのアプリケーションが恩恵を受ける」と書いている記事があるけれど、それは言い過ぎ。

逆にデータをまとめすぎないようにDetuneする必要がある。

対応させる必要はあります。

未だに終わることの無い

「〜」と「～」の問題。

最近は殆どの人がWindows10になったでしょうから、区別が付く人は少ないかも知れません。

「〜」　は　波ダッシュで unicodeで言うと301C

「～」　は　全角チルダで unicodeで言うとFF5E

今でこそ見た目は殆ど同じですが、一昔前は一時的には波ダッシュの向きが逆だったりと、色々と一部の人達が騒いでいました。

因みに、一般的なキーボードの右上の方のキーに付いているのはチルダ

普通に入力する（Shift+^）と半角チルダが入力出来ます。
これは「ダイアクリティカルマーク」とか言う、文字を修飾して読み方を指定するものです。

英語で言うなら 「A」を「あ」と読むか「お」と読むか？

そう言った違いを、文字の上に書き込んでしまおうというのが「ダイアクリティカルマーク」

日本語で言うなら、「か」と「が」みたいな違いです。

で、この半角チルダは、本来は文字の上に付くのですが、昔のＰＣではそもそもそんなことが出来なかったので、次の文字として打ち込んだのでしょうかね？？

＊も含めてOSの違いにより、これらの記号の表示される位置はかなり違います。

半角チルダは、普通に上付きで表示されますし、macなんかでは*が上付きで表示されますしね、訳分からない感じですよねｗ

さて、それはそれとして、今でこそ、自由に全角チルダも波ダッシュも入力出来るようになっているというのに、いまだに全角チルダと波ダッシュを区別しようとしないところがあります。

具体的に言うとATOKです。justsystemは日本人が作った日本語を入力するための機能であるATOKにおいて全角チルダと波ダッシュを間違えています。

全角チルダを入力（漢字入力がONの状態で、チルダを入力（Shift+^）する）し、そこで変換をして、変換候補を表示させます。

すると「ATOKクラウド推測変換サービス」のその他分類（雲マーク）として、波ダッシュと記載された候補が居ます。

しかし、これで確定すると、実際に入力が確定するのは、全角チルダなのです。

ATOKは波ダッシュと偽って全角チルダを入力させているのです。



さて、これはATOKがなにか勘違いをして、こう言う状態になった訳では無いと思うのです。

まず、波ダッシュはその登場当初にunicodeが登録をミスり向きが逆さまになり、microsoftがunicode通りにWindowsのフォントを作成し、表現の違いに苦慮した日本人が全角チルダを使うことになり・・・

それでいて、当時webでは一般的なサーバーであるunix系で使われる文字コードであるeuc-jpでは全角チルダが非対応で有り、波ダッシュしか入力出来ず、

Webに上げるときは波ダッシュに変換し、windows上で使うときは全角チルダに変換したのです。

そんな相互変換をしていた所為で、長い間、全角チルダも波ダッシュもそれで良いじゃんとunicodeがなかなか正しい字体への変更を認めず、WindowsXPの時代まで全角チルダと波ダッシュはほぼ同一の物として扱われてきました。

今見てみれば分かりますが、生い立ちは全然違う物の、最終形態はほぼ同じなのです。

だから、違う向きのフォントが有った方が良いんじゃ無いの？？っていう意味合いがかなり強かったみたいです。


ただし、全角チルダが半角チルダが大きく（全角）になったものと違い、
日本語における波ダッシュは

長音記号　あぁ〜
範囲記号　１〜１０
省略記号　〜である

等、様々に使われてきた長い歴史がある無くてはならない文字。

それなのに、形が同じだからとチルダで良いと言われる訳には行かない。

まぁ、その辺りのことは解決しました。

しかし、現在において日本語入力のためのATOKで、波ダッシュを用いた変換が正常に出来ないという大問題がある訳です。

まぁ、そもそも波ダッシュを入力するキーが無いのは仕方が無いとしましょう。

でも、入力した内容に応じて変換候補を表示するのであれば、「から」の変換候補として全角チルダではなく、波ダッシュを表示すべきでは無いでしょうか？
まぁ、一応、atokは波ダッシュと表記されている候補を出すんですけどね？　これを確定すると、全角チルダが入力されるんですよ。

ようするに、ココまで来るとATOKの方が悪いと言うことになる訳です。

サーバーも、httpもdbもphpもperlもどれもこれもutf8に対応し、
utf8mbにおいてどちらも正しく入出力出来るようになっているというのに、未だに対応しないのは問題有りです。

因みに、このような内容を書いてjustsystemに要望を上げたら、波ダッシュが表現出来なかったようで、コードで表示されるという珍事が起きました。

まぁ、ようするにそう言う会社な訳です。

日本の会社なら波ダッシュに対応して下さい。

数年前からのGoogleの扇動により各種WebサーバーがSSLやらTSLに一気に対応していきました。
だから何だと言われても困るのですが？


HTTPでの通信が傍受される機会が著しく上昇したのです。

例えば、FreeWifiとかですね？

Wifiの電波は外を飛んでいるわけですから、簡単に傍受ができます。そして、Freeの場所は不特定多数がアクセス出来るようにするため、パスワードが無かったり、公開されていたりして

飛んでる電波からパケットを取り出して、それは暗号化されていなかったり、パスワードが分かっているので簡単に復号化できたり。


もし、そこで、秘匿すべきデータを含む通信をしたら簡単にばれてしまうわけです。
場所にも寄りますが？有名どころのFreeWifiのスポットでは、常に誰かがデータを取得していて、特定のキーワード等で分類した結果を売っている人が居るとまで言われていました。

そして、それは頻度の違いしか無く、実際に行われていたでしょう。
スパイの仕事も楽だったでしょうね！

まぁ、実際の所Googleがどう言う状況を想定して
「Httpsに対応していないところは検索結果に表示しない」とか言いはじめたのかは判りませんが、結果として、通信の秘匿性が高まったので良いとしましょう。

そして本題。

SSLやTSL（以降TSL）ではどうやって暗号化通信をしているのでしょうか？

それはサーバー証明書と言われる物を、信頼された機関から発行して貰い、それをサーバーに設定します。

TSLでの通信要請（正確には証明書要求）がくると、サーバーの証明書をクライアントに送信し、クライアントは、その証明書が正しいのかを判断し、正しければ、そのサーバーの公開鍵を使ってサーバーとの通信を始めることになります。

ここで言う公開鍵とは何でしょう？？？

RSAは公開鍵暗号方式と日本語では言われ、
特殊な値（桁の大きい素数と言われています）を二つ用意し、片方の素数を計算した結果を秘密鍵とし、もう片方の素数を計算した結果を公開鍵にします。

そして、この両方を用いて、何らかの方法で計算すると、

　秘密鍵を使って暗号化した物は、公開鍵でしか復号化出来ず、
逆に
　公開鍵を使って暗号化した物は、秘密鍵でしか復号化出来ない。

そういった変わった特性を持ちます。

これがRSAの基本的な仕組みです。

これは高度な数学モデルに基づいて作られたもので、素数の特性（下記）を利用したものです。

素数と言えば　2と3がわかりやすく有名ですね。

この二つを掛けた答え　2×3＝6

　この6は、元になった素数である2と3以外では割れない。

RSAの具体的な計算式は分かりませんが？

暗号前のデータを100とします。
公開鍵(2とします。)で暗号化（単純に掛けます）したけっか 200になりますね？

これをサーバー側に送り、サーバー側は受信した200を6で割り、3を掛けると100になります。
こうして、暗号化されたデータが復号化出来るわけです。

ただし、この公開鍵暗号には重大な欠点があります。

サーバーから返されるデータが 20だとします。
これを暗号化、3で割り6を掛けると、40になります。

公開鍵は2なので、この40を受信した人は 40/2=20で、だれでも復号化出来てしまうのです。

公開鍵暗号方式において、戻ってきた値というのは、

　公開鍵で復号化出来る　＝＞　正しいサーバーから送られてきたデータ

それだけでしかないのです。

まぁ、なので、あたしとしてはTLSは送られてくるデータは暗号化されていないとばかり思っていたのです。

なので、あたしが作っていたWebアプリは全て、サーバー側で暗号化してからTSLでクライアントへ送り、クライアントはこれを復号化してデータを読み取っていたのです。

ですが、こんな穴あきのRSAのままインターネットが普及しているはずが無いという考え方もあります。

そこでHTTPSのプロトコルを調べたところ、サーバーの証明書で本物か確認出来たら、暗号キーを作成して、共通鍵暗号方式で通信していました（笑

注意しなければならないのは、RSAでは、サーバー側へ送る時しか通信を秘匿出来ないのです。

なので、この暗号キーはクライアント側で作成して、サーバーに送る必要があります。

HTTPSはまずサーバー証明書でサーバーの確認をすると、サーバーから送られたキーを元にクライアント側で暗号キーを作成し、それをサーバーへ送信します。

するとそれ以降の通信は、その暗号キーで共通鍵暗号方式で通信することで、通信を解読出来ないようにしてます。

いわゆるワンタイムパスワードと同じ様な感じで、常に暗号キーが違うので、暗号文を復号化することがほぼ不可能な方式と言うことになります。

HTTPSが思ったよりも安全で良かったです。


因みに、一般的なワンタイムパスワードは、暗号生成器で、ユーザーのIDと現在の時間などから算出出来る6桁程度の数値であることが多いですね。