Home
2018年
2019年

5月24日 CRC32回路と自作CPUの接続テスト

Xilinxの8bit CPU PicoBlazeでは正常に動作していたものが自作CPUにCRC32回路を接続すると計算が合わない。 頭がフラフラして、思考能力が著しく低下しているので原因を究明に時間がかかったが、どうにか正常に動作した。
CPUのオープンソースの公開を保留にしたことで、足を引っ張れるネタがなくなったせいか、再び、頭が辛い。 強力な電波妨害の人体への影響が懸念される。作業が遅れることによる問題は解消されていないはず。 仮に僕の発明 がRSA延命に役立ちインターネットのインフラに大きく影響するものだとしましょう。 他国に追い抜かれて、沈む損害を考えているのか心配です。


5月24日 眠気と目まいで作業が進んでいません

ICF3-Fの製品化まで僕1人の作業でできるという見通しが、眠気と目まいが起きる原因なんだろうなと


5月24日 プロジェクトの状況表示を作ってみた

このサイトのOpenICF3のページのトップにプロジェクトの 状態を記述するようにしてみました。


5月24日 アセンブラをバージョンアップ

自作8bit CPUのICF3-ZWZeta、Verilogやアセンブラなどの開発環境の公開は停止中ですが、 アセンブラをバージョンアップをしました。定数のdefineができるようになりました。 技術的な問題で公開停止しているわけではありません。 CPU開発への風当たりが強いので公開しても、イジメにあって、得にもならないことが問題なのです。 ICF3-Zは、産業スパイが盗みだしている可能性があります。誰にも許可をしていません。 WZetaも、誰にも許可をしていません。もし、日立関係以外で、ご興味があれば、ご連絡ください。 ICF3-Z、WZetaは税金の引き出しに使われたくないと考えています。


5月23日 乗除算器のないCPUの乗除算性能

ARM Cortex-M0は乗算器(32サイクル)がオプションになっている。 性能が必要なケースでは、このオプションは必須になるため、ICF3-Vとの性能差は小さくなる。 参考までの話ですが、乗算器無しで乗算をした場合の性能について僕が XilinxのMicroBlazeで調べたものがあるのですがARMでも当てはまります。
XilinxのプロセッサMicroBlazeの乗算性能
除算、正しくは余算。除算性能が必ず余算性能にはならず、余算性能が落ちるものもある。 除算を除算器無しでソフトウェアでやる場合も上記のQiitaの投稿と同じで、結構、性能が落ちます。
ICF3-Vでは加算器1個で、1サイクル/ビットの除算(余算)性能なので、余算が多い暗号アルゴリズムでは、 ICF3-Vが有利。 これをソフトウェアでやった場合、乗算と同じで恐らく5倍以上性能が落ちる。

Cortex-M0(乗算器オプション無し)で、暗号アルゴリズムが、乗算、除算がほとんどの場合、 ICF3-Vは、同じ加算器1個なのに、5倍以上の性能になる。 剰余演算に特化した効率的なアーキテクチャというのを覚えてもらえればと。


5月23日 IoTゲートウェイ経由のIoTデバイス

IoTゲートウェイ経由ではIoTデバイスは公開鍵暗号などの重たい処理をIoTゲートウェイに任せることができる。 IoTデバイスを可能な限りARM Cortex-M0のような軽量なCPUを使ってIoTシステムの原価を下げたい。 と僕が勝手に思っている。 次世代暗号で鍵交換をしてAES暗号で認証をするシステムはあるような気がします。 とてつもない数のIoTデバイスでICF3-Vが使えることがあるのかもと。 税金プロジェクトかもしれないが、たとえば自動車の信号機が、ICF3-Vで将来的にコスト削減につながるなど。 採算が取れる見通しがあれば、いいという考え方はないだろうか。 例えばICF3-Vが5倍速いアーキテクチャだとして、1人が1か月くらいで開発できるアセンブラがあれば、 IoTゲートウェイと通信する程度のソフトウェアの開発ができてしまう。 実際にやってみると5倍が3倍になって、1か月が3年くらいになって、赤字という可能性は多そうですが。


ICF3-Vを作るなら、いっしょにICF3を搭載してIoTゲートウェイを経由しない直接接続というのもあるのかな。 ICF3-Vでインターネットと接続するのは、少し苦労するのかもしれないですが。 ワンチップでRSAと楕円に対応するデバイスが可能になる。 楕円しか対応していないものが既に存在していますが、これだと楕円が先に解読されても、RSAがあるとか。 何事も、採算を考えて。


5月22日 ICF3-Vが次世代暗号に適していたら?

とある有名ジャーナリストのSNSに誘導され、「ARMがHuaweiとの取引停止、BBCが報道。」のニュースを知りました。
一瞬、「ARMがHI〇〇MAとの取引停止、BBCが報道。」のように読めて血の気が引きました。
でも、技術的な話だけは、しておこうかと思います。
SSLアクセラレータICF3-Fの開発で忙しく次世代暗号について勉強する時間がないことは 最初に、ご了承いただくことにして、先日の日記にも書いていますが、最近の国立大学の研究で、 ARMの最も下のクラスのCortex-M0で次世代暗号が、どのくらいの性能になるのか調べる研究がありました。 概要しか読んでいないので、詳しいことはわかりません。他の研究もそうですが、どうも、次世代暗号では、 32bit(64bit)程度の剰余演算が多いようなことが書かれている。 Cortex-M0は、乗算器(32サイクル)がオプションで、除算器(正しくは余算器)はありません。 ICF3-VはLSIの規模的にはCortex-M0と同程度の予定で、元々、剰余演算をする目的で開発された 暗号プロセッサと同じアーキテクチャなので剰余演算が、加算器1個しかないわりに高速です。 乗算器のないCortex-M0とは5倍から10倍は性能が違う予想です。 ICF3-Vを製品化していくとLSIの規模がCortex-M0よりも、かなり大きくなってしまうことは、 考えられなくはない。
IoTシステムは、暗号演算の性能だけでは、決まらないが、暗号の性能が最も重要になることは考えられます。
32bit CPUのICF3-Vは、まだFPGAへの実装はできていませんが、 ほぼ似たようなアーキテクチャの8bit CPU ICF3-ZはFPGAへの実装ができています。
ICF3-Z
仮想マシンの加速支援機構つきの新型8bit CPU!?
しかしながら最優先はSSLアクセラレータのICF3-Fです。このため次世代暗号の勉強不足です。すみません。


5月22日 自作CPUで通信シミュレーション通りました

