|
昨年の試作でICF3-Fのページに
プログラミング用のブロック図を公開しています。このブロック図ではAレジスタに
データ レジスタの値を直接入れることができないのですが、直接入れられるように修正しました。
面積の増加や、ディレイの増加なく、修正できる予定です。
これでプログラムが少し楽になったことと性能が若干、向上します。
これから実際のファイルに修正を入れるのですが、万が一、うまくいかない場合は、元に戻すこともあるかも。
人工筋弛緩で怠い状態が続き作業効率が半減の半減。(←痛みがないから頭痛よりいいと思っているらしい)
96bit÷47bitの除算と余算がシミュレーションで計算できるようになりました。
以下は、今後の予定の話。
48bit版で、いろいろな演算ができるようになれば、48bit版を21.5個つないで1032bit版にする。
そしてCRTを使ってRSA 2048bitの演算ができるようになる。
下図のようにXilinxのFPGAに並べる予定。
余裕があれば加算器に使っているDSPもモンゴメリ乗算器にして性能を2倍にしたいところ。
人工睡魔により作業効率が半減。
図をマウスでクリックすると拡大されます
約1週間ぶりの進捗。ロード命令を2cycから1cycに改善。48bit×48bitの乗算がシミュレーションで計算できるようになった。
人工頭痛で作業効率が30%に落ちている状態。
RISC-V協会とか、ウォッチしていると、オープンソースのCPUコア RISC-Vの活用例としてFPGAに実装することで信頼できるCPUを提供するということを考えているらしい。
盗聴回路や遠隔操作回路がCPUに入っていないとも限らない。FPGA上のソフトプロセッサなら、多分、大丈夫みたいな。
*** 2019年11月24日修正 結論は影響なし ***
RISC-V協会とか、ウォッチしていると、オープンソースのCPUコア RISC-Vの活用例として信頼できるCPUを提供すること。FPGAは、その開発の加速を促進することですね。
暗号プロセッサにAthena-GroupのTeraFire F5200を使った例があったのでF5200を調べてみました。Intel,Xilinx,microsemiなどのFPGAに実装できるようです。
F5200は公開鍵暗号だけでなく共通鍵暗号やハッシュが演算できるようです。とりあえずRSAの性能だけ見ました。鍵長に関係する性能特性からCPU型の暗号プロセッサかも。性能からの推定なので、ハズレている可能性はある。
XilinxのKinetix-7/Vertex-7の性能しか記載されていなかった。僕が現在、やっている暗号プロセッサICF3-FではXilinx Artix-7だから、性能値をみても、あまり正確なことはわからない。しかしSLICE数やLUT数、周波数などの数字があったので、参考にはなりました。
Athena-GroupのTeraFireはオープンソースではないようなので、RISC-V協会が目指していると思われる、信頼できるCPUを提供するには、暗号プロセッサもオープンソースでないと、いけないはずで、ICF3(1999年)のオープンソースが、利用できるようになるなら、便利なんだろうなぁと。みんなで考えると、いいのかも。
Terafire Crypto Microprocessor
ICF3-Fの開発のスピードを上げるには、頭痛を止める必要があり、
ネットをさまよいながら考えています。
高性能な暗号装置の技術を持っている僕が闇サイトにも
アクセスしているという状況ですが、
世界の銀行に収める暗号装置の開発をしたときに僕の監視体制が
整備されていると思われます。
今でも十分な監視が行われていると思います。
僕が犯罪者になってくれることを期待している人も多いのですが、
ご期待に沿えないと思います。
ネット上では、僕が「高度暗号技術」所持で逮捕されることを
心配してくださる方もあるのかな。ありがとうございます。
頭痛などのトラブルでICF3-F(SSLアクセラレータ)の開発が半年以上遅れている
のではないかと思っています。
SSLアクセラレータがあまり流行していない理由の一つは、
SSLアクセラレータを開発できる技術がある企業は、サーバーの販売を
行っているところが多く、サーバーの売り上げを下げる効果がある
SSLアクセラレータを開発するより、サーバーの販売に力を入れたほうが
いいという背景があるのではと考えます。
SSLアクセラレータを購入して得をするには、それなりにノウハウが必要で、
通販ショップに置いておけば、自然に売れるというものでもないように思っています。
サーバーシステムを構築するSEの方々が、SSLアクセラレータを
導入すると得をすると見込める計算ができる必要があるのです。
このためにはSSLアクセラレータを可能な限り、安価で提供しないと、
なかなか導入を考えてもらえないのかなと考えています。
時代の変遷によって必要なサーバーシステムの形態が変化してしまうと
SSLアクセラレータを導入して損失を発生させてしまうので。
つまり、僕が最もいいSSLアクセラレータを提供できる可能性があるということです。
ICF3の利権を持っていて、既存のFPGA基板を使えば、僕の作業だけで開発できて、
僕が社長の会社がある。サーバーシステムの形態が変化することによる
リスクを考えた、価格にできるのではと考えています。
ただし、これは、お約束するできる話ではないので、ご了承ください。
ICF3-Fの開発の進捗は、この日記でお知らせします。
この日記をはじめて読んだ方は、僕のnoteに投稿した記事が、参考になると思います。
「暗号プロセッサICF3について、その未来」
「Webサーバの性能を上げる専用ハードを開発しています」
今日、思いついたのことを書くと、PKIの認証トークンとか、機器認証とか。
小型のCPUよりは高速である必要があって、サーバー向けのアクセラレータほど高速である必要がない。
そういう用途は、思ったよりあるのかもと。
8bit CPUと8bitのI/FのついたICF3(1999年)のチップを作って、8bit CPUにパソコンの
USB通信させれば、SSHとかSoftEtherの認証に使えるものになる。
ネット上ではセキュアなデバイスが話題になりつつあるので、
オープンソースで自分で作ってしまうのも、いいかもと。
僕だと8bit CPUを自作しているので、僕だけでチップが完成しそう。
暗号ミドル(PKCS#11)も自作したものがあるし。
でもICF3-Fを急ぐので当面、やることは無理そうですが。
(1)の蛇足
ブログやSNSで情報を発信すると、競合他社の人とか、ASICの仕事を受注したい人とか、
匿名で、いろいろなことを言ってくるので、全部には反応できないのです。
企業とは製品を開発、販売して利益を得るものなのですが、そのコスト感覚がまるでない人とか。
ちょっと付き合いきれないと思うことはあります。
立場上の問題はあるにしても、もう少し考えてほしいなぁと。
製造コストの話以外の問題もあるのです。
例えば、大企業がSSLアクセラレータをASICで開発、販売する場合、
恐らく大量に販売する計画になる。本当に大量に販売されると、
サーバーの売り上げが大きく落ち込むので、サーバーの営業関係が、
本気で動くことも考えられる。
僕のような零細企業が、ちょうどいいとか。
そう思った人がいたようなので。
僕は大型コンピュータのASICを3個、開発している。
20年前のことだが、その考え方は、現在でも通用するところはあると思っています。
FPGAであれば、開発コストは僕の作業のみで、ほとんどお金がかからないという予定。
しかも自分が社長の会社を使えば、
販売コストも、あまりかからない。
SSLアクセラレータの価格を圧倒的に安く抑えることができるからです。(まだ予定の話)
ASICで開発する場合、僕に大きな不利益が発生する可能があって、
十分な利益が得られる確認が必要。確認だけで時間が費やされる問題。
今年の2月ごろ、通信用の8bit CPUにXilinxのPicoBlazeを使うつもりだったのですが
8bit CPUを自作したので、
Xilinxが提供するIPを全く使わなくても大丈夫な状態になっています。
ASICに移行することも、できるようには、考えられています。
5:50AM まだ頭痛が続いています。
ここ数日の状況からみて、1日分の作業の5%～10%しかできないと思われます。
こうなると作業を進めるより、頭痛を止める方法を考えるしかないのですが。
ICF3-FのSSLアクセラレータを開発することは変更されないと思います。
性能を向上させたICF3-Fのモンゴメリ乗算器は、約1年半前、2018年4月23日に思いついたことが
自分のブログに書かれている。
僕に失点はなく、ICF3(1999年)、ICF3-F(2018年)の発明は、
青色LEDには遠く及ばないかもしれないが、この国の役に立つと思っています。
書いているうちに7:10AMになりました。まだ頭痛は続いている。
4:50PM ずっと眠っていました。ようやく起きました。今日の日記の数行を削除しました。
先月あった
Googleの量子超越性の論文など、量子コンピュータ進展に伴い、
暗号解読の脅威が世界中で心配されるようになりました。
(Googleが迷惑なことをしてくれたというより、
僕はGoogleは多くの人に指示されてるのではと思っています)
暗号解読の脅威への準備が急務と考えています。ですのでICF3-Fを急ぎたいのです。
(一般の人はここまで)
暗号解読の問題は鍵を長くすることで、ある程度、改善されるものと思われます。
これには
大きなモンゴメリ乗算器を実装可能
な、ICF3-Fが、
とても効果的です。←これ僕以外できないと考えてください。
現在、
米アマゾンとイーサリアム財団らがFPGAコンテストで1位のサバンチ大学の剰余乗算器
「Low-Latency Modular Multiplication Algorithm - Erdinc Ozturk」
よりも優れていると思います。(レイテンシ性能では負けますが)
例えばICF3-Fでは、2048bit×8個の演算器を搭載したFPGAを、状況に応じて
4096bit×4個、8192bit×2個、16384bit×1個に変更することが技術的には可能なので、
購入したハードを買い替える必要がなく、安心できます。
仮にRSA 2048bitが解読されたという事件が起きれば、
鍵を長くすることを余儀なくされ、大型FPGAデバイスの大きな需要があるかもしれないし、ないかもしれない。
ごたごた、やっていると商機を失うと考えているのです。
24時間脳内スピーカが鳴りっぱなしが続いている。
音声主によって全身の筋肉に力が入らなくなったり、脳が痺れたり、満腹中枢を操作され、眠くなったり。
数百以上の繊細な制御をされている状況は変わらず、このため作業がほとんど進まない状況は、変わっていません。
ICF3-Fの暗号技術は、僕の言っていることが本当であれば、重要な技術のはず。
国は、この状況、とっくに知っているはずだと思うのですが。
僕が、連日耐え続け、頑張り続ける先に何があるのか。予想してみてください。
このままいけば、損失が大きいと思います。
僕が元気を失って、ICF3(1999年)、ICF3-Fが、技術移転されることはないはずで、
もしそういうことが起きたなら、誰か指摘してください。お願いします。
これで、このままいくという選択を軽く塞げたと思います。
いい方向に向かっていければと。
ICカードのハードと、ICカードリーダがあっても、SSHや、
ThunderbirdのS/MIMEで使うことはできません。
CSPやPKCS#11などの暗号ミドルウェアが必要です。
2008年に自分用ICカードを1000枚作ったときに、自分用のCSPやPKCS#11を独力で開発しています。
そして2011年にGPL/LGPLのオープンソースとして
公開しました。
これらのコードにOSSライブラリは含まれていないので商用化が可能です。
これらを新しい暗号プロセッサ向けにすることもできるでしょう。
これらのオープンソースの権限は、僕１人にあるので、
暗号プロセッサのビジネスが立ち上がれば、その後の展開に役に立つと思われます。
僕の体では、ソフトウェアの体力勝負な世界では、全く稼げないので、これからもFPGAやハード開発をしているのだと思います。
もちろん必要があればソフトウェア開発もやるのですが。
余談ですが、USBメモリをICカードにする
myuTokenは、
カーネルモードのデバイスドライバの署名の問題で64bitOSでの利用が、
使いにくいものになっているのですが、SSHやThunderbirdなどのPKCS#11だけなら、
カーネルモードを使わない方法で実装できる方法を知っているので、
またフリーウェアとして広く使えるものにバージョンアップできると思います。
NTFSやFAT32などのファイルシステムを使わない。そしてパスワードで暗号化されているので安全。
Amazon AWSのEC2へログインする用途なんかでは、便利かも。
ちょっと暇がなくてできませんが。
ICF3(1999年)は、プログラム・メモリ容量の追加とか、CPUとのI/Fの変更とか以外の改造は、
あまりできない方向を考えています。
それでは、あまりオープンでないと思った人があるようなのですが、それでも
SoCの部品として便利に使える場合が多いように思っています。
鍵長(演算器のビット幅)は無制限を考えています。ただしICF3(1999年)は鍵の長さとともに効率が緩やかに下がります。
それでも1万ビットくらいなら、あまり問題にならないかもと。
ICF3(1999年)のオープンソースをどうするかについては、多くの人が考える必要があると思っています。
何かございましたら、勝手に考えずに下記の関連する日記も読んで、ご連絡ください。
ただ今、ICF3(1999年)のオープンソース推進よりも、ICF3-Fを完成させ、
「大きなモンゴメリ乗算器は実装できるのか？」
の検証が、かなり重要なんだと考えて、急いでいます。←これ僕は他の人に頼んでいません。
関連する日記
10月27日
11月09日
11月10日
ICF3-Fの開発で技術的な問題で滞っているということはなく、
僕にとって、オモチャを組み立てるのと同じなのです。急がねば。
頭痛が酷くて、ほとんど進捗がありません。
眠らされていたり、文字の誤認識が多発するなどの脳へのいじめで作業ができない程度の頭痛ですが、
長時間続いているため、ネット上を彷徨うことに。
ICF3-Fの暗号技術は、僕の言っていることが本当であれば、重要な技術のはず。
世界の半導体の動向を知らない人は、ネットで調べて状況を確認したほうがいいです。
FAQ「ICF3の暗号プロセッサは１人でやったの？」を書きました。
「8bitパソコン時代のMSXに次世代の構想が」
「次世代MSXのファーム書換えでICF3-Zに変更でいいのか」
一昨日や昨日ほど酷い状態ではないが、遠隔操作が止まっているということはない。
遠隔操作装置は、かなり違法なもののはずで善良な市民に向けてはいけないはずなのです。
FPGAデバイスにLUT、FFなどの部品を貼り付けるPerlプログラムを書いています。
取り敢えず、並べてみたという感じで、最終版ではありません。
Eレジスタ(E)とセレクタ(S)が追加されていますが、これは演算中にバックグランドで
次のデータをセットするためのもの。
図をマウスでクリックすると拡大されます
遠隔操作で頭が痺れさせられて作業が妨害されている感じ。(←日本の凋落を憂うならこれを対策してください)
これまでもICF3-Fの作業が進む状態になると妨害動作が大きくなることが多い。
頭が痺れると、考えることがあまりできなくなるので、作業が全く進まなくなる。
なんとしてもICF3-Fを完成させようとしています。妨害の効果は傾国のリスクを高めるだけです。
進捗を書きたかったのですが、前述のように、進捗がありません。FPGAに部品を載せる台の絵を作りました。
図をマウスでクリックすると拡大されます
遠隔操作で全身筋肉痛にされたような感じで作業があまり進んでいません。(←日本の凋落を憂うならこれを対策してください)
いよいよ、LUTやFFをFPGA上に直接、貼り付けるところまで来ました。
とりあえずPerlで配置の位置を指定するXDCファイルを作成するプログラムの開発を開始。
昨年のICF3-Fでも32bit版の試作をしていたのですが、
新型のモンゴメリ乗算器を取り付けられるように修正をして、48bitのVerilogファイルを作成中です。
この新型のモンゴメリ乗算器を外して、1999年のモンゴメリ乗算器にすると、
オープンソース版のVerilogファイルができます。
ただFPGAに特化しているので、SoCに搭載するものは別途、専用に作り直したほうがいいのかも。
10月27日
11月09日
の反響があって256bitの制限では、事実上あまり商用価値がなくて、256bit+αになるのか？
という疑問を持った人があったようです。基本的に全員に向かってSNSで話すと、
競合が匿名で邪魔をしてくることがあるので、すべての反応に答えることは、ないと思います。
256bit制限については、まだあまり考えていない部分で、
超科学暴力団による嫌がらせが発生しない限りは、雑誌などに掲載されるなら、
256bit+α(αは数ビットという制限を課す)でもいいのかなとは考えています。
ちなみにICF3(1999年)は、256bit演算器でも、加算して257bitになっても、
直後に引算すると257bit-256bitが可能なので、楕円暗号のアルゴリズムによっては、
256bitの演算器で256bitの楕円暗号の演算ができてしまうかもしれない。
昨日の日記にも、少し書いていますが、20年前のASICの開発環境では、
CPUの1、2次キャッシュなどのRAMをチップ上に配置するには、
一般ゲートを配置するのとは別に専用の領域を用意しなければならず、
CPU型の暗号プロセッサを使うためには、初期の設計段階で、
レイアウトや容量を考えないといけないのかなと思うのです。
一方、ICF3では、そういったことは必要ありません。
最近の話は、知りませんが、現在でもあまり変わっていないように思ってます。
10月27日の反響があったようなので。
オープンソース化が進まない理由は、法律的なトラブルを起こしているからではありません。
このオープンソースの人気の秘密は、「僕に関する問題」の事実上の無効化作戦によるものが大きい。
一方、オープンソースとして十分なものにするのに僕が必要な物は「僕に関する問題」の解決。
このためオープンソース化が進まない。
ICF3-Fの作業が忙しくて、あまり考えられたものではいので、ここに書いたことは忘れて欲しいのですが
「僕に関する問題」が解決されるなら、256bitなどの制限をつけることもなく、
無制限に大きなbit長のオープンソースにしようかと。ただし1999年版は鍵長の長さに応じて、
緩やかに効率が下がります。それでも1万ビットとか、いけるのかも。
基本的にSoCに搭載して便利に使えることのみを考えていて、改造についてはI/Fのみ。
暗号プロセッサと演算器の周波数比や、プログラムメモリの容量などの改造は、できないと便利に使えないので有。
でも「僕に関する問題」は大きいので。
オープンソース化を段階的にやると「僕に関する問題」解決が難しくなると考えていて、
まずは256bitまでというような最小限の解放で、様子を見るのが、いいのかもと思っているところなのです。
小型のFPGAデバイスに実装して試せるようなHDL(Verilog)ファイルの雑誌による公開など。
例えば演算器を256bit幅に限定すると、アルゴリズムによっては254bitまでの楕円暗号しかできないため、
事実上、商用利用しにくく、僕の方での解放はしやすい。
最初に考えるべきは、ICF3とCPU型との比較で、ICF3(1999年)に、
どのくらいのメリットがあるかの価値を考えることから。
ICF3の性能特性は鍵長に比例します。256bitのように短い鍵長では性能が出ません。
ただCPU型と比較して面積が小さい可能性はあります。
また半導体のメモリ用に用意された領域を必要としないので、SoCを実装してみたら、
余ったところに、予定外に入れてしまえるなどのメリットはあるかもしれません。
製造に関するところは、僕も得意ではないので、なんとも言えませんが。
神話から奇稲田(Kusinada)も、いいかと思ったのですが、意味深過ぎるので、
スネークキューブ(Snake Cube)に仮決めしておこうかと。
作業するファイルを整理するのに名前がないと困ったので、
急いで名前を考えることにしたのですが、半日かかってしまった。
スネークキューブは、ルービックキューブが大流行した時代に、
24個の直角二等辺三角のブロックをつなげたパズルのことで、
ICF3-Fは一列に並んだ演算ブロックを蛇のように蛇行させてCHIP上に配置させていることに由来します。
巨大な整数の各桁は、一列に並んだ演算ブロックに一列に並べられて演算されます。
最下位のブロックで1を加算しても、その影響は最上位のブロックにまで影響するため、
何も工夫をしなければ、整数が大きくなればなるほど、1回の演算(加算など)にかかる
時間が長くなってしまって、効率が悪化していきます。
そこで、まるでパズルを解いたかのような方法で演算させることで、
どんなに整数が大きくなっても、ほぼ効率を保つことをICF3-Fはやっています。
1回演算するたびにnビット右シフトする動作が入るため、各演算ブロックで
桁あふれがないことを証明することが必要でした。
僕のブログで証明しています。(見飽きている人も大勢いらっしゃると思いますが)
モンゴメリ乗算の累積加算における分割加算の証明
また文字が読みにくくなって辛いのです。
ICF3-FとICF3と区別がつかないのでICF3-Fの名前を考えようかと。
GoogleのTitanは土星の衛星からきているのかと思い、土星の衛星で良さそうな名前を探してみた。
タイタンは土星の衛星の中で１番大きいのですが４番目にディオーネがあったので、そこから
ブルー・ディオーネ(Blue Dione)
にしようと、一度は、決めたが、商売する気がないのかと思われるのも良くないと考え直した。
惑星や衛星の名前はギリシャ神話やローマ神話からきているものが多い。
ということで日本神話から
奇稲田(Kusinada)
あたりがいいかなぁ。
Googleは米国時間11月5日、OpenTitan
を公開したようです。専用のCPUを使ってハードウェアのファームなどの検証をするやつみたいです。
以下は、僕が、この記事を読んだ感想です。
CPUにlowRISCが開発した
「Ibex」を使うみたいです。
小型のRISC-Vです。乗算命令は、高速版と低速版があり、高速版には17bitの乗算器を使うもののようです。
OpenTitanが想定する用途で高速な公開鍵暗号が必要な場合、Ibexでは性能が不足する場合があるのかも。
2048bitのRSA署名を数ミリ秒から数十ミリ秒で演算したいなどの用途があれば、
OpenICF3を考えることができるのかも。
オープンソースにしている1999年のICF3と、クローズドなICF3-Fがありますが、
ICF3(1999年)でも、Ibexよりは、かなり高速に演算できると思います。
OpenTitanに限らず、ICF3(1999年)をIbexのI/Fに接続するというような案はあるのかも。
問題は、まだRTLのファイルを作成していないことと、ライセンスをどうするかということ。
Ibexよりもトランジスタ数を減らしたICF3-V
の計画をもう一度考えると設計をOpenICF3に集約できるか。
8bitで良ければICF3-ZのVerilogは作成されている。
もう一つ、問題が。税金を使うとイジメられるので、やらない。
税金を使うと僕が大損する状況があって、それを改善できると、かなり違う。
はてなブログに投稿しました - 暗号計算機屋のブログ
https://icf.hatenablog.com/entry/2019/11/06/210448
2スレッド版のモンゴメリ乗算器を暗号プロセッサに接着するための修正作業。
DSP数だけで言えば、1000円くらい安い
Cmod S7
に実装できる可能性が出てきました。LUT数が不足して無理かも。
相変わらず眠らされている時間が長く作業ペースが上がらない。
RSA暗号は秘密鍵の値によって電流や演算時間が変動する。
そこから秘密鍵が漏洩するため対策する必要があります。サイドチャネル攻撃対策と言います。
ネット上で電気通信大学の崎山一男先生の解説記事(2008年)が見つかったので紹介します。
暗号への脅威「サイドチャネル攻撃」とその対策
解説記事を読む必要はなく、言いたいことは
1999年のICF3はサイドチャネル攻撃対策を論文より３年早く製品化していた
解説記事によれば2002年の論文に「Montgomery Powering Ladder」があり、サイドチャネル攻撃対策のための
アルゴリズムが書かれています。ICカードで有名なGemplus(現 Gemalto)の文字列が筆者の中にあるようです。
その対策が1999年のICF3でも、されていた。ICF3ではモンゴメリ乗算器２個を使って並列動作させる方法なので、
アルゴリズム的には違うのだと思います。
そして、このICF3のアルゴリズム。電気工学科卒の僕が有限体を知らない状態で
モンゴメリ乗算のアルゴリズムをFAXで受け取り、
２日で考えてしまったものなのです。
サイドチャネル攻撃対策を意識していたわけではなかったのですが、幸運でした。
「Montgomery Powering Ladder」以前の論文に、同様なものがある可能性もあるので、
日記のタイトルは、やや釣りかもしれないですけど。
ちなみに崎山先生も僕と同時期に日立にいたのですが、事業部が違ったので、全くお話したことはありません。
ICF3-Fのモンゴメリ乗算器のDSPのマイクロコードを開発中。Verilogシミュレーションで動作を確認しながら開発。
XilinxのDSPはシミュレーション用の高速ライブライがあって、かなり高速に動作する。
高速Verilogシミュレータ「Verilator」も興味はあるが、当面は使わないだろう。
眠気を増大させられている感じ。平常の25%の作業スピードといったところ。問題と思う。
ICF3-FはSSLアクセラレータです。ネット上の過去の記事で、SSLアクセラレータの、わかりやすい説明があったので紹介。
1999年のICF3は1024bitのRSA暗号を1回、3.448[ms]の時間で演算できて世界一でした。
2003年ごろ、自分のお金でアイルランドのSSLアクセラレータのAEP1000Lを13万円くらいで買いました。写真は数年前、デジカメで撮ったもの。
AEP1000Lは1秒間に1000回の1024bit RSA暗号ができることが書かれていました。
一度に多数のRSAの演算をさせると1秒間に1000回近い性能がでましたが、1回だけ演算させると約20[ms]の結果でした。
次の記事は、AEP1000LとかSSLアクセラレータについて、わかりやすく説明がされています。
SSLやWebを手軽に速くアクセラレータの中身と効きめ(1)
図をマウスでクリックすると拡大されます
ちなみに、これ、１年前くらいにCentOS 3.9で動作することを確認できました。
保証できる話ではないですが、これが僕、個人で開発できる見通しなのです。
「Webサーバの性能を上げる専用ハードを開発しています」
仮に完成して、品質保証する必要がなければ、僕の作業のみでいいので、税金を引っ張り出す必要がない。
僕が健康でありさえすればいいという話。
いつ頃できるのか、僕の日記を読めば、予想できると思いますが、原価1万円くらいのFPGAにUSBでサーバーに接続できるような「SSLアクセラレータ」を作っています。小さいのであまり役に立たないかも。
しかし、これができると、量子コンピュータの解読脅威によって、httpsなどの公開鍵暗号の鍵を、いきなり大きくしなければ、ならなくなった場合でも対応できる。
量子コンピュータの解読脅威によって、公開鍵暗号のハードに投資できる人はあまりない状況で、昔からやっている僕くらいしか、できそうな人がいない。CPUでも演算できるので、CPUでもいいのですが。
サバンチ大の超高速ハードもありますが、商業をいろいろ考えるなら、僕のICF3-Fがいいと思っています。
SSLアクセラレータで公開鍵暗号のRSAを演算させて、バグで計算結果を間違うと、どうなるか？という話。
実際のアプリケーションで、どうなるのかは、わからないけど、ほぼ技術的な予測による結論でいいように思ってます。
RSA暗号は準同型暗号という性質をもっているため、必ず、ハッシュを含めて暗号化します。なので、ハッシュを確認すれば、バグったかどうか、わかる。
RSA署名は、httpsなんかだど、本物のサイトであるにも、かかわらず、ニセサイトとブラウザに表示されるのだと思うけど、動作検証していれば、例えバグがあっても、滅多に演算結果を間違うことはないし、ニセサイトと表示されるくらいなら、被害はゼロとか、あっても軽微なもの。
業界ではSSLアクセラレータは、サーバー製品の中では、あまり品質が気にならない製品という認識と考えています。
ICF3-FをXilinxのFPGAに実装する作業をしています。
モンゴメリ乗算器として使うDSPを制御するプロセッサがverilogシミュレーションで動き出した。
昨年の試作のほうが、プログラムの内容を見て分散RAM(LUT-RAM)の容量を減らす仕組みを実装して高度な技術で作られていた。
しかし試作の結果、LUTの方が不足して、BRAMに余裕があることから、BRAMで作り直しました。
BRAMのマクロを使うと、少し簡単に実装できるのですがECCのエラー訂正機能が使えないので、
マクロを使わずに作ったのだが、
設定によってアドレスがズレることに気づくのに半日かかったかも。
頭痛攻撃は止んでいない。痛み自体は、あまり酷くはないが作業スピードはかなり落ちる。
頭痛攻撃に悩まされながら開発を続けています。
そのためブログの性能比較にさける時間が不足して計算間違いをしていました。
https://icf.hatenablog.com/entry/2019/08/12/230403
いや、ICF3-Fは、レイテンシ性能こそ圧倒的に負けましたが、面積効率は余裕だろうと
思っていたからかもしれません。
ICF3-Fの演算器で1024bitのA×B mod Nを演算するのに必要なDSP数は88個(44×2)ではなくて44個。
この44個のDSPでリダクションもしています。
一方、サバンチ大学の剰余乗算器は、DSP数 4225個＋リダクション用の巨大なLUTです。
周波数を考えないといけないのですが、同じぐらいの周波数であれば、
サバンチ大学の剰余乗算器は100倍以上、性能が良くなければ面積効率が悪いだろうと予測できます。
サーバーCPUに接続するためには、ICF3-Fは暗号プロセッサが必須なので、それを考慮する必要があります。
サバンチ大学の剰余乗算器も、CPUに直結すれば、サーバーCPUの性能を借りて
RSA暗号演算していることになる。またCPUの脆弱性の問題を考えるなら、結局、暗号プロセッサが必要だと思われます。
暗号プロセッサとしてARMやRISC-Vを使えば、ICF3-Fと同様に面積効率は悪くなる。
プロセッサの面積についての評価は、簡単に見積もるのは難しいので、実際に実装してみるしかないように思っています。
ICF3-Fの暗号プロセッサは、僕が利権を持っているので、僕が開発をすると完全にタダなのです。
サバンチ大学の剰余乗算器でも、ARMつきのFPGAも、多く製品としてあるので、それらが使えるかも(全然、わからない)
おまけ。上記は論文の128bit、256bit、512bitの結果からの予測。
コンテストではA×B mod NではなくA×A mod NなのでDSP数は半分近くで済む。
そしてA×A mod Nを8cycで演算している。DSP内のレジスタを使ってパイプラインをして、
DSP数を４分の一くらいにしているのかもしれない。つまり530個くらい。
A×B mod Nでも8cycにしてDSPを複数回利用することは可能。乗算部分の効率は、上がるのかもしれないが、
LUTのリダクションの効率は上がらないような気がしています。
なので100倍未満の性能でも、サバンチ大学の剰余乗算器のほうが面積効率がいいということもあり得る。
ただA×A mod Nの評価を、A×B mod Nに使うのは、やはり配線数、遅延の考慮が足りてないとも考えます。
これは僕が大学４年生のときの話です。これはゲームです。単なる余興話です。
ICF3-Fは、鍵長の大きなRSA暗号が得意です。
RSA暗号解読について調べるとNTTの青木 和麻呂さんが、
有名なようです。共通鍵暗号Camelliaの開発者としても有名な方だということは知っていたのですが、
まさか、思ったのでした。
それは、学生時代、友人ということではなかったのですが、僕の方が大学で学年が１年上だったので、
「単位を取るのに楽勝な科目、何かありますか？」とか、聞かれたことがあったのです。
東大卒が作ったソフトウェアの会社でバイトをしていたのですが、そこで、知り合ったのです。
ある時、「ハゲタカのえじき」(ドイツ生まれのカードゲーム)を、
プレイヤーの代わりにC言語のプログラムで戦わせるイベントがあったのです。
青木さんも、参加していたと思いますが、僕のプログラムが優勝しました。
図をマウスでクリックすると拡大されます
アマゾンFPGAコンテストで紹介されている論文
に「Low-Latency Modular Multiplication Algorithm - Erdinc Ozturk」(サバンチ大学の剰余乗算)の結果が2週間以上前に発表されていたようです。
FPGAの配線数の不足や、遅延によって思ったほどの性能がでないことを期待していましたが、いい性能が出ているようです。
信じたくありませんが。8月に論文の解析をしたときはA×B mod Nを1cycで演算する仮定をしていましたが、コンテストでは8cycで実装したようです。
このことで解析結果に大きな影響はないように思っています。
コンテストの結果から推測できるサバンチ大学の剰余乗算の性能は良いようですが、bit長(鍵長)が長くなれば、実装しにくくなっていくことや、
効率が低下してコスト面の問題が出てくる傾向であることに違いはないように思っています。
SSLアクセラレータの用途ではレイテンシ性能よりも効率によるコストが重要です。また複数の証明書に対応するためにはmod Nを入れ替える機能が必要です。
mod N固定のサバンチ大学の剰余乗算の演算器でRSA暗号をするには、演算器が２個必要で、FPGAボードだけで100万円を超えそうです。
ICF3-Fは、鍵長が長くなっても効率がほとんど下がらない特長があります。また鍵長が長くなればCPUより、かなり高速に演算できます。
量子コンピュータの解読脅威によって鍵長を長くする必要があることもあるように思います。
したがってICF3-Fが、かなり有利だと考えています。
1999年のICF3の256bit版を作ると小型のFPGAに入る。
そしてRISC-VやARMのSoCに接続するオープンソースとして価値はあるのかも。
CPUを改良した暗号プロセッサと比較して実装面積が小さいと価値はあるのかも。
基板にセキュリティチップを追加するより、1チップにいれたほうが、
最終的にはコストダウンになるだろうし、I2Cバスとか、数本のバスでは、
出せない性能がでるだろうし。楕円暗号を実装する場合、
1999年のICF3の512ワードのメモリでは、恐らく不足する。
命令セットは512ワードまでしか利用できないが、768ワードに拡張して
追加した256ワードに楕円のスカラ倍のようなコード量の多いサブルーチンを
実装すれば、512ワードしかアクセスできない命令セットでも、バンク切り替えなどの
特別な機能を追加しなくても768ワードのメモリを使いきれる。
厳密には256bitではなくて、数ビット追加が必要。
モンゴメリ乗算のアルゴリズムの最後にある引き算を不要にする改良型モンゴメリ乗算を使う場合、
さらに2bitの追加が必要になります。Design Wave MagagineのRSA暗号コンテスト(2008年)が参考になるかも。
参考の参考ですが、僕のブログにちょっと書いてあります。
nhira型モンゴメリ乗算アルゴリズム
2019年10月28日追記 もし興味がある方があれば先行して走る前に僕に話をしてください。
税金が絡む話は、ほとんど無理と思ってますが。
2019年10月23日に公開され話題になっているようです。
論文の内容についてや、ブラウザでインターネットにアクセスするときに使われる公開鍵暗号(RSA暗号)や、
ビットコインで使われる公開鍵暗号(ECDSA)などへの影響について言うことはできないのですが
僕が昨年、発明したICF3-Fは、鍵長の大きな公開鍵暗号を計算するのに向いているので、
注目を集める技術になっているのではと思っています。技術検証を急いでますが、
予定通りの結論になるように思っています。
その技術を、ちょっと説明した３か月前(2019年8月)のブログがあるので、再掲します。
このブログの説明にkとk+1の間に中継FFを入れて大きなモンゴメリ乗算器が実装できる仕組みがあるのですが、
昨年の試作で、k=1つまり、1番目のDSPと2番目のDSPに中継FFを入れて、中継動作が正しく動作することを検証しているので、
技術検証といっても、再確認に近いレベルと思っています。
https://icf.hatenablog.com/entry/2019/08/12/230403
通常、大規模なLSI設計ではレイアウトから、設計にフィードバックする工程があるのですが、
1999年のICF3は、LSIの２次元平面上に配置することや、演算器だけでなく
システム全体のクリティカルパスのディレイを考えた設計を僕がしています。
この結果、レイアウトからのフィードバックなく、製品化されています。
厳密な話をすれば、レイアウトから設計にフィードバックするところを、
ほんの小さな問題だけしかなかったので、レイアウト部署で修正して製品化したということです。
修正内容は、大型演算器を、最下位ビットから最上位ビットまで、
先頭から順番に並べていくわけですが、レイアウト部署からの提案で、
最上位ビットを中心に近づけたようなドーナツ状に修正しますと連絡がありました。
僕も、研究者と、あまり変わらないような環境で設計していた。
レイアウトからのフィードバックを受けるということは、
半導体製造装置の投資の貢献度が上がることを意味します。
そういったことを考えると半導体デバイスの研究開発では、会社の投資の貢献度が、大きいものとなります。
LSI設計はデバイスの研究開発ほどではありませんが、レイアウトからフィードバックされると、
会社の貢献度が上がります。
つまりICF3のアーキテクチャの発明の貢献度は、設計者の僕が非常に大きいということです。
現在ではXilinxのFPGAの開発環境の普及によって、一般の設計者が、レイアウトも
自分でやることが可能になっているようです。
(今後、締め出されることに、ならないといいのですが)
論理ゲートを、好きな位置に配置できる優秀なGUIツールがあります。
でもICF3のように単純な論理を大量にリピートするアーキテクチャでは、
Perl(最近の人はPythonでしょうか)でレイアウト情報を生成することができると思っています。
実際、昨年の試作はPerlでVerilogを生成しています。レイアウト情報までは生成しませんでしたが。
インドの論文(1)の続き。
この論文にはXilinxのFPGAに32bitの実装をして性能を測定した結果があります。
一方、ICF3(1999年)は、
1999年12月に製品出荷され、世界の銀行などに売れたもの。
論文レベルの実装では、実際に製品実装してみると役に立たないこともある。
ICF3は1024bitの本番実装をしています。
1024bitの実装をして最下位ビットからのブロッドキャストのディレイ(Delay)のほうが
問題であることがわかっています。
つまり32bitのディレイ評価では、間違いということになることすらある。
確か、ICF3のリーダー小国氏(東大卒)の研究報告書の中で、僕の名前で
最下位ビットからのブロッドキャストのディレイを書いたような記憶が。
日立内部では「研報」と呼ばれているもの。
僕がICF3を1999年という早い時期に製品化できたのは、日立の決断によるものではある。
日立のシステム開発研究所から僕に送られてきたモンゴメリ乗算のFAXは、英語で書かれた
参考書からの22ページの抜き取りで、RSAを演算する計算式が抜けている不完全な資料だった。
それを僕が、RSA演算できるように、計算式を考え出した。
スパコン製品ならともかく、銀行で使うような大型コンピュータで使われるとなると、
気が引けていた。
ICF3でモンゴメリ乗算を採用するか否かを決断する日の期限が迫ったので、
僕はICF3でモンゴメリ乗算を採用するのは見送りましょうと意見していた。
ちなみに僕は電気工学科卒なので大学で暗号を学んでいなくて、
僕に才能がなければ、短時間に理解して実装できる状態にすることは
できなかったと思っています。
ICF3-Fは、この最下位ビットからのブロッドキャストのディレイ(Delay)の
問題を改善し、とても大きな整数でも演算できるようになっています。
Paillier暗号は加法準同型性を満たす方式です。
ICF3-Fは、大きな数の剰余乗算(modular multiplication)が得意です。Paillier暗号に向いています。
なんか、プログラムまで暗号化されたまま動作するCPUとか、作っている人いるみたい。
(採択された人は、全員、京大みたいだけど)
https://anqou.net/poc/2019/10/18/post-3106/
ちょっとだけGitHubを覗いたのですが、完全準同型暗号の
TFHE
(Fast Fully Homomorphic Encryption over the Torus)の記述が見つかりました。
オープンソースのライブラリのようです。完全準同型暗号は、ブートストラップによって、現実的になっているようです。
数か月前、ICF3-F(←1999年のICF3とは違う)の初号機での実装はされない予定だが、
演算器のビット幅の2倍のモンゴメリ乗算を可能にする設計を考えました。
そのときRSA doublerと命名しましたが、RSA暗号に限らず計算できる技術です。
論文で使われるような名前に変更することにします。
double-size montgomery multiplier of ICF3-F
日立製作所 システム開発研究所に非常に紛らわしい技術があるのですが、全く異なるものです。
コプロセッサの2倍のビット長をもつモンゴメリ乗算
(Double-Size Montgomery Multiplication of a Crypto-Coprocessor)
RSAのビット長2倍化技術
日立の技術は海外の改良型のようです。
日立の技術は演算器で「余」と「商」を計算する必要があります。そして数学的なアルゴリズムで２倍を達成します。
ICF3-Fは演算器で「余」しか計算しません。ハードアーキテクチャで２倍を達成する技術です。ICF3-Fのほうが高効率です。
インドの論文(2016年)
にICF3(1999年)とほぼ同じ内容のものが
そしてICF3(1999年)が参照されていない！
日本の科学技術が霧散しているということなんだろうか。
僅かに違う点は
ICF3はY+Mを毎回計算しているが、インドはY+Mを事前計算していること。
そのために鍵長と同じビットサイズのレジスタが必要。FPGAに実装しているみたいだから、
いいのかもしれないが、ASICだとレジスタのほうが重いような、、、
頭痛は軽度には、なっていて、ICF3-Fの作業は少し進んでいます。
昨年、分散メモリをプログラムメモリとしたDSP48E1をコアとしたプロセッサを作っています。
その分散メモリをBRAMに置き換える作業。半分以上はできたような気がします。
頭痛が酷い。強力な眠気が含まれる。
(脳直結回線で)「おまえの開発するICF3-Fの品質は悪いだろうから、
大手メーカーに任せて、おまえは餓死しろ」というようなこと言ってきたので、
とっておきの話をします。2006年頃の話になります。
日立製作所のICカードリーダ HX-520UJ.JのWindows用のデバイス・ドライバ(PC/SC)は
複数のアプリケーションで同時にアクセスすると、デバイス・ドライバがエラーを返すため
アプリケーションが動作しないというバグがありました。日立製作所ですから、当然、
国税や政府関係の電子申請で使われているICカード・リーダでした。
にもかかわらず、このバグは１年以上、放置されていたと思います。
放置できた理由は、複数のアプリケーションで使うような
使い方をしないことを決めていたからだと思いますが、かなり劣悪な品質と言えます。
他のメーカーのICカードリーダ(NTTコミュニケーションズ、アテナスマートカード、ジェムアルト)の
ドライバ(PC/SC)では、そういったバグは見られませんでした。
そして何より、僕が開発したUSBメモリ用のICカードリーダのドライバ(PC/SC)でも、
複数アプリケーションでアクセスしても正常に動作します。
僕が開発したPC/SCドライバのほうが大手メーカーのPC/SCドライバより品質が
良かったということです。良く見ると日立製作所のICカードリーダの箱には中国製って書いてある。
図をマウスでクリックすると拡大されます
頭痛が酷い。強力な眠気が含まれる。作業を進めることを中断し、いろいろと考えている。
ICF3-Fモンゴメリ乗算器設計図 Rev0.4
←これをどこかに密輸すれば金になると考えた人がいたのだろうか。
この演算器は、暗号プロセッサ(大型汎用四則演算器)にある大型加算器がないと、公開鍵暗号を演算できない。
米アマゾンの
FPGAコンテスト
の参考文献にあるサバンチ大学の方式は、大型加算器がなくても演算可能。
だからCPU直結ができるのですが、近年のIntel CPU脆弱性のような問題を対策するため、
結局、サバンチ大学方式でもCPUのようなプロセッサを挟む必要があるのでICF3-Fの大型加算器のコストが問題にならないのです。
そしてICF3-Fの演算器も、暗号プロセッサ(大型汎用四則演算器、1999年のICF3のこと)も、
僕に利権があるため、僕が開発すれば安価ということなのです。
公開鍵暗号の演算はCPUで計算しても、かなり高速に計算できてしまうため、
暗号プロセッサ(大型汎用四則演算器)を使ったものは、これまでICF3以外に見たことがない。
そのため暗号プロセッサ(大型汎用四則演算器)の大型加算器が必要な
モンゴメリ乗算器(ハード)もあまり存在しないはず。
モンゴメリを使ったハードで世の中に普及しているものには、リダクションのみのものが多いです。
良く注意してみてください。ICF3-Fは乗算が含まれたモンゴメリ乗算器です。
進捗ほぼゼロ。OpenICF3プロジェクトのなかでICF3-Fだけ、
プロジェクト開始時からクローズドとしてやってきていますが、
詳細な設計図を公開しています。
これ→
ICF3-Fモンゴメリ乗算器設計図 Rev0.4
独創性があるのか、確認できると思います。
DSPをプロセッサのように動作させるマイクロコードは公開していませんが、
実際にシミュレーションして動作確認済みです。
なぜか、ある動画関係のコミュニティにいるのですが、数年前、
そこで僕が1998年に会社の研究所からFAXで送られてきたモンゴメリ乗算の資料と同じものが、
公開されているという情報を得ました。
そこでわかったことは、1999年のICF3で使ったモンゴメリ乗算の公式と、
情報を教えてくれた人が示したモンゴメリ乗算の公式と違ったということ。
ICF3(1999年)は乗算が含まれる公式を使っていましたが、彼の示す公式はリダクションのみの公式。
乗算はCPUを使って演算できるので、ICF3(1999年)のように乗算を含むと無駄が生じる。
だからリダクションのみの公式のものが、知られていたのかもしれない。
ICF3はCPUの助けを借りずに公開鍵暗号を演算するため乗算を含んでいます。
ICF3-Fの演算器は暗号プロセッサに接続されることを要求するので、
暗号プロセッサと合わせて考える必要があります。
米アマゾンのFPGAコンテスト
の参考文献にあるサバンチ大学の方式はCPUに直結することが可能ですが、最近の需要は、性能だけでなく
秘密鍵の秘匿のほうが重要になっているので、なんらかCPUのようなプロセッサを挟む必要があると思います。
進捗ほぼゼロ。気分が優れないのでMMD動画を見たり、ネット上の記事を読んでいるが、
また日本語が読めなくなっている。ゆっくり何度も繰り返しながら読めば、なんとかなるが、
偏差値でいうと20とか30くらいになるのだろう。
頭痛じゃないけど遠隔操作による頭痛発生装置が動いていることがわかる。なんとか止めたい。
「ＬＧディスプレイが韓国国内のディスプレー・パネル工場
で使用するフッ化水素全量を国産化した」というニュースが、、、。
半導体技術って結構、重要なんだよなと。
米アマゾンのFPGAコンテスト
の参考文献にあるサバンチ大学の方式は、とても高速に公開鍵暗号を演算できる。
しかし、量子コンピュータの進歩により公開鍵暗号を解読されてしまう心配から、少しでも安全性を考え、
鍵長を長くすると、サバンチ大学の方法では、1チップに入らなくなり、実装が急激に困難になる。
仮に実装できても、乗算器１個あたりの効率は低下していく。
RSA暗号をCPUで計算した場合、おおよそ鍵長が２倍になると計算時間は8倍になります。
ICF3-Fは、設計上は、鍵長を２倍にして２倍の演算器を投入することで、計算時間４倍です。
鍵を大きくしていっても鍵長２倍で計算時間４倍のまま、ほとんど効率は低下しない。
つまり鍵長が大きくなるとCPUより、かなり高速に演算できる方式で、
半導体の重要技術と考えることができて、それなりに多くの人が注目しているはずなんだと思うのです。
ほとんど関係ない話ですが、ぼっーとネット上の記事を読んていると
『英国の「救国の英雄」スピットファイア戦闘機が名古屋に飛来』
というのが。第二次大戦時の戦闘機なのですが、好きな人っているのですよね。
戦果のある善良な市民である僕に、とてつもなく酷いことをしたことが漏洩するのを隠すために、
ほんの一部の人間の利益を守るために、国が危うくなっているような気がします。
進捗ゼロです。noteを書くのに
使われた時間も多いですが、頭痛が続いていることが進捗がゼロである理由。
世界の銀行などに良く売れた暗号LSI ICF3(1999年)は、東大卒の方がいっぱいいる部署で僕が開発しています。
科学の進歩で遠隔操作によって脳破壊、呼吸を止めるとか、特別な手術なしにできる可能性。
現在、頭痛が続いていること。トラブル発生確率が異常であること。
これくらいで、何が起きているのか、多くの人がわかるような気がしています。
必要悪の使い方を間違っていると思っています。
ちなみに呼吸を止められた経験が、10年くらい前にあります。
人生で一番、あせった瞬間でした。呼吸が止まって、数十秒が経過、あと数十秒で気絶して死ぬとか考えていました。
水中で、どのくらい息を止めていられるかというのが基準でした。
数十秒後、まだ呼吸は止まったまま。小さいセキをしていたように思います。
呼吸が完全に止まっていても、多少は肺から酸素が取りこめたのでしょう。
どのくらい呼吸が止まっていたのか、時間はわかりませんが、呼吸が再び、動き出して、一命を取りとめました。
とくに病院に行かなければならないほど、酸欠には、ならなかったです。
進捗ゼロです。頭痛が続いています。連日の頭痛に困り果てて、半日考えこみました。
進捗ゼロです。note
の投稿記事の作成に4時間くらい使っていますが、それ以外の時間は頭痛で動けませんでした。
XilinxのFPGAのDSP、DSP48E1をCPUのように制御するアセンブラの開発を始めました。
微妙にDSP48E1のコンフィグが異なるCPU(DSP48E1)をアセンブラによるプログラムで制御する。
ほとんど眠っていました。苦痛を伴うことがなくなったが、思い出せないことが、多くなっている。
落ちついてはいるが、失われた記憶の量が、かなり多いことが否めない。
頭痛で辛い日々。時々、強い痛みで寝込むこともありますが、痛みより思考能力の低下が問題かも。
←これ役に立つ人があると思って書いているのです。いい説明を思いついた。
ここ数か月、数日前に何をやっていたのか、全く思い出せない。
ゆっくり苦痛に耐えながら思い出す動作をする必要がある。
あるいは、この日記を見て手っ取り早く、思い出すことにするなど。
僕が設計・開発のほとんどをしたICF3(1999年)は、作業工数の少ない「基数2(低基数)」のモンゴメリ乗算で実装されています。
当時、高基数のほうが演算器の効率が高いと考えられていたため、僕が退職した時点(2005年)では、
ICF3は旧式と認識されていたと思います。僕自身も、そういう認識でしたが、
高基数は、効率のいい演算器を制御するために効率が悪くなる点もありました。
昨年(2018年)、低基数のモンゴメリ乗算の改良を思いつき、今年(2019年)になって、さらに性能が上がる設計ができました。
このICF3-Fは、
とても大きな整数の四則演算(剰余つき)を高速に演算できる演算器です。
RSAに限らず、応用範囲の広いものなので、このアーキテクチャが世界で長く使われるかもしれません。
ICF3-FのアーキテクチャはASICでなくてもFPGAでも効率的に実装できます。
つまり、小さな国のソフトウェア会社が、いきなり海賊版の製品発表をしてしまうことを恐れています。
確認してください。ICF3-Fは、僕しか開発できないのです。
ICF3-Fの共同発明者を名乗る人が、僕以外にいたりするのでしょうか？
頭痛で、ごたごたやっていると、霧散してしまうかもしれないのです。
頭痛を止めないと問題です。頭痛制御装置はデジタルではありません。
軽く能力低下をされていても、さらなるICF3-Fの改良に影響がでます。
頭痛をゼロにする必要があるように思います。
1999年のICF3に限らず、ICF3-F以外のプロジェクトは、
オープンソースハードです。あまりルールを明確にできていないところはありますが。
「RSA暗号の秘密鍵をTLBの挙動から推測できる」の引用元を明記してなかったので補足します。
これです。
良くは読んでませんが、解の範囲を３分の一にするとか、
そういうものではなくもっと正確に秘密鍵を求めるものだと思います。
さっき日記を書いた直後、また頭痛で寝込んでいました。どうにか、ならないものだろうか。
おまけです。
ICF3-Fが最重要で最優先なのですが、今年の3月ごろ勢いでICF3をベースにした8bit CPU、
ICF3-Zを作ってFPGAで動作するまでになりました。
廉価な32bit CPUよりも8bitのICF3-Zがかなり高速に演算できるパターンがあることを見つけました。
A/Dで12bitのデータを取得して、4bitの乗数(1倍や16倍含む)で乗算をして8bitの値で割算をすること。
センサー制御系については詳しくないのですが、大雑把にICF3-Zが10倍以上高速で、面積が5分の一。
つまり面積性能50倍のような性能を活かせるものがあればなぁーと、ちょっと思った。それだけです。
SNSでも騒いでいたことがありますが16bit÷8bitが17サイクルで演算できるというやつです。
日本株が下がらないように気を配りながら考えてみるとか。
ICF3-Fは2スレッド化や演算器の2倍のモンゴメリ乗算を演算できる改良が進んで、
CPUと同じチップ上に搭載することも考えられるようになったかもと思っています。
重要です。
CPUの脆弱性の研究者によればRSA暗号の秘密鍵をTLBの挙動から推測できる
などの脆弱性もあり、暗号プロセッサによる根本的な対策が重要性を増しているように思います。
RISC-Vの実装が、あちこちで進んでいるようですが、様々な脆弱性に対応するよりは
暗号プロセッサがいいのかもと考えいます。
もう一度、いいますが1999年のICF3の
暗号プロセッサの設計・開発(製造のためのファイル作成)のほとんどを僕がやっています。
会社を退職するときにICF3が旧式になっていることもあって、ICF3を貰うことしにしたのです。
そして正式な打ち合わせにより正しく成立しているのです。
僕が派生を許可したところはありませんから、僕の作業停滞が及ぼす影響を考えて欲しいのです。
また今日も故障。パソコンに接続しているスピーカから突然、ピッーっと音が発生。
壊れたようなので分解、ヒューズが切れたのかと思いテスターでヒューズを調べても切れていない。
外見に異常は見られない。9VのACアダプターの電圧を調べると13Vあったので、
9VのACアダプターに交換しましたが現象かわらず。
連日の故障。僕が、故意にやっているのではないかと思う人がいるかもしれない。
僕が故意にしているということはなく連日の故障で時間を取られたり、出費もかさんで大変。
おまけに頭痛が完全に治っているのかといえば、そういうこともなく今日の昼から夕方まで寝ていました。
また今日も故障。パソコンの電源を入れると異音がしたためPCケースを開けるとケースファンがホコリで音を発生させていた。
CPUファンも、だいぶ劣化していたのでCPUファンを交換。
この部屋にいて10年以上たって、わかったことだが、どうも部屋がホコリっぽくてファンの故障が通常より多い。
ようやく2週間ぶりにICF3-Fの作業を再会。
しかし「フォルダを比較するソフト」のバグを見つけてしまったので、バグ対策に時間が費やされた。
データを別のHDDにコピーをした直後ではOSがコピーした内容をキャッシュしてしまっていて、
キャッシュとコンペアをしたところでHDDに正しく書けたことを確認できないことに気づいてしまった。対策は完了しました。
ちなみにHDDに正しく書く込みが成功してもHDDから読み出すとエラーだったという障害は経験がある。
また今日も故障。PCIのネットワークカードが認識されなくなり、別のPCIカードに交換。
もしかしてハードが壊れたわけではなくてソフトウエア的に認識されないような細工をされただけなのかもしれない。
図をマウスでクリックすると拡大されます
ここ３か月、トラブルが異常に続いています。ICF3-Fの作業が妨害されているのかもしれません。
ここ数日、頭痛などの体調不良はあまり見られない。変わってパソコン関係の障害が多発しているという状況。
某、有名通販ショップのギフト券、１万円分が行方不明になって、その捜索と、「同件不良対策」に時間を取られました。
このような状況でありますがICF3-Fを完成させるべく作業を進めていきたいと思います。
HDD故障やUSB接続が切れる事故が多発しています。
このためICF3-Fの作業を中断して「フォルダを比較するソフト」を自作しています。
ソースコードを練り直しました。これから様々な環境で動作検証をします。
非同期I/Oで動作するので、物理的に違うドライブのフォルダを比較すると、高速です。
でもオープンソースとして公開するほど、規模の大きなソフトでもないなぁと思っています。
新品のAMD Ryzen 5 2600が搭載される新品のマザーボードで、
マザーボードに直結されるUSB 4個が同時に切断される現象が起きました。
もう１件、SATA接続のHDDがシーク音を発生させながら、パソコンがフリーズしました。
こちらはマザーボードもHDDも8年以上前だと思われるので本当に故障かも。
10年前に購入したWindows7のパソコンがフリーズした。
HDDの問題だろうとHDDを調べると不良セクタが38個見つかった。
38個全部、修復されたみたいで、安心しているが、時間は過ぎていくのが辛い。
HDDはIDEの古いやつだから、いつ壊れても不思議ではないの状況では、ありました。
図をマウスでクリックすると拡大されます
メインのパソコンが接続しているルーターが上位のルーターのハブになっている。
どういう設定にすればWAN接続を含めたハブになるのか、わからないが、サイバー攻撃により、
ルーターの設定が書き換えられたものと推定。
メインのパソコンがDMZゾーンに、さらされていたのだが、
メインのパソコンの設定がパブリックネットワークになっているので、恐らく被害はない。
このサイバー攻撃の狙いは直接被害を出すことではなく、偽装工作ではないかと、思われます。
ここ数日、サイバー攻撃でUSB接続が切れる問題が多発しています。
そこに、このニュースが入ると、インターネットからの不正アクセスで、USB接続が切れたのだろうと、考える人は多いでしょう。
しかし僕は、ネットワークから切り離されたパソコンで多発しているのを知っている。
だから、USB接続が切れる問題と、ルーター書き換えのサイバー攻撃との関係は無いと考えている。
したがって日記には、ルーターがサイバー攻撃にあったとしか、書かない。
一方、日記を読む人は、インターネットからの不正アクセスで、USB接続が切れたのだろうと認識してしまう。
このようにして偽装工作が成功するはずだったのでしょう。
ネットワークから切り離されたスタンドアロンのパソコンでも、USB接続が切れる問題が多発させることができることを偽装したかったのではないだろうか。
WindowsXP以降で動作するソフトウェア。
Microsoftが公開しているfcivの機能拡張版です。
オープンソースにしている暇はないので作ったという話だけ。
作った目的はUSB接続を切るサイバー攻撃によりファイルが壊れたりしていないかの確認のため。
Microsoftのfcivには2つのフォルダを比較する機能はないが、フォルダを比較する機能が拡張されている。
他にもfcivにはできないSHA-256やSHA-512が追加されている。
WindowsでSHA-256を計算できて信用できるフリーソフトがなくて困ることが多かったため。
作ったソフトは、ファイル暗号ソフトToraToraのコードをテンプレートに改修しています。
当時、ファイル暗号ソフトの中には、ファイルを消失させてしまう
バグを持ったものがあったのですが、ToraToraは、きちんと検出できる機能を持っていた。
「窓の杜」に、そういう自慢をしてToraToraを自推しましたが、通りませんでしたが。
Vectorは自推して通りました。
これです。
バージョンアップでレビューの内容は古くなってますけど。
サイバー攻撃がなければ、ソフト開発で、ここ数日を無駄にすることはなかったのです。
|
