2017/04/30

「ChaCha20 and Poly1305」は「ChaCha20-Poly1305」ではないだろう

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」ではなかったということか。
最初に正しいリンク先を示しておきながら、どんどん違った方向にミスリードさせていくとは、なんたるトリックよ。。。

もちろん、ブログに書いているのは氷山の一角で、あれこれ調べたり悩んだりし続けていたのでした。


あまりにガックリしたので、今回はこれまで。

[clang]よくわからずchacha20する

「よくわからず」は、まだ甘い表現だ。
「まったくわからず」と言った方がよいのだが、取りあえずchacha20で何かしてみよう。

今回は、libsodumを使う。


[gist]libsodium1

よくわからないまま、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あればよいということだろうか。

2017/04/29

Poly1305

前回、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で移植できない環境に持っていくのは大変そうだ。

2017/04/28

ChaCha20が入っているライブラリ

お仕事で、ChaCha20というものが出てきた。
茶々?

リンクはここになっていた。
RFC 7539 - ChaCha20 and Poly1305 for IETF Protocols

stream cipherと書いてあるので、連続するデータをどんどん暗号化できるというものなのだろうか?

ストリーム暗号 - Wikipedia

ああ、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

2017/04/25

[et]EthereumはJavaScriptがわからないとつらかった

仕事ではほとんど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/

このくらいできないと、ブロックチェーン技術者になれないのだろうか・・・。