今年の2月にXilinxの8bit CPU PicoBlazeでVerilogの通信シミュレーションを していましたが、8bit 自作CPU(LWZeta)で通信シミュレーションが正しく動作しました。 LWZetaはPicoBlazeの置き換えを、全く意識していないので、そういった用途は期待できないと思われます。 LWZetaは1命令4サイクルでPicoBlazeの1命令2サイクルに対して、かなり性能が悪そうなのですが、 LWZetaは3オペランド、128レジスタなので暗号演算は楽なような気がします。 PicoBlazeは16レジスタ、256スクラッチパッドメモリです。レジスタが少ないので 暗号演算のデータはスクラッチパッドに置かれる。 するとLWZetaでは1命令で演算できるのが、PicoBlazeはロード、演算、ストアの3命令になることが多くなります。 つまりLWZetaでは32bit、4サイクルの処理がPicoBlazeでは54bit、6サイクルになる。 実際に暗号演算を実装をして確認していないので、あまり正しくないかもしれませんけど。

5月21日 昨日のSNS投稿内容への訂正

1999年のICF3のRSA演算器は、モンゴメリ乗算器と暗号プロセッサに分解できる。 昨日、ツイッターで剰余演算器は、アドバイスされることもなく、上長に報告することもなく、1週間で作ったと書きました。 アドバイスされなかったというのは間違いではなかと指摘があり、訂正します。 暗号プロセッサの中に、偶数でも計算できる剰余演算器が潜んでいるのですが、暗号プロセッサの設計開始時に、 「6ブロック程度で作らないと、作りきれなくなるから。バイト単位で切ればできるでしょう。」 というアドバイスをいただいたのでした。ディレイの観点および、論理設計者にフロア設計をさせない方針から、 バイト単位(実際には16bit単位になった)になることは、必然だったのだが、全くアドバイスがないというのは間違いでした。 ちなみにICF3はフロア設計が単純作業になるような論理設計をしています。


5月20日 ICF3-Vが圧倒する

最近の国立大学の暗号ハードの研究を見ていると、 次世代暗号アルゴリズムの効率的な実装で、IoT向けのCPUではICF3-VがARM Cortex-M0を圧倒しそうに見えてならない。 見間違いかもしれないが、もし本当なら32bit CPU ICF3-Vがビジネスで成功することがあるのかも。
数日前に8bit CPU ICF3-Zを公開しました。 Verilogは公開していませんが、FPGAで動作します。このことは32bitのICF3-Vが、 すぐに実装できることを示しています。そして、仮想マシンの特長もICF3-Z同様にあるのです。 日本の過去の経験を考えるなら、採算を考えた計画でなければ、ならないように思います。


5月18日 新しいIntel CPUの脆弱性でAESの鍵が盗める

超軽量8bit CPUの出番か!?AES暗号の処理を8bit CPUで行う脆弱性の対策が考えられます。 性能はあまり必要なくAES暗号以外の処理も必要な場合、 AES専用演算器よりも超軽量8bit CPUが有利な場合があると思います。 8bit CPUであればWZetaである必要はないですが。 WZetaのアセンブラを改良しているところで、定数をdefineできる機能を追加中です。


5月17日 結局、2つのCPUサイトを公開のまま

WZetaICF3-Zの2つのCPUサイトを公開のまま、 オープンソースの公開は停止ということになりました。 今後は、LWZeta(WZetaの劣化版)をSSLアクセラレータICF3-Fに組込みICF3-Fの完成を急ぎます。 2つのCPUのサイトの連絡先で、連絡は受け付けていますが、大きな作業が入りそうなことは、あまりできないと思います。


5月14日 WZetaのサイトの閉鎖を予定しています

8bit CPUのオープンソースWZeta。劣化版をリリースすることで問題点をすべて解決。 そしてXilinxのFPGAでは劣化版でも性能があまり落ちない予想(BRAM付属の出力FF)なのですが、 現在「いいね」などを僅かにいただいている程度なので閉鎖を予定しています。 WZetaを検討している方は即中止をおススメします


5月14日 自分で自分のアイディアを回避

32bitの命令コードのプログラムをバイト単位でメモリに格納しておく。 このとき命令コードのフォーマットを工夫しておけば、 プログラムカウンタがインクリメントされ、CPUに到着した命令コードから実行ができる。 工夫がない場合、最悪32bitすべての命令コードがCPUに到着しなければ命令を実行できない。 劣化版では命令コードのフォーマットをシャッフルすることで工夫がない命令コードと判断できる。


5月14日 特許調査中断、劣化版検討

アイディアをなくした劣化版を開発するとともに特許検討の保留。 WZetaは32bitの命令コードを8bit単位で送信することで省リソース化する特長を有していましたが、 命令コードをシャッフルしてして32bit単位で送信するアーキテクチャに修正した劣化版の開発を考えます。 特長のない命令セット(コードのフォーマット)になるため特許侵害になる可能性はほぼゼロになる。 アセンブラレベルでは完全互換なのでAES暗号のサンプルなどは、そのまま動作する予定です。 うまくいけば、元のWZetaに戻せる。という方針を思いつきました。


5月13日 命令セットの工夫の特許調査開始

1990年後半、日立の大型コンピュータを開発していました。僕の名前の入った特許が2件あります。 特許作成の仕事をしたことはありません。しかし特許調査の仕事はしたことはあります。 RSA暗号のハードウェアで必須ではないが、あると便利な逆数の計算方法があります。 当時、従来より600倍高速な方法を見つけたと上長に報告すると、特許調査をするように言われました。 会社の特許検索端末で調べ始めて、比較的すぐに東芝が同様の特許を出願しているのが確認されました。
今回もないとは言い切れなかったのですが、今回の発明はXilinxの8bit PicoBlazeとの比較により、 効果があるように見える、あまりぱっとしない発明だったので、既存の特許が、ありそうもないと 勝手に思っていました。また効果のひとつに、メモリが1ポートでいいとWZetaのサイトに記述していますが、 命令セットの工夫によるものではなく、1命令を複数のサイクルで実行することによる効果ではないかという、 指摘もありました。特許という視点で厳密に書いていませんでした。
仕様、設計図、Verilog、C言語シミュレータ、アセンブラ、テストベンチ、AES暗号のサンプル、 サイトの作成を1人でやって、疲れ切って、特許に気が回っていませんでした。 制限の緩いライセンスで公開するつもりだったので、考えが甘くなっていたように思います。
1999年の暗号プロセッサICF3をベースにした8bit CPU ICF3-Zは、ほんとにICF3に酷似していて、 特許侵害になりそうなところも、思いあたるところはなかった。圧縮命令あたりは、もしかすると、、、


5月12日 8bit CPUのオープンソース公開しました

