2007年05月22日

MinGW+MSYS とコンソール

MinGW+MSYS で USBNIX を動かそうとしたのだが、コンソール入力がなかなかうまくいかない。その顛末記。

USBNIX は、まず Linux で開発して、基本的な動作を確認し、その後で AVRで動かしている。AVR 版は、動くことが判っているパーツの割合が大きいので、(比較的)すみやかに動かすことができた。MinGW でも同じことができれば、AVR-CDCベースでなにかを作ろうとする人の参考になるだろうし、USBNIX を Windowsで動かしてみて、なにか作ってみようと思ってくれる人も出てくるかも知れない。そういう意味で、MinGW版を作りたいと思っている。

さて、MinGW というのは、WIN32API (のみ)を使うので dll のインストールが必要なく便利な開発環境だ。当然 USBNIX のキーボード入力をコンソールに対応すれば(細かいところは別にして)それだけで移植が終わると思っていた。

方針としては、WIN32API のコンソールAPIをすなおに使う。具体的には、エラー処理とか省いて簡略化すると次のようなかんじ。


#include <windows.h>
#include $lt;wincon.h>

初期化:
HANDLE conin;
DWORD conin_mode = 0;

conin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(conin, &conin_mode);
conin_mode &= ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT);
SetConsoleMode(conin, conin_mode);

char usbcdc_getc(void) {
char buf[3];
DWORD nrec = 0;
while (!ReadConsole(conin, buf, 1 , &nrec, NULL)
|| nrec == 0)
;
return buf[0];
}


これが全然うごかない。でも、ためしに "コマンドプロンプト" の上で動かすと動いてしまったのだ。どうも MSYS のコンソール(rxvt) は、WIN32API で扱えるコンソールではないらしい。

WIN32API でコンソールとして扱うにはどうしたらよいのか? と考えてしまったので、はまりにはまった。結局、rxvt のソースを見たら MinGW のAPIとして提供していない termios を使っていたことがわかった。

これだと、cygwin の環境がなければ、移植できない。逆に cygwin さえあれば簡単で、termios のインターフェイスで OK ということになるのかも知れないい。でも、MSYSという環境は結構気に入っているので、コンソールアプリもそこでビルドし、かつ動かしたいところ。

WIN32APIはよく知らないが、CreateConsoleScreenBufferで コンソールを作って、イベントを送り込むようなことをすれば、 rxvt のコンソールを WIN32API で扱えるようにできるのかもしれない。まぁ、そこまでする気力はないので、termios.h と MinGW で使える tcsetattr/tcgetattr が用意できれば、対応できるようにだけはしておくけれども、通常は MSYS で実行したら GetConsoleMode がエラーになってアボートする程度にしておいた。

というわけで、中途半端ながら、最新版。→usbnix-0.4.tar.gz


参考になったページ(リンク)

MSYS/MINGW 環境設定、その1
MSYS/MINGW 環境設定、その2
Msysで日本語

追記:

MSYSのソースコード一式(msys-1.0.10-src.tar.bz2)をダウンロードしてみた。
その中の
  msys/1.0/10/rt/src/winsup/cygwin/include/sys/termios.h
が、どうも 正しいヘッダファイルらしい。
あと、
  msys/1.0/10/rt/src/winsup/cygwin/termios.cc
が、正しくコンパイルできれば、MSYSコンソール(rxvt)で動く USBNIX が作れそうだ。ただし、ビルドの方法はまだよくわかっていない。

ただ、termios.cc (のさらに一部)のために、18MB近いソースを扱うのはどうかという気がする。できれば、必要なものだけをシンプルにまとめて、USBNIX に添付したい。

追記2:

msys の bin にある msys-1.0.dll に termios で使用している関数 tcgetattr/tcsetattr が含まれていることがわかった。でこれを Google Code Search調べる と libmsys-1.0.dll.a を使ってリンクすることがわかった。これは、結局 Msysで日本語に書かれていた msysDVLPR-1.0.0-alpha-1.tar.gzに含まれていた。

lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h
lib/crt0.o
lib/libmsys-1.0.dll.a

を取り出し、termios.h 48行目の CTRL のバグを修正する。
次に usbnix-0.4 の usbnix.c の tcsetattr/tcgetattr の defineをコメントにしておいて、

