Home

プロジェクトの状態

ICF3-Z、WZetaは税金の引き出しに使われたくない

自作8bit CPUのICF3-ZWZetaが完成し、 FPGAに実装できるVerilogが公開できる状態にあります。 技術的な問題で公開できないわけではありません。 CPU開発への風当たりが強いので公開しても、イジメにあって、得にもならないことが問題なのです。 ICF3-Zは、産業スパイが盗みだしている可能性があります。誰にも許可をしていません。 WZetaも、誰にも許可をしていません。もし、日立関係以外で、ご興味があれば、ご連絡ください。 ICF3-Z、WZetaは税金の引き出しに使われたくないと考えています。
SSLアクセラレータのICF3-Fの開発を優先しています。


5月23日 ICF3-Vは剰余演算に特化した効率的なアーキテクチャ

IoTゲートウェイ経由ではIoTデバイスは公開鍵暗号などの重たい処理をIoTゲートウェイに任せることができる。 IoTデバイスを可能な限り軽量なCPUを使ってIoTシステムの原価を下げたい。という需要はあるような気がします。 暗号アルゴリズムで32bit×32bit、64bit÷32bitが多いものであれば、 ICF3-Vは一般のCPUと比較して、かなり効率的なアーキテクチャです。 ICF3-Vは、同じ加算器1個なのに、5倍以上の性能になる。 剰余演算に特化した効率的なアーキテクチャというのを覚えてもらえればと。 またAESのMACで使われるキャリーレス乗算も、アーキテクチャ的に効率がいいです。


5月17日 8bit CPUのサイトを公開

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

3月21日 8bit CPUのICF3-Zをフォークしようかな

8bit CPU ICF3-Zの仕様を公開すれば酷評する人とか、いそうなので書いておこうかと。 8bit CPUの計画が立ち上がった経緯。ICF3-Fを急いでいたのですがXilinxのセミナーから溢れてしまって、 ICF3-Fで使う通信プロセッサの8bit CPUを自作することに。 そこに常々、考えていた圧縮命令の実装と、割込みの実装を検討すると、とても簡素に実装する方法を思いついた。 やるしかないと思い、設計図 A4 5枚を書いた。3枚はメモリのみなので実質、A4 2枚。 1枚をverilogにして、完成が近づいたところで、他の8bitマイコンを調べてみました。 ICF3-ZはXilinxの8bitより高性能で面積が大きい。 8bitのマイコンに期待するものは面積が小さいことなので、少し考えた。 Xilinxの8bitは100MHzちょっとまでしか周波数が上がらない。 そのせいでXilinx 8bit CPU付属のUARTの性能が出ない。 一方、ICF3-Zは、高い周波数で動作するため、そういったところでは役に立つだろうと。 インターネットで8bit マイコンを調べると、ATmega328PとかSTM8などが見つかる。 ワンチップマイコンとSoC内で使うサブCPUとでは違うと感じました。 NECのPC98でステッピングモーターを割込みで制御するシステムとかしか作ったことがないので、 最近のワンチップマイコンの事情とか、詳しくないため、正しいことは言えないと思いますが、 ATmega328PもSTM8も、良くできているなぁと感心しました。 両者、アーキテクチャが全然、違っていて面白い。 ATmega328Pはパイプラインはなくて1サイクルでメモリをリードしてライトするみたいなので、 ICF3-Zほど高い周波数では動作しない予想。 STM8は3段のパイプラインなので高い周波数で動作、メモリのストールがしっかりできているので性能が安定していそう。 でもストールがプログラマから見えないので、決められたサイクルでI/O制御させる僕の用途には向いていないのかも。 ICF3-Zは多分、小さい面積でありながら、高い周波数で動作し、STM8よりもレジスタを多く持っているので、 レジスタに入る範囲内の加減算、AND/OR/XOR/NOTは、とても高速。 レジスタの範囲内にAESなどの暗号やハッシュが入るのか、調べていませんが、入るなら高速で役に立つのかも。
ICF3-Zは、ICF3-Fで自分が使うために作っているので万人の人にいいかどうか、わかりません。 OpenICF3で一番最初のプロジェクトICF3-Vの評価を予測する目的としてやっています。 ですが、ICF3-Vと同じように仕様、設計図を公開するかもしれません。