既にSNSで発表していますが 8bit CPUのオープンソースWZetaを公開しました。 命令コードの工夫を思いつくのに半日くらいで、後は僕のわずかな作業時間のみで、 構成されるWZetaは、制限の緩いライセンスで公開することが可能でした。
実際にやろうとすると、風当たり強くて、断念せざるを得ない状況に。 支援より、風を防ぐことが大事。 WZetaが他人の特許を侵害している可能性は少ないと考えていますが、これが確認されないと、 大がかりなことは、できない。 そういえば政府の支援で、税金ではなく、推奨だけのものがあるのですが、そういうのは 税金扱いなんでしょうか? 2011年に僕の会社、iCanalのICカードエミュレータを 政府に推奨していただいたことはあるのです。 震災復興イベントでした。株式会社Vectorなどの有名企業の隣にiCanalのロゴが配置されてインターネット上で宣伝されました。 さて、そこまで考える必要がある8bit CPUなのかというのは、考えないとですね。 SSLアクセラレータICF3-Fを急ぐことが先決となっていて僕の時間はあまりないですが。 それでもWZeta譲渡の可能性はないです。MITライセンスになれば派生すればいいので。 派生すると税金制御が不能になるのか。僕に連絡なく勝手な解釈されないようお願いします。


5月11日 オープンソース公開の風当たりの強さ

日本でCPUのオープンソースハードを公開することの風当たりの強さに困りました。 MITライセンスを考えていたのですが、これだと社会貢献が評価されないと、やらないほうが得なのです。
自作8bit CPUはSSLアクセラレータ ICF3-Fの通信用プロセッサとして開発しているため、 産業スパイによってソースコードが盗難され特許を取られてしまう心配があるので、 実装されたVerilogのコードの公開はする予定です。
参考まで過去、何度か自宅ネットワークに不正アクセスをされた実績があります。 ルーターのログに家族のMACアドレスで侵入してきたものがあって、 マシン名の偽装をしていなかったので、不正アクセスの動かぬ証拠となりました。
税金を使わない方針であれば、なんとかなるかと思ったのですが、 違法な行いを支持する動きがあって脳内爆弾がまた破裂するといけないので。


5月10日 AESがFPGAの実機で動いた

自作8bit CPU WZetaでAES暗号256bitが実機で動作しました。 これってもしかしてAES暗号のIPと考えることもできるんだろうか。 AES暗号が動作するWZetaはXilinxのPicoBlazeの面積の60%~65%くらいか。 周波数は安定しない。200MHzを超えることもある。(ただし1命令4クロック) WZetaの実装で誰かの特許にぶつかる可能性は、低いように思ってますが、ぶつかっていなければ、 MITライセンスにするとAES暗号のIPとして使いやすいかも。
WZetaのアーキテクチャは、32bitの命令コードを1バイト単位で転送することを考えた命令セットで、僕の考えた独自CPUです。


5月9日 AESがVerilogシミュレータで動いた

一昨日の日記でAES暗号のプログラムがC言語の 8bit CPUシミュレータで動作していたのですが、無事、Verilogシミュレータで動作しました。

軽い頭痛と眠気で寝ていました。一昨日は、久々に調子が良かったのにと。 前々回調子が良かった日との共通項を見つけた。歯医者に行った日。ボリュームで20秒間隔くらいで調節できるのか。


5月8日 他に誰も出社してない日

過去の話で恐縮です。僕が大型コンピュータを開発していた時代、 休日に無給で自主的に勉強することも多かった。 ICF3開発後、AES暗号もハードウェア実装できるか自主的に出社して検討していました。 非東大卒で一番偉い長時間管理の課長も、そのとき出社していました。 他に誰も出社していない日でした。 休日、自主的に出社すると、長時間残業管理の課長もよく出社していなぁと。 僕も残業しまくっていましたから、誰が、長時間残業で頑張っているのか評価できるくらいに。

追記。退職直前、研究所で遊んでいたと思う人が多いので。 1994年に入社、長時間残業を頑張り抜いて、1999年にICF3で大型コンピュータの事業に大きく貢献。 30歳、これで結婚できると思ったのですが、いろいろ頑張りましたが、何故か、うまくいかない。 結婚紹介所にいっても、無駄だと諦めさせられた。 みな酷いと思いながらPKIとJavaとC言語の勉強に励みました。 もう一仕事しないと、みなが認めてくれない。そう思いました。 焦りまくっていたので休日、遊ぶ余裕が心になく、ソフトウェア開発に励んだ。 ゴールデンウイークに1人、寂しく、Javaの勉強していたことを思い出します。 そしてICカードエミュレータを自力で開発し、会社の事業に貢献できると社内展開しようとした瞬間、 謎の風邪に襲われ、欠勤が続いた。2004年12月のことです。これ以上、体を壊されないようにと思い退職した。 この状況を遊んでいたと言うのはあんまり。


5月8日 8bitCPUのAES暗号はLinuxを使っているのか?

スラドの記事ドンキPBのネットワークカメラ、 Linuxの痕跡が確認されるも開発元は「Linuxを使っていない」と主張、ソースコード開示を拒むということが話題になったようです。 まだ自作8bitCPUのオープンソースを公開していませんが、AES暗号が使えそうか?という話です。 日立退職前に研究所でICカードエミュレータの元を自力で開発していたときに、 たまたまAES暗号について勉強していて、C言語のソースコードを仕様から作成していた。 アルゴリズムの理解のためなので性能は、全く考えていないものでした。opensslの10倍以上遅いものでした。
その後、フリーソフトのファイル暗号ToraToraを2009年に公開。 Windows 98/NT4/2000には自作のAES暗号コードを使っています。 WindowsXP以降はOS標準のAES暗号を使っているので自作のコードは使われていません。
自作コードの性能がMicrosoftの半分の性能でしたがopensslのコードが使われているのではないかとうわさされました。 opensslのコードをそのまま使うことはありませんでしたが、自作コードの高速化のヒントは得ています。 その中身は、AES暗号のアルゴリズムは8bit単位の処理なのですが、32bitのレジスタを持つマシンでは8bit×4を1度にできるというもの。
今回の8bit CPUのAES暗号は、8bitなので仕様を素直に実装したコードであり、とてもクリーンなコードなので、 AES暗号のコードは使えます。


5月8日 半日以上作業が停滞すると日記に

あまり厳格には日記をつけないかもしれないですが、なぜか体調が悪くなって作業が半日以上停滞するなら、 日記を書こうかと。現在も、日記をつけるのに片目をつぶりながら書いています。 1日半以上、筋肉痛で力が入らなかったり、うまく筋肉をコントロールできない状況が続いた。 マウスをうまく握れない。 過去の話を書くと、床に倒れて、自分で起きることができなくなるほど、筋肉が動かなくなったことがある。 これは1度の例外的な話ですが、時々、謎の筋肉痛になる。痛みだけなら、作業が停滞することもない。 文字で説明するのは難しいが、吐き気で動けない状況と同じだった。 これは大袈裟な話でも嘘でもない。


