ChaCha20を調べ始めたとき、私はリンク先を載せていた。
それは、RFC-7539だ。
こちらを読んでいたのだが、出てきたのはRFC-7905だった。
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
RFC-7539 : ChaCha20 and Poly1305 for IETF Protocols
RFC-7905 : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
えっ、別物？？？
私が調べないといけなかったのは「ChaCha20 and Poly1305」で、「ChaCh20-Poly1305」ではなかったということか。
最初に正しいリンク先を示しておきながら、どんどん違った方向にミスリードさせていくとは、なんたるトリックよ。。。
もちろん、ブログに書いているのは氷山の一角で、あれこれ調べたり悩んだりし続けていたのでした。
あまりにガックリしたので、今回はこれまで。
「よくわからず」は、まだ甘い表現だ。
「まったくわからず」と言った方がよいのだが、取りあえずchacha20で何かしてみよう。
今回は、libsodumを使う。
よくわからないまま、chacha20という名前が入っていたAPIを使う。
。。。使おうとしたが、xchachaやchacha_ieftなどの種類があった。
結果も異なる。。。
ChaCha20-Poly1305のサンプルがあったので、少しだけ変更した。
MESSAGEに入れたデータは、encryptしてdecryptするとちゃんと復元される。
enc= 8eb13143515e31c709aabdb474a9f910a929b6389c4abaac90c62e5511bdb0ab1186
dec= 64(d) 69(i) 67(g) 69(i) 74(t) 61(a) 6c(l) 20( ) 74(t) 65(e) 6c(l) 65(e) 76(v) 69(i) 73(s) 69(i) 6f(o) 6e(n)
"digital television"が18文字で、encryptすると34byteだから、+16byte。
"test"は4文字で、encryptすると20byteなので、+16byte。
crypto_aead_chacha20poly1305_ABYTESが16byteだった。
いやあ、さっぱりわからんね。。。
ストリーム暗号だから、暗号にする単位ごとに16byteあればよいということだろうか。
前回、Chacha20が使えるライブラリを調べた。
しかし、何か忘れている気がする・・・と思ったら、RFCではChacha20-Poly1305となっている。
Poly1305とはなんだろうか？
メッセージ認証符号とのこと。
Poly1305 - Wikipedia
メッセージ認証符号ってなんだ？と調べると、「メッセージを認証するための短い情報」ということだ。
メッセージ認証符号 - Wikipedia
MACは、FeliCaでも出てきたな。
INPUT1: 共通鍵
INPUT2: メッセージ
OUTPUT: MAC値
メッセージが変わると、MAC値も変わるので、書き換わってないことが確認できるということらしい。
デジタル署名と似たような感じがするが、あっちは秘密鍵で符号化して公開鍵で復号するタイプだった。
そして、秘密鍵で署名する場合は「秘密鍵を知っている＝持ち主」という図式になっているので、署名を作った人はメッセージを符号化した人と同じと見なせるが、MACは共通鍵なのでそれができない(というのが、否認不可性をもたない、ということだろう)。
じゃあ、デジタル署名の方が優れているじゃないか、ということになってしまうが、MACの方が処理が軽いのかな？
デジタル署名ほどの機能は求めていないシーンもあるだろうから、そういう場合によいのかも。
この辺は、とても疎いので逃げておこう。。。
Poly1305の「1305」は、2130-5が素数だからら・・・って、いきなり素数のこと出てきてもわからん。
poly1305.dvi - poly1305-20050329.pdf
The Poly1305-AES formula is a straightforward polynomial evaluation modulo 2130-5;
うーん、moduloに関係していることは分かるのだが、まあ専門家じゃないので、ここも見なかったことにしておこう。
WikipediaのPoly1305には、オリジナルは「Poly1305-AES」と書かれている。
TLSでは、AESではなくChaCha20を使うと書かれているが、こっちは「ChaCha20-Poly1305」と順番が逆だ。
AESはブロック暗号で、ChaCha20はストリーム暗号だから、それを取り替えただけだろうと思うのだが、計算順序が違ったりするのだろうか？
まあいい。
既に自分で実装する気がないので、ライブラリさえあればよいのだ。
ともかく、ChaCha20だけではダメで、Poly1305も一緒にやらないとダメということはわかった。
前回調べた、ライブラリになっていないソースは、ChaCha20だけだ。。。というか、この人、ChaCha20自体の考案者やん！
Salsa20ときて、ChaCha20ときているから、ダンスの名称(だっけ)からとった名前のようだ。
そのうち、ジルバなんかも出てくるのだろうか。
ごにょごにょ調べていたが、ここを読んだ方がわかりやすいと思う。
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
libsodiumやwolfSSLはChaCha20-Poly1305と書いてあるから大丈夫だろう。
mbedTLSが対応するまで、それでしのぐしかないが、configureで移植できない環境に持っていくのは大変そうだ。
お仕事で、ChaCha20というものが出てきた。
茶々？
リンクはここになっていた。
RFC 7539 - ChaCha20 and Poly1305 for IETF Protocols
stream cipherと書いてあるので、連続するデータをどんどん暗号化できるというものなのだろうか？
ああ、AESなどはデータの塊を暗号化するからブロック暗号で、そういう制限がないのがストリーム暗号なのか。
残念ながら私は専門家じゃないので、難しいことは分からない。
知りたいのは、自分で実装できるようなものなのか、ライブラリを使った方がよさそうかということなのだが、こういう暗号関係は自分で実装しない方がよいだろう。
間違うと、ひどい目にあうし。
というわけで、ライブラリを探したい。
まず出てきたのが、libsodium。
ChaCha20-Poly1305 · libsodium
wolfSSLにもあった。
wolfSSL - Docs | wolfCrypt Manual - Chapter 18.7 (ChaCha20-Poly1305)
では、私がよく使っているmbedTLSにも・・・無かった。。。
Will ChaCha20 and Poly1305 be supported in mbedtls? · Issue #346 · ARMmbed/mbedtls
実装が進んでいる気配はあるが、もう1年前か。
Implement Chacha20 and Poly1305 by damaki · Pull Request #485 · ARMmbed/mbedtls
Cortex-Mくらいしか使わないから、小さいのがいいんだけどなぁ、と思ったら、こういうのがあった。
joostrijneveld/chacha-arm-cortex-m: Optimized assembly implementation of ChaCha8/12/20 permutation for ARM Cortex-M3 and Cortex-M4
Cortex-M3とかM4に最適化してあるらしい。
ほうほう、と中身を探したが、chacha20.hはあるが、本体がなさそうだ。
chacha20_perm_asm()をexternしているので、これが本体なのだとは思うが、Googleで検索しても出てこん。
本体は、libopencm3というARM cortex-M用のオープンソースライブラリなのかと思ったけど、うまく探せない。。。
ライブラリになっていると、各プラットフォームに移植するときに面倒だったりするから、数ファイルだけでできていて組み込めるのがよいのだけどなぁ。
Chachaだけだったらここにリファレンス実装があった。
The ChaCha family of stream ciphers
ref, regs, mergedって、なんの違いなんだ。。。
使い方がわからんので、同じソースを使っているこちらを読んでみるか。
circulosmeos/triops: triops: a multiplatform command-line encryption tool using CHACHA + KECCAK
仕事ではほとんどBitcoinしか見ていないのだが、それじゃあんまりだということでEthereumも少し見てみることになった。
環境の作り方はいくつかあると思うが、私がやったのは、
という組み合わせだった。
これも自分で作ったわけではなく、作ってもらったのを使っただけだ。
geth(たぶん、go言語で書かれたethereumエンジンという意味だろう)を動かし、それにJavaScriptのAPIでアクセスするというやり方だ。
ethereumは、私から見ると、JavaScriptっぽい言語で動く仮想マシンだ。
EVM、EVMとよく出てくるけど、仮想マシンがEVMね。
JavaScriptのAPIでアクセスするから「JavaScriptっぽい言語」というわけではない。
Solidityという言語でプログラムを書いて、それをブロックチェーンに載せると、燃料(gas)を与えればプログラムが動く、というイメージだ。
JavaScriptからはAPIを経由してSolidityで書いた関数を呼び出す。
関数ではブロックチェーンに書込んだり読込んだりができる。
なんとなく、DBアクセスしている気分だ。
ただ、DBじゃないので、書込んだ値は「自分のノードでそう思っている」というだけで、マイニングされてブロックに組み込まれないと値が確定しない(のだと思う)。
この辺りは、しくみがよくわからんかった。
ライトキャッシュみたいに、自分が書込んだ値を読込めば本体にアクセスせずに読み込めるけど、書込んでない人は本体を読みに行くので、キャッシュが吐き出されるまでは値が変わらない、みたいなことじゃないかなぁ。
ドキュメントの更新はそんなに頻繁ではないようで、APIを使ってみたらもう搭載されていなかった、ということがときどきあった。
私が触っていた頃は、ちょうどtestenetのRopstenが攻撃を受けたところで、Parityという別実装のエンジンだと対処法があったのだけど、Gethではどうしようもなさそうだったので、プライベートチェーンを作って試して終わった。
とにかくつらかったのが、Solidityとかじゃなくて、JavaScriptそのもの。
使い慣れていない上に、スクリプト言語自体に不慣れなので、毎日荒れていた(私が)。
また、便利なはずのmeteorも、私にとっては「JavaScriptがよくわからないのに、さらによくわからないものが載っている」ということになり、いろいろつらかった。
つまり、そういう言語に使い慣れている人であれば、敷居はそんなに高くないのかもしれない。
JavaScriptが書ける人であれば、ブロックチェーンのところはSolidityを使える少数の人にやってもらって、周りのアクセスするところは普通のJavaScriptが書ける人で対応できる。
ネットニュースでブロックチェーンを使った実験とかあるけど、多少複雑なことをブロックチェーンだけで完結させたいと思ったら、何かしらブロックチェーンでプログラムが動いてくれる方が便利で、そうなるとEthereumか、という選択になるのだろう。
技術者を集めやすいし、JavaScriptで書ける人はブラウザを使ったサービスなんかをよく作りそうな気がするので、画面の見栄えもよさそうだ。
Ethereumはホワイトペーパーとイエローペーパーというものがある。
ホワイトペーパーは日本語訳もあるので、ちょっと読みづらいけど中身としては興味深かった。
Bitcoinを分析しているところなんかも面白い。
[Japanese] White Paper · ethereum/wiki Wiki
イエローペーパーは、いやあ、さっぱりわからなかった。。
http://yellowpaper.io/
このくらいできないと、ブロックチェーン技術者になれないのだろうか・・・。
うちで動いているPCのうち、1台だけCreators Updateになった。
今のところ、特に困ったことはない。
IMEがATOKを使っていたのに切り替えられていたり、高速スタートアップが有効に戻されていたり、システムフォントが元に戻っていたりと、いくつか元に戻されていた。
得に便利になったというものはないのだが、Bash on Ubuntu on Windowsの動作がいろいろLinuxのUbuntuに近くなったので、それが一番ありがたい。
今のところ、valgrindも動いている。
さっき気付いたが「ディスプレイ」の設定に「夜間モード」というものがあった。
ブルーライト軽減というやつかな。
眠たくなりそうな色なので、ちょうどよいかも。
では、おやすみなさい。。。
2017/04/17 23時半
風呂から上がってくると、画面が薄暗くなっていて、中央にこんなダイアログが出ていた。。。
「設定の確認」をクリックすると、プライバシー設定の項目が5つくらい表示されて、ON/OFFできるようになっていた。
とりあえず、全部OFFにして承諾すると、バックグラウンドで何かするようなことをごにょごにょ言って、また元の画面に戻った。
Windows Updateの画面を見ても、タスクトレイを見ても、何かしているようには見えない。
タスクマネージャーを起動しても、何かダウンロードしている感じでもない。
うーん、なんだったのだろうか？
2017/04/18 8時半
Windows Update画面の更新ボタンを押すと、ダウンロードが始まったようだ。。。
日曜日にバックアップを取っているので、このまま進めてみよう。
今回のPCは、Windows標準のバックアップを使っているので、何が保存されているのかわかりづらいのだがね。
ダウンロードが終わると、自動的にインストール準備が始まった。
なお、これはWindows10 64bit Homeなので、Updateについては制御できないと思う。
放置して作業していると、ばーん、とダイアログが出てきた。
覚悟は・・・できている・・・。
30分くらい放置していると、いつの間にかアップデートが終わっていた。
違いはよくわからんが、アクティブ時間が18時間まで設定できるようになった。
フォントが、また細いのに戻されたから、元に戻したり。
Defenderを使っているのだが、サンプルの送信を無効にしておくと警告マークが出てくるので気持ち悪い。。ここは我慢だ。
メニューに「更新プログラムとプライバシーの設定」というのが追加されているのだけど、選択してもブラウザが開いてページに飛ぶだけだった。
あとは、Bash on Ubuntu on Windowsのアップデートくらいか。
valgrindやgolangがちゃんと動くようになっているとよいのだが。
Bash on Ubuntu on Windowsの、Creators Updateでの強化点＆新機能【Insiders Preview版】 - Build Insider
BoWの再インストールがいるらしいが、ホームディレクトリにあるデータも消えるとは。。。
ESP8266のRTOSビルド環境や、RaspberryPiのkernelビルド環境を作っていたのだが、もう一度構築し治した方がよいだろうな。
uninstallコマンドを打つと、消えるけどよい？と確認してくれるのは親切だ。
アンインストールは、案外早く終わる。
インストールも同じようなものかと思ったが、ダウンロード後にプロンプトが出てきた。
えーっと、これで"y"入力するとja-JPに変更されるのか？
それとも続行して、ja-JPに変更するか聞かれるのだろうか。
あるいは、ja-JPに変更しつつ続行か。。。
じゃあ、"n"にしたらどうなるのか。。。
最初からやり直せばいいや、と"n"にすると、アカウント作成に進んだ。
アカウント作成すると、終わりだ。
Bash on Windowsのプロンプトを起動して、確認。
$ echo $LANG
en_US.UTF-8
lsすると、Esp8266などのフォルダはそのまま残っていた。
.viminfoは残っているので、最初からあったと思われる.bashrcが消えただけか。
valgrindをインストールしようとしたが怒られるので、apt update/upgradeしておく。
makeもgccもg++もないので、あれこれインストール。。。
いつも何も考えずに足りないものをインストールしているけど、build-essentialだけやっておけばよいのかも。
googletestのビルドに失敗するので、libgtest-devとgoogle-mockもinstall。
・・・だめだ。
c++11 - Converting std::__cxx11::string to std::string - Stack Overflow
ああ、gccのバージョンが変わったということか？
Makefileに-D_GLIBCXX_USE_CXX11_ABI=0を追加して、ビルドできた。
valgrindは、動いているような気がする。
これは様子見だ。
そういえば、以前はvalgrindも自分で何とかしないと行けなかったような気がするが、apt installしたもので動きそうな気配だ。
2017/04/19
前回は、_GLIBCXX_USE_CXX11_ABI=0を追加してビルドできたのだが、今日はダメだ。。。
Ubuntu16.04でもダメだった。
=1にするとビルドできたので、make cleanが中途半端な状態になっていたのかもしれない。
valgrindは動いているようなのだけど、私が使っているライブラリではcalloc()を内部で使っているらしく、calloc()があるとvalgrindが誤検知するというか、解放タイミングが違うために解放漏れとして検知してしまうようなのだ。
-fsanitize=leakでやるのがいいんじゃないの？というStackoverflowがあったので試したのだが、BoWではビルドできるものの実行すると固まってしまった(valgrindは使ってない)。
Ctrl+Cでもタスクマネージャーでもすぐには効いてくれず、かなり時間がかかってから停止した。
むう。。。
組み込み環境だとメモリリークのチェックは大変だから、できるだけこういう環境でチェックしておきたいのだがなあ。
2点間で通信しようとすると、まず通信仕様を決めなくてはならない。
プロトコルというやつだ。
物理的な通信仕様が決まったら、次は論理的な通信仕様を決めて、どこかの段階でデータの仕様も決めることになるだろう。
あるいは、データ仕様はRFCだったり既存の機種だったりで決められているものかもしれない。
さあ、ではこれを実装しよう、となったとき、内部で持っているデータ構造をプロトコルに合わせなくてはならない。
これが面倒で、比較的機械的な作業なのだけど、やらないといかん。
ただ、そういうものであれば、誰かユーティリティを作っていないだろうか？
まず思いついたのは、protobufだ。
名前はあちこちで見かけるので、使えそうな気がする。
しかしWikipediaを見ると「XMLとの比較で～」などと書かれているので、protobufフォーマットのプロトコルで通信したり、ファイルに保存したりするのであればよさそうだけど、決められたデータ形式に合わせた入出力にする、というものではないのだと思う。
Protocol Buffers - Wikipedia
他にもシリアライザーという種類のライブラリはあったのだけど、やはり独自フォーマットになるようだ。
まあ、よく考えれば、「プロトコル」と一言で書いても、テキストやバイナリがあるし、バイナリだってType-Length-Valueもあれば、Length-Type-Valueもあるし、データに構造が載っておらず順番だけで決めてしまうものもあろう。
そういうものに対応したライブラリを作ろうとしたら、作りが複雑になって、使うのも複雑になって、結局誰にも使われない、ということになってしまいそうだ。
だから、そういうライブラリはないんじゃなかろうか、という結論に至った。
では、部品レベルでもよいから作っておきたい場合、どういうものがよいだろうか。
私の場合、だいたいバイナリで通信するから、まずはバイナリが前提となる。
TLVなり、LTVなりが固定されている方がありがたい。ソースファイルだけ取り替えれば構造が変わるのがよいだろう。
あとは、エンディアンとアラインメントか。
私が使う環境はリトルエンディアンが多いのだが、プロトコルはビッグエンディアンだったり、ものによってはビッグとリトルが入り交じっていることもある。
そして、プロトコルの方は無駄がないようにデータを詰めるけど、プログラム上ではメモリ境界に沿わないと使えない。
アラインメントは、gccだと#pragma packで詰めたりもするのだけど、いつも罪悪感というか、そういうものを感じてしまう。。。
気にせずアクセスできるCPUならよいけど、そうじゃなかったら裏でコードを書いて対応していたと思うので、全体的にサイズが大きくなってしまうこともありそうだ。
そんなことを考えていくと・・・部品化せずに全部実装することになるんじゃないのか？
プロトコルの内容によって、機械的に解釈する方が効率的だったり、個別に解釈する方が効率的だったりするのを考慮してしまうと、部品化できなくなってしまうのだ。
そうではなくて、メンテナンス性の良さとか、今後の使い回しとか、そういうのも含めて考えないと。。。
とは思うのだが、また今回も個別に実装するような気がしている。
久々にC#だ。
Windows10を使っているのだが、フォルダ選択ダイアログとしてToolboxに入っているFolderBrowserDialogを使ったのだが、初期フォルダをツリーの下の方にあるようなフォルダにしておくと、表示させたときにそこまでスクロールしてくれないことがわかった。
何か設定すればよいのかと思ったが、そうではなくて、このしくみ自体が.NETの部品じゃなくていじるのが面倒な様子がStackoverflowに書かれていた。
うん、そこまでしてやりたくはない。
そういえば、私が使っているEmEditorというテキストエディタでは、フォルダ選択が普通のファイル選択風になっているのを思い出した。
それなら、スクロールなど考慮せずに済むはずだ。
ようやく出てきたのが、こちら。
ファイルは選ぶ事あるけど、フォルダを選ぶことは少ない。 | C#等と戯れる日々
NuGetでWindows7APICodePack-Shellというものをインストールし、Microsoft.WindowsAPICodePack.Dialogs.CommonOpenFileDialogをnewして、IsFolderPickerをtrueにすることで、期待するダイアログが表示できた。
ボタンが「フォルダーの選択」になっていて、ファイルが表示されないようになっていた。
ただ、初期フォルダを設定しなかった場合、どこが開かれるのかがよくわからん。
なんとなく、前回最後に開いたフォルダのような感じはする。
System.Windows.FormsのInitialDirectoryがそうだから、同じような動作になるのかな？
このCode PackでもInitialDirectoryプロパティは使えるようになっていたから、指定した方が無難かもしれん。
前回、秘密鍵、公開鍵、公開鍵ハッシュ、Bitcoinアドレス(P2PKH)の求め方を説明した。
今回は、それぞれの使いどころを説明しよう。
まず覚えておいてほしいのは、こういう前提だ。
秘密鍵→公開鍵→公開鍵ハッシュ、の部分は一方向ハッシュという計算を使っている。
A→Bは計算できるし、毎回同じ計算結果が得られるが、B→Aは計算できない、というやつだ。
「ほぼ不可能」としたのは、力任せに一方向ハッシュの計算をし続ければ、いつかは期待する値を見つけることができるからだ。
たとえば秘密鍵は32byte=256bitなので、2256回試せば、そのどこかで出てくるはずだ。
1秒間に1億回計算できたら、何秒かかるだろうか？
うーん、生きてる間には無理そうだ。。。
まあ、0から計算を始める必要もないと思うが、割に合う作業ではないように思う。
ノイマン型のコンピュータだときついが、並列世界を作り出して正しい答を持つ世界だけを選択できるようなことができれば。。。
こういう難しい話は賢い人やずる賢い人が考えてくれていると思うので、今回は単純に「逆方向の計算はできない」ということにしておく。
まず、Bitcoinアドレス。
これは人間が見るためのものだ。
Bitcoinのブロックチェーンとしては使っていない。
次は公開鍵ハッシュ。
これは、「このアドレスに送金します」という出力で使われる。
左が送金元、右が送金先だ。
青い文字がBitcoinアドレスだが、右側の「scriptPubKey」のところに、OP_DUP、OP_HASH160に続いて16進数がずらずら並んでいるのが見えると思う。
これが、公開鍵ハッシュだ。
試しに「mwtvLXha2y5wiMt3XGFGx7EpTNG9pMdQLw」をBase58デコーダで戻してみよう。
「なってないやん！」と思うかもしれないが、落ち着いておくれ。
Bitcoinアドレスに変換する際、公開鍵ハッシュにプレフィクスとサフィックス(CRC)をつけているのだ。
頭1byteとお尻4byteを切り取って、
6FB3A987A2561CFFDFCFB0FE90AFD309576D7F88295FBF2A80
一致したでしょう？
秘密鍵はデジタル署名をするために、公開鍵はデジタル署名したのが誰かを示すために使われる。
Bitcoinの支払いは送金元と送金先を示すので、送金元の人が許可していないと送金できないようにしたい。
だから「私が送金を許可しました」という意味で、送金の記録(トランザクション)に送金元の人がデジタル署名を行うのだ。
デジタル署名の計算は、秘密鍵を使う。
秘密鍵を持つ人じゃないとBitcoinの支払いを行うことができないことになる。
ただ「これは私の秘密鍵で計算したデジタル署名ですよ～」と宣言しても信用できないので、チェックする方法が必要になる。
そのチェックに秘密鍵が必要になってしまうと意味が無い(秘密鍵を持っている人しか署名できないというルールが崩れる)。
そこで公開鍵があれば、トランザクションとデジタル署名のセットが正しいかどうかのチェックができるという計算式がある。
なので、秘密鍵だけは絶対にバラしてはいけないのだ。
そのBitcoinアドレスに入っているお金は、秘密鍵を知っている人なら誰でも送金できるようになるからだ。
カードの暗証番号みたいなものだと思えば良いか。
もう1つバラしてはいかんのが、ウォレットアプリのバックアップ。
これは秘密鍵よりもまずい。
Bitcoinアドレスの秘密鍵だけなら、そのアドレスに入っているお金だけが対象なのだが、ウォレットアプリのバックアップが漏れてしまうとウォレットに入っているすべてが対象になってしまうのだ。。。
だから、こういうのはクラウドに置いたりせず、できればPC内にも置かず、ネットや人目から切り離されたところに置いておきたいところ。
私は実験用にしかBitcoinを持っていないのであきらめられるくらいの額なのだけど、心配ならハードウェアウォレットを検討すべきだろう。