gcc -DHAVE_TERMIOS -I. -nostdlib crt0.o usbnix.c minicrypt.c \
libmsys-1.0.dll.a -L/d/MinGW/lib -lmingw32 -luser32 \
-lkernel32 -lgcc -lmoldname -lmingwex -lmsvcrt

としてコンパイルすると ... MSYSコンソール(rxvt)の上で動くようになった。

そして、MSYS/MINGW 環境設定、その1 で知った日本語対応 ...

/d/msys/1.0/msys.bat で指定しているフォントを
   Courier-12 → Terminal-14に変更する

を試してみたら、USBNIX で漢字が使えるようになった!

注意:
msys-1.0.dllを使えるようにした .. というのは、逆にいうと msys-1.0.dll がなければ動作しないということです。cygwin で動作したというのと意味的にはあまり変わりません。ものとしても msys-1.0.dll は、cygwin1.dll から枝分かれしたものです。MSYSのコンソールで動くようになったのと引き換えに、動作には MSYS を必要としますので注意してください。

追記2おわりに

追記2は内容からいって独立した記事にすべきだったかもしれない。でも、あまり取り上げると AVR研究から MSYS+MinGW研究にしたくなるので、追記にしておいた。それはともかく、termios が動き漢字も使えるのなら、ちょっとしたものをビルドしたり作ったりするのは、楽しそうだ。
posted by すz at 23:01| Comment(87) | TrackBack(0) | USBNIX

実機テスト

実機テストが完了! → usbnix-0.3.tar.gz

まぁ当然ながら、いくつか問題があった。それらについて書こうと思う。

1)USBに接続しただけで、リセットを繰り返す
これでは、全然デバッグができない。とりあえず エコーバックだけするコードを動かしてみた。これは問題なく動いた。いろいろ試行錯誤したところ、最初に "login:" を表示するとリセットしてしまうことがわかった。メインループに入る前に usbcdc_getc() で1文字入力を入れたら、とりあえず "login:" が出るようになった。

AVR-CDC そのものか AVR-CDC の最新版をマージしたときのバグらしい。いまは、USBNIX を動かしたいので、(バグを追求しないで)最初に入力するという回避策のままにすることにした。

追記:
ひといきついたので、改めて動作を調べてみた。
最初にいきなり Type any.. という 38バイトのメッセージを出力していたのだが、その動作にしたら再現した。(Linux 2.4.31 + UCHI )
これを "login: "の 6バイトにした場合、 ほとんど正常に動作する。正常といっても、"login: "のメッセージを全部または一部ロストする場合がある。
それはともかく、デバイス側がいきなりデータを垂れ流すという設計は普通しない。デバイスはホストから要求があって初めてなんらかの動作を開始するようにするのが普通。
というわけで、↑は回避策ではなく正しい設計にしただけなのだ。


2)ENTER で改行ができない

なさけないミス。Linux 版は、ICRNL が効いていたので、ENTER が LF だったが、ターミナルソフトでは、CR 。

3)I2C ROM の READ/WRITE が動かない

0.2では、適当に書いただけのものだったので、これはある意味予定どおり。
デバッグがなかなか面倒で、結局 I2C ROM にデータを書くコマンド と ダンプするコマンドを作ってテストすることになった。あと、エラー処理を全然していなかったので、どこでエラーになっているかわからなかった。プリミティブだけでも エラーコードが判るようにしてデバッグすることになった。

本来の処理ではまだエラー処理ができていない。これはボチボチやっていくことにして、先に進むことにした。

4)EEPROM が勝手に書き換わる

これは、低電圧検出リセットを有効にしていないため。...というのは知っていた。しかし、2回に1回ぐらいの高い頻度で EEPROM が書き換わるとは思っていなかった。USBNIX は、EEPROM が少しでも違えば login できなくなるしくみなので、書き換わったのがよくわかる。

あといくつか改良をしたが、問題点としてはこんなところ。あともうすこしで完成か。

ちなみにいまのプログラムサイズは、

text data bss dec hex filename
7228 32 234 7494 1d46 usbnix.elf(+デバッグコマンド)
6790 32 234 7056 1b90 usbnix.elf