5月7日 FPGAのSSLアクセラレータの製品化

僕が去年発明したモンゴメリ乗算の累積加算における分割加算の証明は インターネットの社会インフラに影響する可能性があると思っています。 現状のRSA暗号や楕円暗号の延命や、巨大整数を使う新しい公開鍵暗号を発明に役立つと思います。 この日記にも書いていますが、公開鍵暗号を加速するモンゴメリ乗算は、基数を大きくしたり、小さくしたりすることができます。 僕の発明は小さい方(低基数)の高速化に役立ちます。高基数型の方法でも僕の発明と同じことができます。 FPGAとASICの場合分けをします。FPGAでは広島大学の高基数型がIEEEに掲載されています。 小さい高基数型を多数並べる方式でスループットの性能はいいです。 ただ1演算の演算時間は大きく、現状のRSA 2048bitまでなら問題ないのですが、 鍵長が大きくなると1演算時間が問題になっていきます。 僕の低基数は多数の演算器を並列に動作させて1演算を行えるので、鍵長が長くなっても大丈夫です。 ASICでは、FPGAと異なり演算器やメモリを自由に配置できるので、高基数でも1演算の性能が出せるようになると思います。 ただ設計にコストがかかるので、量子コンピュータによる解読リスクのある状況下では、うまく資金を集めるのが難しく、 設計コストが安価でFPGAでも性能が出せる僕のICF3-Fは有望です。 そして高基数型を実際に実装して、思ったより性能が出ないということになれば、そうなれば僕の名前は世界に残るのかもしれない。 現在は2048bitですが1万ビット以上とか、それ以上になってくると低基数が有利になることも考えられます。

ICF3-F(FPGAによるSSLアクセラレータ)の製品化は、数学だけでなく、論理実装、 サーバー側のソフトウェア、WebサーバーのSSL設定、多くの技術が必要なのですが、全部、僕1人で、だいたいできることを確認しています。 WebサーバーのSSL設定は、SSL向けICカードの販売を計画していたこともあって、なんとかできる程度ですが。
SSLアクセラレータの製品の特長のひとつは、サーバー製品でありながら、バグっても、接続不可になるだけのことが多く、 めったに致命的な損害が出ない。そして僕は大型コンピュータの暗号装置を開発して世界の銀行に製品出荷した実績があり、 FPGAのSSLアクセラレータの製品を、僕1人でも、作ることは可能な状態です。 頭の中の爆弾がいくつか破裂して、かなり問題ですが、エラー訂正プロトコル全開で頑張れば、まだなんとかなるでしょう。


5月7日 自作CPUでAES暗号を実装してみた

自作8bitのWZetaはXilinxの8bit CPU PicoBlazeよりも面積が小さく役に立ちそうなので、 オープンソースとして公開するべく作業を進めています。 最初、GPLにしようかと言っていましたが、方式性能的に優れているということもないので、 MITライセンスとか検討しています。 C言語によるシミュレータでAES 256bitの暗号化、復号化のプログラムを実装してみました。 AES暗号の仕様を読むと、一見、8bitの乗算命令とか、1bitシフタ命令がCPUに必要みたいな感じですが、 WZetaは、どちらもありません。しかしうまく実装できる方法を見つけました。 AES暗号の仕様が、良くできているということかもしれないですけど。
C言語によるシミュレータですがSPARCのようなビッグエンディアンのCPUでも動かないといけないと、 思ってQEMUを使ってSPARCでの動作検証をしました。 IntelリトルエンディアンのCPUでビッグエンディアンの動作検証ができるQEMUは、いいですね。 Ubuntu環境ではSPARCバイナリがIntel CPUで、そのまま動作する感じがまた良かった。


5月7日 日立は退職支援をしたのか?

毒殺して潰してますから、そんなことをして僕のわかりやすい成果に対する処遇を引っ張り出されると困るはずなので、 支援することはないと思います。僕が退職するときの条件は、日立とケンカできるようにして出てきています。 なので退職金はあまりもらえなかった。数十万円程度。 退職直後は、僕の活躍を毒殺で潰したことを周囲に話て、再度、日立に戻ることを検討していました。 当時、独立行政法人IPAで税金によるソフトウェア開発支援プロジェクトしていたゲーム会社社長は日立出身でしたが、 日立関連のICカードを販売する計画を持っていきました。1度は落されましたが、2回目で採択されました。 IPAにあった社長の経歴には日立製作所としか書かれていなくて、まさかこれから問題を言う先の日立とは思っていなかった。 このためゲーム会社社長には、僕の問題について、一言も話すことなく、終わっています。 この採択で僕は320~330万円くらいお金が入りました。 そこから日立関連の会社にICカードとして100万円くらい払っていると思います。 活躍した従業員を毒殺で潰す会社というのが拡散されるICカードは、全然、売れませんでした。 ちなみにあまり関係ないですがICカードを購入した会社は日立から離脱したようです。 退職前、日立、富士通、NECが出資して設立した日本認証サービスという会社に出入りしていました。 NEC出身の社長に「公開鍵暗号のハードが搭載されていない認証デバイスでは秘密鍵が漏洩しやすいので、 僕の開発したルネサスのICチップを使ったICカードを宣伝していただけないでしょうか?」と提案したところ、 日本認証サービスの会社のウェブサイトで宣伝していただけました。 認証局のサイトでの宣伝は効果があったはずですが、全然、ICカードは売れませんでした。
僕のいた大型コンピュータの開発部の偉い人にメールをしました。 非東大卒では一番偉く、従業員の長時間残業を管理するため自らも長時間残業していることで有名な人でした。 そして暗号LSI ICF1のときの僕の上長で、ICF3でRSA暗号の暗号プロセッサの開発を僕に 業務命令を出したことでも有名なのかもしれません。
「体をご慈愛ください。」とあっさり、拒まれました。
家族に日立の家電を買うように薦めたりしていましたが悔しいです。
僕は暗号、PKI系のソフトウェアを公開していますが、全部、独学で日立から技術は入っていません。 退職前、営業本部や、研究所にいましたが、ほぼ1人でソフトウェアの独学に励んでいました。(給料は払われていた) わずかな例外はありますが、逆に何を、僕に支援したというのか聞いてみたいです。

