Home

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