だいぶ厳しくなってきた。

TODO

1) 最初に文字出力するケースのバグの修正

2)MinGW 版 (キー入力を termios から WIN32API に変更して、バイナリファイルの指定をいれるぐらいで OK のはず)

3)I2CROM の I/O エラー対応
EIO をエラーコードに追加して、ちゃんと処理する。

4)ハイパーターミナルでの漢字の扱い
上で書かなかったけども、ハイパーターミナルで漢字が扱えていない。Linux では、ファイル名やデータに漢字が使えている。(といっても 8bit スルーなだけで環境が変わると文字化けしてしまう)

追記: ちゃんと漢字は扱えた -- 勘違い。ところで、ハイパーターミナルの漢字コードは、SJIS デフォルトだし、Linux でも問題なく SJIS は扱えるから、SJIS 専用ということにして、文字化け対策をしたほうがよいかも知れない。
追記2:ちなみに、TeraTerm Proや後継ソフトである UTF-8 TeraTerm Pro with TTSSH2 も期待どおりに動作した。(SJISのみ評価)


5)format コマンド
低電圧検出リセットを有効にしても EEPROM が本当に書き換わらないか自信がない。EEPROM が書き換わるとデータがすべて失われてしまうので、EEPROM はバックアップしておいたほうが良さそうだ。... そうなると I2CROM との整合性について保証できなくなる。せめて I2CROM を初期化するコマンドはつけておきたい。ただし、オペミスで format してしまう可能性をなくすために、yes を入力させるとかの考慮は必要か。
posted by すz at 00:34| Comment(0) | TrackBack(0) | USBNIX

2007年05月18日

続 USBNIX Linux 版

USBNIX をバージョンアップした。 → usbnix-0.2.tar.gz

いくつか大きな改造をしたのでそれについて書こうと思う。

暗号化のキー(ランダムデータ)をどうやって生成するか

最初の版は、/dev/urandom から取ってくるという安直な方法を取った。これだと MinGW環境では使えないし、実機のデータを生成する環境も限られてしまう。
困ってしまったのだが、結局はストレートに実機で作るということにした。
そもそも、キーが変わるとファイルが読めなくなる..というより化け化けのデータが読めてしまう。i2crom の初期化もキーの変更に同期しなければならないのだが、キーを外部で用意することにすると、i2crom の初期データもロードしなければならなくなる。それはとっても面倒そうなので、実機でキーを作り、そのタイミングで i2crom も初期化することにした。

そのデータをどうやって作るかについて、いろいろ検討したのだが結局、キーを 64 回入力してもらって、受け取るタイミングで 16bit TIMER の値をとってくるということにした。12MHz/65536 = 183Hz なので、十分ランダムといえる値を生成することができそうだ。

ちなみに、i386 の場合は次のようにした。

uint16_t get_seed() {
uint16_t seed;
__asm__ __volatile__("rdtsc" : "=A" (seed));
return seed;
}


TSC という 64bit のタイマーがあって、CPU クロックでカウントアップされている。(キーが入力されたタイミングで)そのTSC の下位 16bit だけ取ってくる。Linux(いまどき Pentium III!) でしか確認していないが、Windows でもたぶん大丈夫だろう。

inode番号指定のオペレーション

TODO にも書いたが、文字化けしたファイル名のファイルができてしまったとき、どうやってファイルを読んだり、消したりするかという問題がある。これについては、ls -i というオプション(UNIX には昔からあるもの)をサポートして ファイルの ID(UNIX ではinode番号という) とファイル名を表示するようにして、rm と cat に -数字 というオプション(これは USBNIXオリジナル)を作り、inode番号指定で操作できるようにした。幸い avr-libc には、atoi() があったのでそれを利用することができた。ちなみに、ls -i での番号表示は、サイズとか見栄えの理由で、itoa や printf でなく自作のコードにしている。

エラーメッセージ

エラー処理をみなおして、できるだけちゃんとしたメッセージが出るようにした。ないファイルを指定すれば、(ディレクトリなんてないのだが)"No such file or directory" 32個を超えるファイルを作ろうとすれば、"No space left on device" ...なんて伝統的なメッセージが出る。

内部処理も Linux 流に -エラー番号 を使うようにした。