追記。退職金について確定拠出年金が計算に入っていないことを指摘されました。 株なので、引き出せる頃には、手数料や株の下落で、数十万円になっているかもしれないことはありますが、 いいときは100万円くらいの価値かもしれません。ちなみに、このお金、今、引き出せない。

追記 2019年5月10日。NEC出身の社長への説明をもう少し詳しく。 提案当時、日本認証サービスでは最も安価な認証デバイスを推奨していました。 公開鍵暗号の演算器は搭載されていないタイプでした。電子署名をする際、秘密鍵をCPUに送ってCPUで計算させるため秘密鍵が漏洩しやすいものでした。 一方、僕のICカードはRSA暗号が搭載されICカード内で演算されるため秘密鍵は漏洩することはありません。 また、当時のICカードの業界標準規格のAPIは、秘密鍵が漏洩することのないものでしたが、悪人によって知らないうちに破壊することができるものでした。 僕のICカードは、この問題に気づき、秘密鍵を書き込むためのパスワードと、 署名をするパスワードを分ける機能をつけながら、業界標準のAPIで動作するものを提供していました。 恐らく、この機能がないと、セキュリティ的にかなり問題なはずです。 見た目は、大丈夫なのかなという感じだったかもしれませんが、とても優れたものでした。 これが僕の提案を受けていただけた要因として大きかったのかと。


5月5日 パソコン故障で修理作業

修理作業をしたら、過去何度も修理していて、思わず写真に撮っただけの読む必要のない日記。 パソコンで作業をしているとデータを入れているHDDが徐々に動かなくなっていった。 中古HDDだったので、手早く別のHDDに交換。しかしHDDは動かない。 原因は電源と思ってATX電源を交換。動作するようになった。 ATX電源は過去、FANを交換してFANの電源が外にはみ出している。 CPUクーラーもFANが、過去ダメになって、余っていたサイズの会わないFANが付いている。 GPUは中古で購入したときにFANを固定するネジが破損していて、針金で固定している。 良くやってるなぁと自分に感心。

写真をマウスでクリックすると拡大されます


5月3日 32bitのICF3-Vの状況

8bitのICF3-Zは、かなり完成していて、 もうICF3-Zのサイトまで準備中のステータスで作ってしまいました。 32bitのICF3-Vのほうは放置されたまま実装があまり進んでいません。 しかしICF3-Zの実装によって、圧縮命令や、割込みなどの実装技術については、確認されているので、あとは 命令コードのビットの割り当てをどうすれば、効率が上がるのかという状況です。 IoTのマイコンでは公開鍵暗号の処理は重いため、AES暗号による認証を利用する計画が多いのですが、 ICF3-Vは乗算器無しでキャリーレス乗算が効率的に処理できるため、圧倒的?に面積の 小さいプロセッサになる可能性もあるのかと。その確認をするところですが、後回しと思います。 ICF3ベースのCPUは、FPGAによってCPUの設計コストが下がったから、技術的なところを押さえておいて、 ビジネスになるところを見つけて推進するという方針です。 技術的なところだけではなく反ICF3のARM支持と、韓国の影響があるように見えています。


5月3日 僕が稲門会にいない理由

日立にも稲門会はある。僕が言うのもなんなんですけど。稲門会というのは早稲田OBの集まりなんだと思う。 会社に入って数回はOB会に行ったことがある。 日立の大型コンピュータ開発部の僕のいた部署は東大卒がいっぱいの部署なのですが、 稲門会に参加しようとした日、何度か、一つ年下の東大卒の人に、稲門会には行かないように止められた。 そして稲門会には行かなくなった。 2度だけだったかもしれないが、2度あれば、稲門会に行ってはいけないのだと思うでしょう。 普通、東大派に入れてもらったのだと思いますよね。日立の東大卒の責任のひとつと思っています。


5月2日 PicoBlazeのアセンブラ

PicoBlazeの導入コストとWZetaのメリット。WZetaは公開予定で、予定の話で恐縮です。 Xilinxの8bit CPU PicoBlazeの開発環境はXilinxが提供する無償のものはWindows版だけのようです。 WindowsのVivadoで開発していれば、それほど問題はないのですが、 僕の場合はLinux上のQEMUでWindowsを起動してQEMUとLinuxでファイル共有させる環境の構築などで 1週間かかっています。さらに実際にデバッグするにはPicoBlazeのディスアセンブラが必要になるので 自作に数日かな?かかったような気がします。
僕のWZetaはC言語なので、多くのOSで動作して便利かもという話です。
ちなみにPicoBlazeの互換プロセッサ(PacoBlaze) が修正BSDライセンスで存在しています。 互換プロセッサのアセンブラはJavaで書かれています。


5月2日 WZetaのアセンブラ作成中

自作8bit CPUのWZetaが正しく動作するのか検証するためC言語でアセンブラの開発をしている。 30年前くらいからC言語を使っているが、仕事時間のおおよそ10%くらいはC言語かもしれない。 プログラミングをしていると、脳の損傷が、露見することがある。 自分にはプログラミングに癖があってif文の>=や<=は、>や<に置き換える癖。 今日も、置き換えをしようとした瞬間、できなくなっていることに、驚いた。 多分、脳のどっかが損傷している。最近の暗殺兵器は、かなり陰湿なので、注意されたい。 この手のことができるところは限られるし、依頼元は明らかなので、このやり方を問題と思う人もいると思うのです。


5月1日 CPUの知識は、どこで得たのか

誤った認識を持つ人が多くでてきそうなので書きます。 1994年4月に日立の中央研究所超高速プロセッサ部の 大型コンピュータのCPUを開発するところに入りました。 その部署の実体は既に事業部にあり、先輩は、わざわざ研究所まで来て、 将来、自分の仕事を奪われるような行いは、しません。 1日くらいやってきて、性能測定の方法だけ、僕に教えて後は、ほとんど放置でした。 研究所に入って、1年が過ぎようとするところで、IBMのCPUを購入して 大型コンピュータを開発する部署に異動になって、 IBMのCMOS CPUと日立のメモリを接続する電子回路シミュレーションをする仕事になりました。
つまりCPUを作りたくて日立に入りましたが、CPU開発の仕事は、していません。 会社から知識は入っていません。CPU撤退でCPUの勉強をすることはないでしょう。


4月28日 超軽量8bit CPUが合成できた

まだ目の調子がわるい。文章がスムーズに読めない。
超軽量8bit CPUのVerilogの入力が終わって、取り急ぎ、合成できたところ。 動作確認していないから、まだ面積が大きく変わるのか、わからないが、 Xilinxの8bit CPU PicoBlazeの約半分くらいの面積という数字が出た。


4月27日 頭痛が強くなって中断中

痛い、、、


4月26日 もうひとつ8bit CPUを作り始めた