3月3日 ICF3-Vの命令セットの修正予定

ICF3-Vをする時間が、なくてあまり進んでない状況ですが、16bitの圧縮命令セットの実装のため、 これまで通常命令モードと圧縮命令モードのようなモードを使って実装を検討してきました。 これから命令コードの最上位bitを圧縮命令セットか否かを判定できる方式に変更することを考えます。 RISC-Vでは命令コードの上位2bitが圧縮命令セットか否かを判定する方式です。 命令コードのフォーマットは似ていますが、実装はどうなんでしょう? ICF3-Vの実装は最上位bitが1の場合、オペコードをアドレスと思ってサブルーチンコールをします。 簡単に説明するとICF3-Vはマイクロコードを32bitの命令セットにしています。 16bit圧縮命令だけ特別な解釈をしてサブルーチンコールに置き換えて、 ICF3-Vの32bitの命令セットで16bit圧縮命令の中身を実装する。 実装が容易で面積がとても小さいプロセッサになる。


1月4日 1999年ICF3の大型加算器の方式

ICF3には1024bitの大型加算器がある。 加算器を学習するとキャリーの伝搬方式としてripple carry方式やcarry look ahead方式を学ぶと思います。 ICF3がripple carry方式なんじゃないかと思っている人もいて説明することに。 当時、暗号プロセッサを1人で設計していた。とても忙しくて教科書通りのripple carry方式とか、 carry look ahead方式にする必要はなかったので、とにかく実装した。 そのため、当時、それがcarry look ahead方式なのか、確証を持っていなかった。 実装に対してあまり負荷がかからないように実装したということなのです。
ちなみに大型加算器のキャリーは性能上のクリティカルパスなので通常の配線ではなくて、 上層配線をすることになり、どの信号線がキャリーであるか資料作成を僕がしていました。 3倍幅の配線よりも上の方法。


12月11日 ICF3-Fの状況報告

暗号プロセッサを実際のFPGAに実装して製品化するためにはサーバーと通信するためのハードも実装する必要がある。 どんなに演算が速くても、通信性能で頭打ちになることがあるので、通信ハードの実装をどうするか検討してきた。 通信性能を見て暗号プロセッサ側のハードの実装の詳細を詰める順番がいいと思ったからだ。 USB-RS232Cコンバータのチップには12Mbpsの性能を持つものがあり、性能が出るなら、引っ張りだして、 あと楽をしようと考えている。FPGAの実機で3Mbpsが動いたが、高速化をしていくとノイズによる ビット誤りも気になるので、CRC32などの符号化を検討。とりあえずは、もっと簡単な符号化で試作の予定。 通信ハードは暗号プロセッサが実行中にも、次のデータを送り込んだり、結果を取り出すような実装になる。 もう少し時間がかかりそうです。


12月7日 ICF3-VにCRC32/CRC32C用の命令追加(改訂版)

XORC命令をBICZERO命令に差し替え。XORC命令は、ほぼ専用命令なので、 複合命令にして4命令を2命令になるように変更。性能は昨日と同じ2サイクル/ビットです。 用途の狭い専用命令っぽいものになってしまいましたが、 追加のゲート数が少ないので実装することにしました。


12月6日 ICF3-VにCRC32/CRC32C用の命令追加

Cレジスタの第0ビットが1ならXORの値、0なら0にするXORC命令を追加。 GF(2^128)のためにXORを加算器に移しましたが、これにCレジスタの第0ビットによる制御を追加。 ごくわずかな修正でXORC命令は実装できます。このXORCを使うとCRC32/CRC32Cが 2サイクル/ビットの性能がでます。CRC32/CRC32Cのアセンブラコードを仕様書に追加しました。 一般的な命令セットの低性能なCPUで2サイクル/ビットの性能はかなり難しく、 8ビットづつ処理するには1KBのメモリが必要になったりするのでICF3-Vは、 専用ハードやメモリなしに高い性能が出るということかも。