パスワード処理

前に、userとパスワードをつなげたものをパスワードとして扱うと書いたが、合計で 15バイトまでしか使えなったのを それぞれ 15 バイトに拡張した。こんな処理。


mc_setkey(user);
mc_encrypt(password);
for (i=0; i<128; i+=16) {
eeprom_read_block(line_buf, (const void *)i, 16);
mc_encrypt(line_buf);
}


メモリが使えないし、API がシンプルなので、こんな些細な改造でも、実は苦労した。...ところで今まで ターゲットの ATtiny861 の RAM が 256 バイトだと思い込んでいた。念のため確認したら 512バイトだった。stack が足りないんじゃないかと心配していたのだが、これで心配はなくなった。なんか得した気分。

TODOその2

5)login 時のメッセージ表示
UNIX では、(V7 のときから) login 時に /etc/motd の内容を表示するようになっている。その機能をなんとかしたい。ディレクトリがないので、motd というファイルがあったらそれを表示することにしよう。それに Welcome to ナントカカントカ と書いておけば、雰囲気が出るだろう。
ちなみに motd は、"message of the day" の略だそうだ。...実はいままで知らなかった。

おわりに

だいぶ満足のいくものになってきた。そろそろ実機で動かすことを考えたい。ソースコードはほとんど共通なのであまり苦労しないはず。ちなみにいまのプログラムサイズは、

text data bss dec hex filename
6562 12 200 6774 1a76 usbnix.elf

必要なコードはすべていれてのサイズ。デバックすれば多少大きくなるだろうが、8KB 以内は楽勝の見込み。
posted by すz at 20:29| Comment(0) | TrackBack(0) | USBNIX

2007年05月17日

USBNIX Linux 版

なんかそれらしいもの → usbnix-0.1.tar.gzができあがった。

make usbnix とすると linux 版ができてテストすることができる。AVR のビルド環境があれば、make で AVR 版もビルドされる。ただし、プログラムサイズをみるためだけのもので動作しない。

実行例

$ ./usbnix
login: suz
New password:
Retype new password:    #最初のloginは、パスワードを設定する
# ls
# cat > test1 # これでしかファイルを作れない。
aaa bbb ccc # ^D か 行頭の .で EOF
# ls
test1
# cat test1
aaa bbb ccc
# exit
login: suz
Password: # 2回目からは正しいパスワードが必要
# ls
test1
# rm test1
# ls
# rm aaa
No such file or directory
# passwd # 初期化するだけのいんちき passwd
login: suz
New password:
Retype new password:
login: suz # Retype で間違えれば、やりなおし。
New password:
Retype new password:
#


こんなところでどうだろう。ちなみに AVR 版のサイズは、まだ 5516 バイト。エラー処理とかのブラッシュアップで多少大きくなるだろうが、まだ拡張できそう。

ちなみに、プログラムを動かすとカレントディレクトリに、eeprom のイメージファイル key.img と i2crom のイメージファイル i2crom.img ができる。このファイルを消さなければ、作ったファイルは保存される。(eeprom イメージは、他人に見えないようにパーミッションを設定しないと危険なので注意。実用として使う人はいないと思うが一応。 )

i2crom.img の中身

FILE: i2crom.img (32768) - ASCII
PAGE: 0 (0)
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xa xb xc xd xe xf 0123456789abcdef

00: 74 65 73 74 31 00 00 00 00 00 00 00 00 00 00 00 test1...........
01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04: d3 26 a9 ed dc 53 ec 9c c9 77 fb 30 eb 00 00 00 .&...S...w.0....
05: d0 f3 ca 49 1f 42 a7 52 9b c8 88 6e 48 8c cb fb ...I.B.R...nH...
06: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................


32KB を 1KB 毎にわけて、その1KB の頭 64B までに ファイル名が平文で入る。64B のオフセットから、ファイルの中身が 暗号化されてはいる。
16B 単位でデータをセットするので、後ろのほうは初期値のまま。

TODO