頭が痛み出したので作業しにくくなったため日記を書きます。 8bit CPU ICF3-Zの仕上げに入ったところで、もっと軽量な8bit CPUを思いつきました。 世界のインターネットインフラに影響する可能性を持つSSLアクセラレータICF3-Fが最重要で、 ICF3-Fで使う超軽量な8bit CPUが必要だったため、急遽、新しい8bit CPUの開発を始めました。 ICF3-Zで8bit CPUを開発する環境は整っていたので、急速に出来上がってきています。
Xilinxの8bit CPUよりも面積の小さいCPUになる予定で、 この面積の小さいCPUを採用することで、1ランク下のFPGAを使って 製品ができるというのが価値になるのかと。 いくら高速に演算できてもCPUやGPUより高いと売れないですから。
この超軽量8bit CPUは32bit固定長の命令セットなのですが 「命令セットを工夫することによってCPUの面積を小さくできる」 ということを、実装して、はやく言いたくて仕方がないという状況。
名前をICF3-ZZ(ダブルゼータ)にしようかと思ったのですが ICF3とは全く異なるアーキテクチャなのでWZetaと命名します。
もしうまく動作するようならGPLとかのオープンソースライセンスで 公開しようかと考えてます。 何か参考になるものがあったのかと聞かれれば、全くないのですが、 小さいCPUは、結構、世界に沢山存在するので、似たものがないことは、わからないです。 実は、ICF3-Z公開用の新しいサイトを、作って工事中の状態で、放置しているのですが、 予定ではWZetaを先にしようかと。


4月24日 性能重視のLUT数

昨日の日記には面積重視の結果しか書かなかったのですが、性能重視の結果を出してみます。 いい性能が合成されても少しVerilogのファイルを変更すると、2度と合成されないとか、ありそうなのですが、とりあえず。 (乱数シードを調整して、同じ条件で、多数合成すれば、いいと思うが、まだそこまで調べていません)

自作CPULUT数FF数BRAM数LUT-RAM周波数
面積重視
256Byte
3871971.510160MHz
性能重視
256Byte
4361951.510170MHz

FPGAはXilinxの(XC7A35TICSG324-1L)です。


4月23日 自作CPUに64KBの拡張RAMを実装

文字認識力の低下でネット上の記事を読むのが多少、辛い。
自作の8bit CPUはレジスタ16本×2とスクラッチパッドが256バイト(先頭32バイトはレジスタ)しかデータを扱えない。 入出力命令を使ってSRAMをアクセスすることを考えていたが、 ポートIDとアドレスをセットしてI/Oリクエストを出力、次のサイクルで入力I/Oから1バイトのデータを得るという手順になって、性能が悪い。 それでも、このCPUはコントローラだと考えれば、いいと思ってきた。しかしついに高速にアクセスできるような拡張方法を追加しました。 最大64KBのデータをバイト単位でアクセス可能。Z80のエミュレーションをしてやれば、昔の8bitパソコンの復刻版とか、作れそうな勢い。 64KBのRAMを装備すると周波数が少し落ちました。

自作CPULUT数FF数BRAM数LUT-RAM周波数
面積重視
256Byte
3871971.510160MHz
面積重視
64KByte
4172051710133MHz

64KBの全領域に書き込んで、正しく書き込まれたかを確認するプログラムがFPGAの実機で動作しました。 シミュレーションでプログラム終了後、64KBのメモリを全部表示させ、正しい値が書き込まれているか確認しました。 動いている。

FPGAはXilinxの(XC7A35TICSG324-1L)です。 もう少し小さいFPGAでも十分入りますが、Artyは緑のLEDが4個+4個の合計8個あって、Dレジスタ1バイトの値を表示させるのに使っています。


4月19日 自作CPUのデバッグ機能が動いた

午前中、医者に行ってきました。とくに何かあるという話はありませんでした。
8bit CPUの動作の検証作業が続いています。 数日前、ブログ「仮想マシンの加速支援機構つきの新型8bit CPU!?」 を書いたのですが、割込みの動作検証中です。割込みを使ったデバッグ機能の検証をしました。 プログラムのコード中に、ブレークポイントを設定して、そこに、たどり着いた回数を計算して、設定した値(パスカウント)のとき、ブレークさせるみたいな機能が実現できます。 具体的には毎サイクル割込みを入れて、アドレスを確認して、設定されたアドレスなら、指定された回数に到達したかをチェック。 指定された回数の場合は、LEDを点灯させるというプログラムを作成して、FPGAの実機でテストしました。ちゃんと動いているようです。 ただプログラムコード中の一部の命令ではパスカウントを正しく計算できません。遅延分岐で遅延スロットをキャンセルする命令などです。 分岐命令の直後の命令にブレークポイントを設定した場合は、パスカウントは正しくありませんという仕様にしようかと考えています。 割込み処理中でキャンセル信号をチェックしてもいいのですが、 デバッグ機能のためにキャンセル信号をチェックする論理を追加するのは面積最小を追求するプロセッサでは、あまり良くないと考えてのことです。 (面倒とかではなくて)

XilinxのFPGA(XC7A35TICSG324-1L)に実装して面積を確認しています。 論理合成のオプションで結果が違うので、面積重視、性能重視の結果です。

自作CPULUT数FF数BRAM数LUT-RAM周波数
面積重視3871971.510160MHz
性能重視4421971.510175MHz

400 LUTいかない面積の小さいCPUで、追加のデバッグモジュールなしにパスカウントを 使ったブレークポイントを設定できるのは、良くできるほうなんだろうと思うが、 他のCPUの面積とかわからないから、なんとも。


4月16日 早めに言っておきたいことがあります

数か月前に前兆らしきもの(まだ医者に言われてない)ができて、またもう一つできました。 治ればいいのですが、数か月前にできたものも治っていない。 僕が消滅すればですが某大手メーカーの東大卒に激怒していたことを、みな忘れないようにお願いします。 OpenICF3も、この激怒を広報していただける方のみ、 使ってください。僕は某大手メーカーの東大卒が悪いと考えています。

これから大きな研究成果や開発成果をあげる方。明日は我が身と思います。 それ以外の方も、考えていただけますよう、よろしくお願いします。 大きな成果を上げると、潰され、隠蔽できず。僕のようになるのです。あまりに、酷いことになります。


4月15日 8bit CPUの割込みが動作した

ICF3-Z(8bit CPU)の圧縮命令と割込みの動作を確認中。いくつか試してみたが、どちらも、なんか動作している。 まだまだ動作検証が必要だが、ちょっと嬉しい。バグをいくつか修正したら性能が少し低下しました。 Intelの8051という有名な8bitマイコンをFPGAにしたlight52があったので比較。 light52のFPGAはXilinx Zynq(-1)で、ICF3-ZのXilinx Artix(-1)と、ほぼ同じなのではないかと。