12月5日 ICF3-VでGF(2^128)乗算(改訂版)

昨日に続きICF3-Vの仕様を更新しました。 GF(2^128)乗算のサンプルコードをバージョンアップしました。 昨日のものは計算結果は正しいのですが、 C言語の疑似コードがICF3-Vのアーキテクチャと若干ズレたため修正しました。 リダクションの処理の性能が改善されています。

余談になりますが、Intel White Paperのデータ形式に合わせるため、 下位ビットから乗算するハードで上位ビットからキャリーレス乗算するコードになっています。 性能もあまり損ねず、良くできたと思ったのでした。


12月4日 ICF3-VでGF(2^128)乗算

ICF3-Vの仕様を更新しました。 ICF3-Vは32bitの暗号に強いマイコン。 小さい汎用演算コアに、いろいろな暗号を効率的に演算できるように凝縮していきます。 GF(2^128)の乗算を効率化するために加算器でXORの演算ができるように修正。 加算器は、元々、XORを持っているので、わずかな追加で実装できます。 GF(2^128)のC言語による疑似コードを追加しました。Intel White PaperのC言語のAPIと 同じにしています。コンパイルすれば試せます。 GF(2^128)乗算で先行しているところとがありますがコンフリクトしていないだろうと思います。


11月30日 暗号プロセッサの時代が来るのか?

IntelやARMの動向を追っているわけではないので技術的な面からの予想みたいな話です。 「CPUの脆弱性の対策として暗号プロセッサ」は有力だと思っています。 ICF3-Fの実力はまだ未知なのですが気の早い人はICF3-Fは、どうなのかと考える人がいて 意図しない使われ方で、使えないと評価されるのは困るなと思っています。 ASIC前提とFPGA前提で違うので、ここではASIC前提で考えていきます。 RISC-Vだとセキュリティを考えずに性能設計に注力できるのでICF3-Fは都合がいいように思っています。 どのCPUも暗号プロセッサ用のAPIを決めて、その実装にICF3-Fを利用することは考えられます。 ICF3-FはRSAも楕円も演算できますが楕円はCPU型でも高速に演算できます。 つまり楕円しか使わない用途には向いていません。 この段階でIntelについて考える必要があるのかと思っているのですが、気の早い人がいるので、 無理にでも考えてみます。 RSAや楕円を高速化するモンゴメリ乗算は基数の取り方で実装が大きく変わる面白いアルゴリズムです。 ICF3-Fは低基数で配置配線が容易であることが特長なのです。 逆にいえばIntelのような配置配線が得意なところでは高基数で高性能な実装を開発できる可能性があります。 最終的にICF3-Fのモンゴメリ乗算の累積加算における分割加算が 最も効率的だったということになれば、うれしいなとは思っています。
CPUの脆弱性のために暗号プロセッサを追加したいけど、性能は低くてもいいからゲート面積最小にしたいという用途に ICF3-Vが、もしかすると使えるのかなとも思って見たり。


追記
CPUの脆弱性対策としてのICF3-Fの評価と、SSLアクセラレータとしてのICF3-Fの評価は違うように思っています。 SSLアクセラレータは外部LSIでもいいのでCPUメーカでなくても製造可能であること。 おおざっぱな話、高基数な暗号プロセッサがCPUと同じ傾向を持つとすると、RSAの鍵長が2倍になると処理時間8倍。 一方、ICF3-FはRSAの鍵長が2倍になると、演算器ゲートを2倍にすることで、処理時間4倍なので、鍵長増大による応答時間の問題の対策になるかもしれない。


11月29日 ITを扱う一般文系という想定で書いてみます