1) rm では、ファイル名しか消去していない。ファイルイメージも消去する必要がある。
2) 消せないファイルができてしまう可能性がある。ls で inode 番号(?ファイルの場所を示すインデックス)を表示して、rm で inode番号を指定できるようにするとか工夫が必要。
3) コマンドライン入力の cooked モードが貧弱で漢字などを入力した場合 BS で文字化けする(はず)。なんか対策を考えたい。
4) Linux 版だけではなく、MinGW 版もつくってみたい。いまは、/dev/urandom とか使っているので、動かない。keyにつかうランダムデータをどう生成するかが問題だが、それは AVR 版の初期データ生成にも共通する問題なので、解決する必要がある。一般の乱数で生成するのは、データに関連性ができてしまうので望ましくない。

おわりに

着想の段階では、8KB ではとても入らないだろうと思っていたが、作ってみたら、わずか 5.5KB に機能が入ってしまった。このサイズで USB を制御し、簡単ながらファイルという概念をもっていて、login できて、コマンド処理もし、暗号化までしているわけだ。

USBNIX というのも面白いものだと思うが、工夫しだいでもっといろんなものが作れそうな気がしてきた。
posted by すz at 23:01| Comment(0) | TrackBack(0) | USBNIX

USBNIXの構想

はじめに

作ってみようと思っている装置の記事で

UNIX もどき USB Key
実はUSB910では、オリジナルのAVR-CDCに手を入れて getc/putc でプログラミングできるようにしていて、USB シリアル装置を手軽に作れるようにしている。で、なにか便利(そう)なものを作ってみようと考えていて思いついたもの。
この装置をUSBにつないでターミナルソフトを立ち上げ、ENTER を入力すると login: なんて出る。本当に login できて、いくつかのコマンドが使える。使えるコマンドは、ls と cat ファイル名と cat > ファイル名。あと rm ファイル名 は必要か。なんに使えるかというと、(他の)パスワードとか忘れそうだけれども秘密にしたいものの覚書。ファイルデータは、1件 1KB 以内で、32件までにして、I2C ROM に入れる。I2C ROM だけ抜かれたりしたときの対策に暗号化が必要で、暗号化のキーは本体のEEPROMに覚えさせてロックビットで保護する。最大の問題はコードのサイズ。 4KB に入れるのは無理そうだが、8KB には収めたい。装置単体でのパスワードの変更は無理だろう。で、どうするかというと、データをいったん全部吸い出して、あらためて パスワードと暗号化キーデータを生成して、EEPROM に書き込みデータを書き戻す...そういうホストプログラムがあれば問題ない。

と書いた。これを実際に作ってみることにする。USB Key ではなにのことかわからないので、USB + UNIX の意味で USBNIX と名前をつけた。超々簡易版ではあるが、UNIX のコマンドを使って操作する。説明なしにデモすれば、UNIX or Linux が動いているように見えて驚かれるかもしれない。

暗号化のコードをどうするか

DES や AES といったものを移植するという方法はコードが大きくなりすぎる(はずな)ので、最初からあきらめている。実は、UNIX V7 のコード usr/src/cmd/crypt.c を使おうと思っていた。で、(ライセンスにしたがって)このプログラムは、UNIX のコードを使用しています...なんてシャレで書こうと思っていたのだが、実際にコードを見てみると、char の配列が256x3 もあることがわかった。これでは tinyシリーズでは無理だし、mega88 とかでも厳しいので、それもあきらめて、自作することにした。eeprom にkeyを入れて ロックビットを設定してやれば、弱い(てきとうな)アルゴリズムでもまぁ大丈夫に違いない。

ところで、UNIX V7 の crypt.c のコメントが興味深かったので紹介。
A one-rotor machine designed along the lines of Enigma but considrably trivialized.

だそうだ。要するに有名なエニグマ(第二次世界大戦のときのドイツの暗号装置)の簡易版ということらしい。

構造とかAPIとか

md5 などと同じように、コンテキストを持っていて入力ストリームによって状態を変化させていく。で、コンテキストと入力ストリームの XOR を取ってエンコードする。デコードもほとんど同じで、状態を再現して、XOR で元に戻す。md5 とかは、コンテキストを変化させる部分が非常に複雑になっているけども、ここを思いっきり簡単化すれば、8KBのAVRで使えるものになりそう。

具体的には、


typedef union mc_context {
struct {
uint32_t A;
uint32_t B;
uint32_t C;
uint32_t D;
};
uint8_t buf[16];
} mc_context_t;