CPUコアLUT数FF数BRAM数LUT-RAM周波数
light52811-0.5-100MHz未満
ICF3-Z4241911.510175MHz

light52の説明書を読むと1命令の実行に6サイクルとある。 ICF3-Zは1命令1サイクルで同時に2命令を1サイクルで処理できることも、稀だがある。 なんか、圧倒的、みたいな。^^)
ICF3-Zが劣っているのは命令コードのビット長。ICF3-Zは32bit。8bit CPUにしては長い。 ただし圧縮命令を使えば、16bitの命令コードになる。圧縮命令はユーザーが必要に応じて自作する。 自作する命令によるが圧縮命令を1命令実行するのに4サイクル~8サイクル程度。数百サイクルの命令を自作してもいいが、プログラムコード領域を消費する。

ICF3-Zは動作検証中なので、最終的にどうなるのか、まだ未定。性能が悪くなる予定は、ないですが。


4月13日 自作仮想マシンとか

昨日1日中、眠っていたり、深い思考ができない状態だが、仮想マシンに興味を持った。 Ruby言語にマイコン用の仮想マシンmRuby VMがあるらしい。 ほとんど研究ネタだと思うが、自作仮想マシンを作ってみるのも面白いかなと。 実用性については不明なので、暇にならないとできないが。
なぜ急に仮想マシンなのか?ICF3-Zの圧縮命令の機能を使えば仮想マシンが、できそうだからだ。 ハードで直接実行する仮想マシン。それが魅力だった。 ICF3-Z以外のマイコンはソフトウエアの仮想マシンで動作させる。 いろいろなマイコンで動作するようになるから、いろいろ環境が整って、便利になっていく。 ハードで直接実行するICF3-Zは、当然、有利になる。という仕組み。 実際、やってみると、うまくいかないこと多いのだろうけど。


4月11日 自作8bit CPUで除算した結果をLチカ

自作8bit CPU(ICF3-Z)が、動くようになったので16bit÷8bitの除算をして、その結果をLEDに表示させてみました。 16bit÷8bitの除算には17サイクルが必要になりますが、従来CPUの命令セットでは、除算器無しに、この性能はでません。 シフト命令、減算命令、条件分岐命令の組合せで除算をすれば、数倍から10倍のサイクルが必要となると思われます。 ICF3-Zは面積が小さいわりに高性能な乗除算が可能です。 1サイクルが複数クロックのCPUもありますがICF3-Zは1サイクル=1クロックです。

LEDが点滅する動画もYouTubeにアップしました。


4月10日 自作8bit CPUとMicroBlazeとの比較

注意!ICF3-Z(自作8bit CPU)の全機能を実装していますが、論理的な検証を全くしていないので、 結果が変わってくる可能性があります。XilinxのソフトCPUコアには8bitのPicoBlazeと32bitのMicroBlazeがあります。 PicoBlazeとMicroBlazeの性能差は、かなりあってICF3-Zは、その間に入るような感じかもしれない。 ICF3-ZをソフトCPUコアとして使うなら8bitで制御できて高い周波数が要求されるようなケースで役に立つように思う。 PicoBlazeは1命令の実行に2サイクルかかるので実質、50MHz程度のI/O制御となる。 一方、ICF3-Zは150-180MHzのI/O制御が可能となる。 実際にI/O制御のプログラム経験はなく、ICF3-Fが初めてなので、使い勝手がいい命令セットになっているのか、わからないが、 使いやすいような命令セットにしたつもり。
MicroBlaze(乗算器無)とICF3-ZをPicoBlazeと同じようなI/O装備にして、なるべく比較ができるような設定で、面積と周波数を比較します。 XilinxのFPGA(XC7A35TICSG324-1L)に実装して比較。

CPUコアLUT数FF数BRAM数LUT-RAM周波数
MicroBlaze7003381176166MHz
ICF3-Z3981891.510180MHz

両者、メモリは4KBですが、多分、MicroBlazeは2KBコード、2KBデータなんじゃないかと思います。 一方、ICF3-Zは4KBコードと256バイトのデータ。

機能的な差はMicroBlazeが32bitなのに対し、ICF3-Zが8bitである他、 ICF3-Zは圧縮命令を持っているため16bit命令が使えます。MicroBlazeの2倍の命令を格納できる機能を持っている。 ICF3-Zは8bitながら乗算、除算、余算ができるので、そういう処理はMicroBlaze(乗算器無)よりも勝ります。 ICF3-ZはI/O命令と加減算の命令が同時にできることもメリットです。
デメリットを考えれば、キリがないですが、ICF3-Zのメリットが活かせるところで利用さればなぁと。 あ、まだ論理的な検証できてないので、これからです。^^;;;

上側がMicroBlazeの実装結果、下側がICF3-Zの実装結果。ICF3-Zが小さいことがわかると思います。



4月9日 名前を考えたWZetaにしよう

再び目が辛くなってきた。頭の損傷の傾向も見えてきた。比率の計算ができなくなっている。 例えばMIPS(million instructions per second)、CPI(Cycles Per Instruction)が計算できない。数十秒かかる。 青色ダイオードやフラッシュメモリの発明における教訓を思い出す。 この事件が表面化した状態で、頭を打ちぬく銃の乱射の放置は全方位問題なはず。 自身に銃口が向けられて何ができるのかを考えてみてください。善良な市民に発砲しないところを見せたほうが良いように思うのです。

前置きが長くなりましたがICF3-Z(8bi CPU)のFPGAへの仮実装が続いています。 面積と周波数の概略を知るため論理的な動作検証よりも先に仮実装をしています。 まだ正しい数字とは言い難いですがプログラムメモリ4KB(ECC無)の場合、 XilinxのFPGA(XC7A35TICSG324-1L)で180MHzの周波数になりました。 Xilinxの8bitCPU、PicoBlazeでは100MHz程度(実質50MHz)。 Xilinxの32bitは昨年測定してみた結果がブログにあります。 166MHz程度のようです。もしかすると設定の改善でもう少し性能がでるのかもしれないですが。^^;
ICF3-Zは1サイクルに加減算とI/O命令を同時に実行できるので同じ周波数でもI/O制御の性能は、いいかもと推測。
プロセッサの評論家?がCレジスタの最下位ビットの値によって分岐する命令が無駄だという、うわさが、、、。 ICF3由来の命令だが、TEST命令と分岐命令を1サイクルでできます。 I/Oから読みだしたデータを処理するのが高速になるというメリットがある。

