|
頭痛で作業できずChromium OSのビルドを始めた。痛みで脳が正常動作していない。
8bit CPU ICF3-Zが、どのくらいの面積か
確認してみたい。
そういう人のためにボード Artyでの手順を
ダウンロードのページに追加しました。
今日は筋肉痛で動きが鈍っていました。
昨日は目を開けているのに真っ暗、いやほとんど見えているのだが、そんな感覚に悩まされた。
昨日の日記の補足。
8bit CPU ICF3-Zが
高速な8051互換(FPGA用IP)の2倍高速と書いたのは同じXilinxのArtix-7の実装でICF3-Zのほうが
2倍の周波数だったこと。運よく8051互換チップのCPI(Clock per Instruction)が書かれていて1.5～1.8であった。
ICF3-Zは加減算、論理演算であれば、同程度のCPIが出そうだと思ったので、2倍高速と書いた。
ただICF3-Zは加算器1個のアーキテクチャなので乗除算は、多少遅い。
しかし乗算の乗数が小さい場合は少ないサイクル数で演算できたり、
8051ではできない16bit÷8bitが可能だ。
ICF3-ZにはLOOP命令というものがあって2サイクルのディレイスロットをもつ特殊な命令だが
加減算とは条件付きで同時実行可能。つまり1サイクルで同時に2命令が実行できる。
LOOP命令はループで使われるため実行頻度が多く性能に影響する。
アセンブラで、こういった最適化をすれば、「2倍高速」になるかもしれない。
8bit CPU ICF3-Zと8bit CPUのIntel 8051との比較です。
正しくはIntel 8051の互換チップとの比較で、互換チップには高速なものから面積最小のもの様々ある。
カタログスペックからの予測なので間違っている可能性はあるかもしれないが、
同じクロックならオリジナルの8051より27倍、高速なものもあるがICF3-Zは、それよりさらに2倍高速かもしれない。
そして面積最小化を目標にしているlight52の半分の面積なのです。
IoT用途として期待されますが、制御用途では8bit CPUも多く使われているようです。
ICF3-Zは面積最小化した8051の半分の面積しかないのに、高性能な8051の2倍の性能。
技術革新と言えないだろうか。これくらい、あれば、ICF3-Zをゆるいオープンソースライセンス(Apache License 2.0)にすれば、
世界中の8bit CPUがICF3-Zになっていくことが、ないだろうか。
そこに、うまいビジネスは生れてくれる気がしている。
頭痛が続いて脳が壊れていく感じ。僕の頭が壊れていくと、うまくいくはずのものが、
うまくいかなくなるように思うのです。
頭痛を止めるほうが、いいと思えないだろうか。
8bit CPU ICF3-Zは、
全てを僕がゼロから設計したものです。
新規に追加した圧縮命令が他人の特許を侵害していないか、念入りに調査中。
昨日は頭の痺れで、ほとんど動けずベッドで横になっていました。
数日前までは脳内の文字認識系の動作が不安定でしたが、昨日は文字認識は回復、意味解析部がほぼ停止。
特許などの文章が、ほとんど読めない状況になっていました。
今日は、記憶にダメージがあることが何度も検出され、やれやれと思っているところ。
通常0.5秒で思い出されるはずの物が、思い出せず、数十秒かけて思い出す作業が必要。
連日の頭痛で、今もなお思考能力低下が著しく、思考速度にいたっては20分の一くらいに低下。
回復はするが、思考能力は通常の70%くらいか、思考速度は10%くらい。
思考速度が遅くなったことでアニメを見ても、速度が追い付かず、人生の楽しみを失った。
もっと回復しても少なくとも十分には、楽しめない。
今日はARMの時事問題や、ICF3の僕の功績についての検証が議題のようだ。
前述のとおり、万が一、頭が本格的に壊れると、ICF3の開発秘話の真実が消える。
そう思ったので急遽、問題となったところの記憶を、ここに記す。
1996年ごろ米国サンノゼにあるAMD本社の正門前にあるホテルに３ヶ月間、IBM互換機の
製品出荷のため滞在した。帰国後、暗号LSI ICF1(1997年)のリーダーとして僕は仕事を始めた。
米国滞在中にIBMの暗号LSIについて研修を受けていたのではないかという疑問を
持った人はいるかもしれない。全くそういうことはない。
帰国直前に、次の仕事は暗号LSIだと言われて、帰国しただけです。
滞在中の仕事は、ほぼ日本人スタッフルームで控えているだけでした。
ICF1(1997年)を出荷した後、ICF2(1998年)がスタート、僕がリーダーだったような
気がしますが、東大卒の小国氏が途中から参加、主にMulti2暗号や、RSA暗号の
実装のための検討を、いっしょにやりました。
小国氏は僕より4年くらい上なので実際の検討作業のほとんどを僕が担当しています。
大型加算器の検討を小国氏自身がやった事実が残っていますが例外的なこと。
同時期に僕の方でも検討していました。
ICF2のときもRSA暗号を実装できないか、検討していたのです。
しかし期限に間に合わずRSA抜きでICF2の実装作業に入りました。
僕が、この会社に入ったのはCPUを作りたかったからでした。
自宅で、こっそりSHA-1の論理を作っていました。
僕の論理設計のHELLO WORLDです。これがICF3のときに使われIBMの5倍の性能になったという伝説。
会社では雑用が多かったですが、論理設計をしたいという熱意が冷めず、
自費でVHDLのシミュレータを20万7900円で購入。(領収書の画像が文章の最後にあります)
しかし長時間残業のため、ほとんど購入したVHDLを使うことはありませんでした。
その頃、会社ではMulti2暗号の実装検討が、はじまりました。
恐らく、既に他でMulti2暗号をハード実装した製品があったと思います。
小国氏から仕様と、ともに作り方のポイントを享受しました。
Carry Save Adderのことで、実は加算器の初歩の初歩のFull Adderと同じです。
その使い方を、ちょっとうまくやると、大きな加算器のキャリーを非常に短くする効果を得られるのです。
魔法であるかのように小国氏に説明をされたので、思わず、魔法なのかと思って、その場で
C言語でシミュレーションして魔法の確認をしてしまいました。
魔法のように説明されなければ、すぐに理解できたと思っています。
乗算器の実装ではお馴染みのテクニックで、
当時の「トランジスタの技術」にも掲載されていたと思います。
それでもFull AdderがCarry Save Adderの効果を持つのは昔は発明だったのだろう思います。
そしてMulti2の高速化実装の検討を開始、これ以上無理ですと、小国氏に報告すると、
もっとやれと返事が返ってきたのです。
一見、正しくないと思われるローテーション加算の証明をしてみると、正しいことが
証明できてしまったのです。この発明は特許化され、僕の貢献率が5%ということでしたが、
本当に発明したのは僕です。この特許は地デジのチューナーで使えたはずなので、会社が、
かなり儲かった可能性ありと思っています。しかし特許手当として6000円くらいしか、
僕には入ってきませんでした。
儲けに貢献したのは、僕の発明力よりも、会社の政治力と思ったのでおとなしくしていますが、
今の僕の現状を考えるなら、問題かもしれない。
ICF2(1998年)の製品出荷が終わり、ICF3(1999年)がスタートしました。
リーダーが正式に小国氏になって、僕はRSA演算器(剰余演算器)の担当になりました。
ICF2のときと同様、期限が迫り、モンゴメリ乗算を採用するか否か僕は考えていました。
モンゴメリ乗算を使ってRSA暗号の演算ができるようになっていましたが、
いま一つと思い、モンゴメリ乗算の採用を見送ろうと思っていました。
これがスパコンなら悩む必要はなかったのです。
大型コンピュータの暗号装置では銀行などで使われたりするので、
モンゴメリ乗算のアルゴリズムの誤用で、万が一でも間違いを起こすと、大惨事になるからです。
僕が卒業した大学の電気工学科に暗号の授業は全くありません。
大学１年の頃の数学に整数論がありました。四則演算が閉じるとか、閉じないとかの説明を覚えています。
1988年のことですが、ICF3の検討をしていたのは1998年ですから10年前の授業を数学者でもないのに、思い出せていた。
モンゴメリ乗算のR^(-1)が、普通の整数や実数の-1乗と同じなのか、きちんと理解できていなければならないのです。
このあたりが、才能で、このおかげで、いきなり仕事で必要なところだけ勉強して事業に貢献できる仕事ができるのかも。
SONYのプレステで楕円暗号の乱数に固定値を使って失敗したニュースがあったような気がしますが、
才能があれば、いきなり楕円暗号を勉強しても、失敗する「確率」は少ないのかもしれないと思います。
そしてICF3にモンゴメリ乗算を採用するか否かの期限まで、あと数日というタイミングで
小国氏にモンゴメリ乗算の演算器は通常の加算とは違ってCarry Save Adderの効果を
得られないという誤った結果を持って、モンゴメリ乗算の採用は見送りましょうと提案しました。
ところが、モンゴメリ乗算器においてもCarry Save Adderの効果を得られるという情報を、
得ていたらしく、その場で、僕の誤った結果を否定して、モンゴメリ乗算の採用を決断したのです。
僕のほうの言い分になりますが、期限が迫っていなければ、
Carry Save Adderの効果を得られないという誤った結果を持って行くことはなかった。
Carry Save Adderの効果が得られないか？と考えながら探索しているわけですから、
最初、誤った結果になっても、他をいろいろ探したはずだからです。
ただし小国氏が、モンゴメリ乗算のR^(-1)が、
普通の整数や実数の-1乗と同じだと思い込んでいた、あるいは、
それを知らずに決断していたことも付け加えておきます。
2019年12月25日 10:20AM 追記
ちなみにICF3-F(2018年)では、
Carry Save Adderは使っていません。モンゴメリ乗算器を全部、取り換えました。
Carry Save Adderの効果に相当する部分は、
僕の発明
「モンゴメリ乗算の累積加算における分割加算の証明」によって置き換えられています。
2019年12月25日 5:25PM 追記
12月12日の日記の繰り返しになりますが、
モンゴメリ乗算器の採用が決まったところで、リーダーの小国氏は、
IBMのCPUとのI/Fの設計に移行し、僕は「プロセッサ」の設計に入りました。
誰からも、何もアドバイスされることなく、快適な環境で１人で設計を完成させました。
OpenICF3のサイトでは「プロセッサ」の
設計図を公開しているので、
独自なプロセッサだということが確認できます。
そして退職時に正式な打ち合わせをして会社から正しくICF3を持ち出しています。
2018年にモンゴメリ乗算器を全部取り換えた
ICF3-Fを発明しました。
つまり、ICF3-Fは、小国氏の承認した部分すらない、完全な僕の設計で、従来プロセッサからも、
うるさく言われることもない、ものになっています。
また8bit CPUのICF3-Zも、
モンゴメリ乗算器をはずしているので、ICF3-Zについても同様です。
CQ出版の領収書の画像、インターリンクの文字がなくなっているような気がする、、、
パソコンにウィルスが入って改ざんされたのだろうか。相変わらず証拠隠滅能力が高い。
8bit CPU ICF3-Zのverilogファイルを数日前、
githubのほうにアップロードしましたが、少し修正しました。
30個以上のテストベンチがPerlスクリプト1個を起動するだけで全部、実行できるようになりました。
githubからICF3-Z Zeviosをダウンロードして、テストベンチが動作すれば、あとは、
それを参照して、自分に必要な修正ができると思います。
頭の痺れで丸１日以上、何もできませんでした。
今朝は眠れなくなるくらい歯が痛み、朝起きて歯医者の予約をしました。
しかし歯の痛みは、なぜか治ったので狙い撃ちできるようです。
痛みに耐えることはできても、失われた時間は取り戻すことができません。
このままの状態が続くと、どうなっていくのでしょうか？
2010年あたりの広島大学の論文の話です。
RSA暗号の演算をXilinxのFPGAに実装して、その乗算器(DSP)の利用率が100％に近い値
であることを実証したようです。論文がIEEEなどに掲載されているようです。
乗算器の利用率100％が理論限界かどうかは、わかりませんが、
それに近いであろうと考えることはできるかもしれない。
ICF3-Fのモンゴメリ乗算器の乗算器(DSP)の利用率は、どのくらいかというと、
現在、製品化しようとしている物は、75％くらいになると思います。
この数字はスレッド数を上げると100%に近づきます。
製品化しようとしているものは2スレッドです。
RSA暗号の演算の並列度は4ですから4スレッドで演算できます。
つまりRSA暗号の演算に限っていえば、ICF3-Fのモンゴメリ乗算器は
利用率100%に近い数字がでる予想です。
ただスレッド数を上げるとRSA暗号のように並列度のある暗号アルゴリズムでないと性能がでない問題がでてきますが。
広島大学はDSP 1個(あるいは数個)で演算する方式なのでレイテンシ性能が悪く、
今後、RSA暗号の鍵長が長くなれば、使えるケースが減っていきます。
ICF3-Fは鍵長に比例したDSPを使って並列に計算させても、利用率100%に近い数字が
出るという極めて優れた方式です。広島大学の数十倍～数百倍の性能になると思われます。
並列計算機をやっている人は、良くご存知だと思いますが、8個のプロセッサを使って
1個のプロセッサの1.5倍とか、そういうことは良くあります。
ICF3-Fは、8個のプロセッサを使って約8倍の性能が出るというような話なのです。
2019年12月22日 7:00PM 追加
ICF3-Fの周波数について説明が抜けたため指摘がありました。
広島大学の論文では400MHzを超えるデータもあるようですが、
実際にはCRTを使う必要があるので325MHz程度のようです。
ICF3-Fが目標としている周波数は285MHz。
広島大学は１世代前のプロセスですが、
高性能クラスのFPGAデバイス(システム性能２倍)です。
デバイス差があまり明瞭ではないので、なんとも言えないですが、
少しICF3-Fが遅いのかもしれません。
利用率が100%近い値だというのが、もう少し下がるということなのかも。
それを考慮しても、優れた並列計算性能であることに問題はないように思います。
2004年の琉球大学の論文
「並列加算を用いた高速モンゴメリ乗算器の設計」の概要を読むと、普通の人は、
僕のICF3-Fのモンゴメリ乗算器と同じものかと疑われそうなので、説明します。
概要には並列加算について「2回の加算を並列に行う」と書かれています。
僕の並列加算は巨大整数を分割して並列に加算することです。
同じ並列加算ですが内容が全く異なります。
もう一つ、この論文の概要の最後に「従来のWMM乗算器の遅延時間を約63%削減できることがわかった.」
とあります。この数字、前提条件がありません。
僕のモンゴメリ乗算器の場合、巨大整数の桁数に応じて、削減量が変化するため、
この点からも、琉球大の論文と僕のモンゴメリ乗算器が全く異なるものだとわかると思います。
別の判定方法としてCarry Save Adderというキーワードが論文に入っていれば、
僕のモンゴメリ乗算器とは異なると考えられます。
Carry Save AdderはICF3(1999年)では使っていますが、ICF3-Fでは使っていません。
IEEEなんかにもdynamic instruction set computerとか慶應大学のWASMIIとか動的再構成するハードの研究があります。
ICF3-Zは再構成可能な機能ユニットは存在しません。
圧縮命令の実装実体は特殊な分岐命令なので問題ないと思います。
2010年ごろ日立製作所 中央研究所でFPGAを使ったSSLアクセラレータを開発していたようです。
僕も1994年4月～1995年1月まで日立製作所 中央研究所の超高速プロセッサ部に所属していましたが、
僕が現在、開発しているICF3-F(SSLアクセラレータ)とは全く関係ありません。
海外の特許を調査、ICF3-Zの圧縮命令が特許侵害を疑われそうな特許を見つけました。
韓国の特許「構成可能機能ユニットを含むプロセッサを使用してコンピュータープログラムを行う方法、
プロセッサ及びコンピューター判読可能記録媒体」
ICF3-Zは再構成可能な機能ユニットは存在しません。
圧縮命令の実装実体は特殊な分岐命令なので問題ないと思います。
年末年始、休まず作業予定。
8bit CPU ICF3-Zは来年1月15日に、
Apache License 2.0として公開予定で、現在準備中です。
XilinxのFPGAに実装したverilogファイルをgithubにアップロードしました。
これまで限定公開したバージョンとほどんど違いはありませんが、
不要なファイルを削除したので、これまでより読みやすくなっていると思います。
Xilinx依存な記述はないのでverilogが使えるシステムなら、使えると思います。
ICF3-Zのオリジナル実装をZeviosと命名しました。
名前の由来は、アーケード版ゲーム XEVIOUS(1983年)のデッドコピーXEVIOSの頭文字XをZにしたもの。
XEVIOUSはBASICマガジンに連載されるなど当時、大人気でした。
CPUは8bitのZ80が3個、使われているそうです。
僕が1999年に設計・開発し、世界の銀行などに売れた暗号LSI ICF3。
この影響かもしれないが、日本の特許にはICF3のモンゴメリ乗算器の改良型が、
大手メーカー(含む早稲田大学)で特許にされているようです。
これらの改良型はブースの乗算アルゴリズムを使っています。
僕が2018年に発明したICF3-Fのモンゴメリ乗算器は、これらの特許よりも性能がいい。
面積を小さくする目的では、ブースを使った改良型のほうが、いい場合があるかもしれないですが。
つまり、この分野では僕が日本で一番、頭がいい、ということのように思った。
しかし、連日の頭痛で、劣化が進んでいる。
遠隔頭痛装置を止めないと、問題ということには、ならないのだろうか。
昨日は、失明の前兆が現れている。
1999年のICF3、2018年のICF3-F、２度あった。２度あることは３度あると思えないだろうか。
特許を調べているとマイクロソフトの高速RSA署名検証の特許を見つけた。
ソフトウェアのアルゴリズムで、100%の正しさはないが、計算量が10分の一以下になるようなことが書かれている。
つまり量子コンピュータの解読脅威のためにRSAや楕円の鍵長を長くするのだが、スマホでの検証の性能や電池に問題が生じる。
元々、RSAのほうが楕円よりも検証コストが小さいのだが、マイクロソフトの特許によって、
RSAが有利になるのではないかという予感。
マイクロコード関連の特許を調査、ICF3-Zの圧縮命令に影響するのではないかと
疑われそうなインテル特許を見つけた。
「命令エミュレーションプロセッサ、方法、およびシステム」
ICF3-Zの圧縮命令は、命令をエミュレーションするものではない。
エミュレーション論理は存在せず、圧縮命令を解釈するにも、ICF3-Zのアーキテクチャが前提になっている。
ICF3-Zのアーキテクチャに適合しないエミュレーションはできない。
2000年ごろの日立製作所(現ルネサス)が特許申請して拒絶された２件と、一見、酷似している。
1件は内容を読むとICF3-Zの圧縮命令と、すぐに異なることがわかるが、
もう一見は精読しないとICF3-Zの圧縮命令と異なることがわからない。
ICF3-Zの圧縮命令は、後方互換性のための機能ではないため、実装が全く異なる。
もっと単純な実装方法で、実現されていることである。
8bit CPU ICF3-ZをApache Licenseとして公開するため特許を調査した。
メモリ効率を上げるためプログラムコードを圧縮して、それを伸長する回路などの特許がいくつかみつかった。
ICF3-Zの圧縮命令は16bitの命令コードを使ってメモリ効率を上げるものでプログラムコードを圧縮しているわけではない。
インテルの特許「ミドルウェアとしてのプラットフォーム独立のＩＳＡエミュレータ」が危ないと思ったが、
ICF3-Zの圧縮命令はISAエミュレータではなく、ICF3-Zの圧縮命令というICF3-ZのISAなのです。
先日、ICF3-Zを公開した後、ネットの反応を見ていると「後方互換の機能があっていいね。」というのがありました。
ついつい誘導されて、ICF3-Zには後方互換性の機能がありますとか言うと、ISAエミュレータだと勘違いされて、
インテル特許でICF3-Zを抑えられてしまうところだった。ネット上は、工作員いっぱいだと感じた。
今年も休まず営業していると思います。
昨年、10年ぶりくらいにOB会に参加したのですが、ある先輩に学生の頃と風貌が
変わったといわれましたが、全然、学生の頃と変わっていません。お気軽にお声掛けください。
以下、OB会とは関係ない話になります。
Chromium OSのQEMU版だけですがR76,R77,R78を公開しました。
これからICF3-Fの開発作業に戻るわけですがFPGAの実機で性能が測定できるように急ぎます。
12月11日の日記に20年前、社会人しながら大学の先生の
講義を受けた話をしていますが、期間がICF3の開発期間と重なっていたので、あれっと思ったのです。
LSIを製造するためのファイルを送付した後なので、重なっていても時間的には受講できるかもしれない。
しかし僕は製品のマイクロコード開発もしていたので、銀行に収める暗号装置のマイクロコード開発中に
外部の人と接触していたのかという感じです。残業も多くて、とても勉強時間なかったろうし。
当時のホテルの領収書を調べて確認しました。
一泊二日なのですが、連日の残業で疲れているので、受講日１日目の朝の早起きに耐えられず、
前日の夜に移動してホテルに宿泊しています。
自費です。偉くなるからと思って油断しないほうがいいです。
領収書をスキャンした画像を13枚、アップロードします。→ホテルの領収書(全部ではないかも)
僕も暗号プロセッサを開発して、日本では大きなメーカーを退職して、新会社を設立しているので、
GIGAZINEの記事を読んでみました。
「Appleが退職後に新企業を設立して
58億円を調達したiPhoneやiPadプロセッサの元開発者を訴える」
この記事にあるAppleが訴えていることの中に、僕にあてはまるものがあるのかというと、全くないです。
この機会に、少しだけ暗号LSI ICF3(1999年)の「プロセッサ」について説明します。
RSA暗号はプロセッサ＋モンゴメリ乗算器で構成されます。
僕はICF1(1997年)のリーダーを担当して、ICF2(1998年)もリーダーだったように思いますが、
途中から東大卒の小国氏が参入しました。そしてICF3のリーダーは小国氏が担当となりました。
僕はRSA暗号の演算器(剰余演算器)の設計担当になっています。
ICF3は、まだ新しかったモンゴメリ乗算のアルゴリズムを、どうやってASICに実装するのか、
あれこれ僕が考え、東大卒の小国氏が承認する形式で、設計が進められました。
僕のほうは、ICF1、ICF2を経て仕事にも慣れていたので、小国氏に、
それほど指導していただくことはありませんでした。
僕はICF3でモンゴメリ乗算器を採用するのは、やめましょうと進言したのですが、
小国氏の判断により、モンゴメリ乗算器が採用されたことは大きな事実です。
そしてモンゴメリ乗算器の設計案が決まったところで、リーダーの小国氏は、
IBMのCPUとのI/Fの設計に移行し、僕は「プロセッサ」の設計に入りました。
誰からも、何もアドバイスされることなく、快適な環境で１人で設計を完成させました。
OpenICF3のサイトでは「プロセッサ」の
設計図を公開しているので、
独自なプロセッサだということが確認できます。
そして退職時に正式な打ち合わせをして会社から正しくICF3を持ち出しています。
2018年にモンゴメリ乗算器を全部取り換えた
ICF3-Fを発明しました。
つまり、ICF3-Fは、小国氏の承認した部分すらない、完全な僕の設計で、従来プロセッサからも、
うるさく言われることもない、ものになっています。
また8bit CPUのICF3-Zも、
モンゴメリ乗算器をはずしているので、ICF3-Zについても同様です。
20年前の話です。
大型コンピュータを開発している事業部の同期で、この研修に参加したのは、僕だけだと思う。
ざっと30人に1人の確率。話では、各事業部から幹部候補生が集まるところらしい。
僕は、ICF3の開発者として、受講生や、大学の先生たちにも知られていたようです。
早稲田大学の村岡先生や、慶應大学の天野先生など有名な先生の講義が多かったと思います。
2週間に1度、東京に集まり一泊二日で講義を受けるコースでした。
受講生によっては、真面目に勉強をしてくる人もあったようですが、
僕は仕事を休ませてもらってなかったので、ロクに勉強もせずに受講していたので、それなりの結果でしたけど。
欠席があまりなければ、全員、修了できるみたいでした。
図をマウスでクリックすると拡大されます
僕のブログ
「大きなモンゴメリ乗算器は実装できるのか？」の最後の行に書いた
ICF3-Fの「鍵長２倍で計算時間４倍」が理論のように見えてくるのかも。
というのが論文の要点になるのではないだろうかと思っています。
この法則は、僕の考えたアーキテクチャを前提とした法則ではあるものの、
少なくとも、この性能が出るという下限値を正確に予測できる。
システムを設計するうえで役に立つことだと思っています。
鍵長を長くしても演算器の周波数が全く下がらず、効率がほとんど落ちない
アーキテクチャの発明も要点だと思っていますが。
早くICF3-Fの作業を進めたいのですが、人工頭痛に耐えながらの作業中。
今も、両目を開けることができず、片目をつぶって、これを書いています。
自分で言わないと、良くない予想しかしてくれない人が大勢いて、自分で言うのですが、
僕は、修士卒なのです。研究室の同期の修士卒は6名、その中で成績１番で研究室に入っています。
博士課程に進学した人は、いません。
ちなみに２つ上の学年は3名、博士課程に進学、1つ上は１名博士課程に進学。
一つ下は、正確な数字は知らないのですが、少なくとも１名は博士課程に進学しているという状況。
自分で論文が書けないか、ちょっと考えているところです。
もう少しでR76、R77、R78の3っつをCanalビルドのサイトで公開予定です。
ICF3-Fを進めたいのですが、軽度ですが人工頭痛が止まらず、
Chromium OSの独自ビルドをやっています。
数年前に亡くなった叔父、元国会議員だったのですが、コンビニの経営戦略
について語っていたことがありました。敵のコンビニ店を両側から、
挟み撃ちにして、潰すということだった。
(自) (敵)
-------------------------------------
道路
-------------------------------------
(自)
左から来る人は(敵)より近い(自)のコンビニ店に入ることが多い。
右から来る人も(敵)より近い(自)のコンビニ店に入ることが多い。
(敵)のコンビニ店は、非常に少ない範囲の客しか来ないということが、
先にわかり、１店舗しかなければ倒産が自明になる。
こういったきコンビニが複数店舗あれば、全店を潰すほどの資本がない
ことが先にわかり、倒産を免れる。
Chromium OSの独自ビルドも、そういうことなのです。
XilinxのFPGAへの実装を急いでいます。
昨年の試作には論理演算の機能がなかったのですが、面積の増加や、
ディレイの増加なくORを追加できそうなので、やってみました。
暗号プロセッサとモンゴメリ乗算器の配線をして、暗号プロセッサから
モンゴメリ乗算器のマイクロコードを起動できるように作業中です。
人工頭痛が最も問題で、これだけで作業効率が半減しています。
昨年の試作で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アクセラレータは、サーバー製品の中では、あまり品質が気にならない製品という認識と考えています。
|