(最近、知り合いの文系の方にメールした内容を転載)
理系でも専門でないと、ICF3-Fが、どのくらいの技術なのか、わからないと思っています。 ざっくり言うとRSA暗号を高速化する世界一の技術ではないかと思っています。
そう思う根拠の一つは、もし、この技術が他で開発されていれば、常時httpsなどの 時代のニーズによってSSLアクセラレータが製品化されているはずなので。
RSA暗号の高速化の研究は非常に多くあります。いろいろな計算方法があるのです。 あまり詳しくない人が論文を調べるとRedundant Number Systemsとか、Residue Number Systemが モンゴメリ乗算の累積加算における分割加算 と類似していると言うかもしれない。
これらの論文を実際に読んでみると、複数の演算ユニット使って並列に演算できるのは いいのですが、実際に実装するには複雑で、製品化できなかったのだと思う。 精密に読んでないので、間違っている可能性はありますが、余計な演算をしていることは 確認したつもりなので、全くの、でまかせで言っているわけではありません。
もっと簡単に、LSIに実装しやすい方法を見つけた。(のではないかと思っています)
そしてRSA暗号の鍵長を長くしていった場合でも使えるので常時httpsをはじめ 世界のシステムに大きなインパクトを与えられる可能性があるのです。


11月21日 ICF3-Vの仕様を半年ぶりに更新

最初の頃の仕様にあった加算器のXORモードを復活させました。 XORは論理ゲートのレベルで考えると加算器のサブセットなのでゲートを少なくできる可能性があります。 ただ性能的にクリティカルパスになりやすいので一度、見送りました。 ICF3-Vは暗号に強いマイコンということで暗号面の性能強化に役立ちます。 ソフトウェアでキャリーレス乗算が高速になるのが利点です。


11月2日 ICF3ってオープンなの?

はい。FPGAでSSLアクセラレータを開発するICF3-Fは商用版として クローズドにしていますが、元々のICF3はオープンソースで マイクロコードも公開しています。 ただライセンスについては、まだあまり固まっていない部分があります。 何かやってみたいという人は匿名でないアカで問い合わせてみてください。 Intelの4004をFPGAで再現した本 がCQ出版から販売されていますが、1999年のICF3のレプリカ(厳格な複製)はFPGAで再現して販売して 儲けてもらっていいように思います。僕のほうはICF3-F、ICF3-Vで手一杯で当面、自分では無理なのです。 ICF3-Fの開発が進めばモンゴメリ乗算器をはずして、1999年のモンゴメリ乗算器を取り付けるとレプリカになります。 詳細なところでは相違はいくつかありますが、その設計データを提供することは可能です。(日立関係の方は不可)

ARMの搭載されたFPGAに1999年のICF3を実装すれば、通常よりはセキュリティの高いhttpsのWebサーバになるように思います。 実際に詳細を詰めて検討しているわけではないので、ビジネスになるのかまでは、わかりませんが。



11月2日 ICF3-Vって何に使うの?

暗号プロセッサを汎用マイコンに改修しようとしているため、まだちょっとできていないが、 面白みのあるアーキテクチャなので、いけないかと思っています。 ふと思いつたのだがダウンロードしたファイルを検証するIoTとかできないかと。 PGPによる検証はパソコンでもできるが信頼した鍵が不正アクセスにより改ざんされていないか心配になる。 PGP検証専用のパソコンを用意するのは高価、そこでIoT。 ICF3-Vは暗号、ハッシュ関数の計算が得意なので有利なのです。



11月1日 ICF3は日米共同開発なの?

暗号LSI ICF3はIBMの互換機です。日米共同開発したのか?みたいに思う人も多いのです。 IBMの仕様から日立の日本人だけで開発していたと思います。 基本的な動作検証ソフトの開発は日立でしていたように思いますが、IBM互換機なのでIBM製の動作検証ソフトを最終的に利用していたのかまでは確認していません。私が最初の15システムくらいまでは製品出荷の作業をしていました。 思い出してみると開発部の部屋に外人が入って来た記憶は、ほとんどありません。 日立が雇用していたドイツ人は1人いました。



11月1日 こんなサイトも、作ってました

http://noteice.idletime.be/

暗号プロセッサ OpenICF3