最初からわかっていたことですがICF3-Zの面積は、PicoBlazeと比較して大きいので、 ICF3-F用の通信制御に、もっと小さい面積のプロセッサが欲しくなってきた。 ICF3-Zから、さらにフォークしてICF3-Zのサブセットになるようなプロセッサを作ろうかなと。 名前を考える。ICF3-ZZ(ダブルゼータ)がいいかと思ったが、サブセットにするとICF3の特長を失うのでWZetaという名前にしよう。 名前だけ、先に決まった。(笑)


4月7日 8bit CPUのVerilogシミュレーションが動いた

まだAレジスタとBレジスタに即値を代入して加算した結果をAレジスタに代入するという簡単なプログラムでの確認しかできていない。 いろいろな命令の確認をする前にXilinxのFPGAに実装すると、どのくらいの面積(LUT数、FF数)になるのか、知りたくなって、FPGAへの実装を始めた。 ICF3-Z(8bit CPU)は移植性を考えたVerilogになっていて、プログラム用のメモリのVerilogがBRAMに変換できず、半日が経過した。 CEやリセットのないFFからBRAMには変換できないのではないかという推理。 ASICを考えるなら不要なCEとリセットは、削除して軽量な実装にしたいと考えていたので、原因究明に時間がかかった。 結局、原因を明らかにするよりBRAMを直接記述することに。
Xilinxの32bit CPUで最も軽量なMicroBlaze MCSの面積(LUT数、FF数)を調べました。 ECC無しの数字がXilinxのサイトのこのページありました。 手元にあるパソコンで実測してもXilinxのサイトにある数字と一致します。 そしてECCを有効にすると、かなり性能が低下して、面積が大きくなっていることが実測されました。実測に使ったボードはArtix-7 Artyです。 基準クロックは100MHz。ECCを有効にすると、メモリ容量の選択が8KBを選択することができなくなって16KBの結果になっているのでBRAMが5個に増えています。

32bit CPULUT数FF数BRAM数WNS周波数
ECC無68333922.634 ns136MHz
ECC有9434615-0.224 ns97.8MHz

なぜXilinxの8bit CPU PicoBlazeと比較しないのかと考えた人もあるかと。 ICF3-Zは演算レジスタ(A,B,C,D)を余計に装備しているので高い周波数で動作して、乗除算機能があるので、 乗除算はPicoBlazeの10倍以上、高速なはずなのです。面積で負けることは、最初からわかっていることなので。


4月5日 NHK新番組「逆転人生」

相変わらず頭と体が痛い。目の調子は良くなったが、頭が悪くなっている問題が検出されている。
逆転人生「最強アップルVS.貧乏発明家」 僕のような人間が見る番組なのかと。番組の初回を飾るのに相応しい逆転人生。 でも、この人、最初に3億円の借金をして裁判所に1500万円の収入印紙を払っているから、3億3千万円を勝ち取っても。ほとんど人生浮いていない。計画的な人生とも言えそう。 そういえば、僕も日立製作所に勤務していたときにMulti2の暗号のハード実装の特許を取得している。 OpenICF3のサイトにも、少し書いていますが、特許第3795315号です。 Multi2は衛星放送とか(地デジもかな)で使われているため、僕の名前が入っている特許が、使われているかもしれない。 2005年に退職したが、その後6000円くらい日立製作所から振り込まれた。 僕がMulti2のハード実装の発明をしたときの話。僕の特許の貢献率は5%ですが、実際に特許になるアイディアを考えて証明をしたのは、僕でした。 証明といっても中学生でも証明問題として出されれば解ける程度です。アイディアを思いつくきっかけになったのは東大卒の上長が「やれ」と厳命してきたからで、渋々、やってみたら、できた。 だいだい完成していたメモを、筑波大卒の新人に渡すように言われ、渡して、僕はRSA暗号の検討に着手した。知らないうちに、その新人が特許を取っていて6000円が振り込まれた。 他事業所の誰かが考えたアイディアを、知らないふりをして、僕にやらせたのかもと思うようになっているが、そうでなければ6000円かぁ。

4月6日 5:00AM 追加 「だいたい完成」という表現だと「半分くらいやった」と思いたい人とか、大勢いそうなので「完成」と考えていただいてもいいように思います。 上長とのやり取りですが、もう少し正確に説明すると、僕が「これ以上、速くできません」と言ったときに、強硬に上長が「やれ」といったこと。 Multi2の検討を上長と始めるときに、上長がCarry Save Adderが役に立つからと事前に説明している点。

4月2日 わかっていること

僕は世界の銀行で使われるような暗号装置(1999年のICF3)の開発をしているときに会社に 監視員をつけられていると思う。 監視をしなければ僕が悪組織と内通していない保証ができない。 軍事機密レベルの監視装置がついていてもおかしくはない。いや、ついていると思う。 監視員は監視ついでに僕のリストラの方法を考え、さらに儲けようとする。 監視員にとってみればOpenICF3が成功すれば、これまでの悪事が明らかになる。 そして潰せば国の損失になる。 そこで監視員が考えることは、僕からOpenICF3の利権を奪うか、事実上、無効化することだと思う。 僕にしてみればOpenICF3は、これまでの、とてつもない不遇を、どうにかするための大事な資産であり、 不遇が解決しない限りは、騙し取られないようにするため運用があまりできない。 どうしようもない。学生を使った手口も使ってくるかもしれない。そのあたりを考えていただけると。
このままいくと損失になると思います。 Intel CPUの脆弱性でOpenICF3は目立つこととなり、そろそろ国も 見てみないふりもしにくくなっていると思いますし、うまくいけることを考えるのかなと。


4月1日 エイプリルフールだから許されるだろう

被弾して結局、1日以上、寝ていた。頭痛と筋肉痛と両方。
昨年、「モンゴメリ乗算の累積加算における分割加算の証明」を 発明した。常時httpsでは現在でもRSA暗号が主流でRSA暗号をコストパフォーマンス良く演算できる方法だと思っています。 1999年に世界一高速なRSA暗号のLSIを開発した僕が演算器を改良して性能を上げています。 (ICF3-Fは低基数のモンゴメリ乗算ですが、 別の方式、高基数型のほうが勝る場合もあります)
RSA暗号だけでなく非常に大きな整数の四則演算(modつき)が得意です。 将来、新しい公開鍵暗号を考える必要が出てきたとき 「モンゴメリ乗算の累積加算における分割加算の証明」のLSIがあると、選択の幅が広がるように思います。 本当に将来、そうなれば青色発光ダイオードのようにICF3-Fの 数学の結晶が活躍するなか、 僕は消されていたとか。ならなければいいなと。


暗号プロセッサ OpenICF3