mc_context_t mc_context;

static void mc_rotate(uint32_t *x) {
/* pseudo random generator */
*x <<= 1;
if ( (!(*x & (1L<<31)) && (*x & (1L<<28)) )
|| ((*x & (1L<<31)) && !(*x & (1L<<28))) ) {
*x |= 1;
}
/* netbsd rand() algorism */
*x = *x * 1103515245 + 12345;
}

static void mc_xor(uint8_t *dst, uint8_t *src) {
uint8_t i;
for (i=0; i< 16; i++) {
*dst = *dst ^ *src;
dst++;
src++;
}
}

oid mc_encrypt(uint8_t *block) {
mc_xor(block,mc_context.buf);
mc_rotate(&mc_context.A);
mc_rotate(&mc_context.B);
mc_rotate(&mc_context.C);
mc_rotate(&mc_context.D);
mc_xor(mc_context.buf, block);
}

void mc_decrypt(uint8_t *block) {
uint8_t tmp[16];
memcpy(tmp, block, 16);
mc_xor(block,mc_context.buf);
mc_rotate(&mc_context.A);
mc_rotate(&mc_context.B);
mc_rotate(&mc_context.C);
mc_rotate(&mc_context.D);
mc_xor(mc_context.buf, tmp);
}


こんな風にしようとしている。mc という prefix は mini crypt の略。mc_rotateの上の部分は、ホワイトノイズ生成とかで使われている 擬似乱数(pseudo random)ジェネレータ 。下の部分は、netbsd の rand() のアルゴリズム。最初は下の部分だけでよいと思ったが逆関数がつくれてしまいそうなので、上の部分もあわせて使うことにした。これでかき混ぜておいて 入力データとの XOR で新たな 状態を作る。コンテキストの初期状態は、

void mc_setkey(const uint8_t *key);

で設定することにする。eeprom に 16 バイト x 8 の乱数を格納しておいて、
ファイル毎に Key を変える。

これぐらいしておけば、素人みえには他の暗号化アルゴリズムと遜色なさそうなデータになるのではないかと思う。ただし、アルゴリズムを知っている上でまじめに解析されればわりと簡単に解けてしまうかもしれない。

パスワード

UNIX もどきなので、user と password を入力させようと思う。ただし、user という概念はないので、user と password をくっつけたデータをパスワードとみなす。格納するデータは、平文ではなく、暗号化したデータでもない。一方向関数によって生成したダイジェストである。これを mc_setkey と mc_encrypt を使って生成することにする。

mc_setkey(line_buf);
for (pos=0; pos<128; pos+=16) {
eeprom_read_block(line_buf, (void *)pos, 16);
mc_encrypt(line_buf);
}

ようするに、パスワードを初期状態にし、乱数テーブルでかきまわしたデータ。これを eeprom に格納しておく。同じ処理をおこなって同じデータになれば、login を許すことにする。ちなみに、パスワードデータを PCで生成する予定だったが、それはやめて、実機で行うようにするつもり。

おわりに

このシステムで、暗号化をどうするかが最大のポイントだった。全体で8KBに入る見込みがなければ、作るのをあきらめようとさえ思っていた。
いまいち不安ではあるものの、次のように 474 バイトとコンパクトな暗号化モジュールができた。


text data bss dec hex filename
474 0 0 474 1da minicrypt.o


これさえ目処が立てば、あとはプログラムを作るのみである。USB910A と 実験ボードその1

を使って評価できるので、ボードも作る必要はない。

といっても、最初から実機でテストするつもりはない。Linux でプロトタイプを動かして満足できるものに仕上げてから、実機に移植する予定。次回は、その製作をレポートしたいと思う。

追記

つれづれ日記からコメントをいただいた。更新を久しくしていなかったのに、すかさずコメントをもらえて嬉しい限り。

コメントではじめて知ったのだが、Crypto-avr-libというのがあって、各種暗号化アルゴリズムを AVR に移植しているそうだ。はっきりはわからないが、 メモリが厳しいものの MD5 とか SHA とか載らないわけでもないかも知れない。
posted by すz at 16:55| Comment(0) | TrackBack(0) | USBNIX