2018/01/08

ECDSAの署名+αから公開鍵を算出したい (3)

では、今回は楕円曲線の署名がどういう計算をしているか見てみよう。
途中で挫折する可能性は大きいが、まずは見てみるのだ。


mbedTLSでは、この辺りになる。
https://github.com/ARMmbed/mbedtls/blob/development/library/ecdsa.c#L68

コメントに書いてあるSEC1は、これだろう(pdf)。
http://www.secg.org/sec1-v2.pdf

SEC1 4.1.3は、p.44の「4.1.3 Signing Operation」と思われる。
ここの1~7を実装しているということだろう。

Step4は、ハッシュを求める部分だが、これはAPIの引数でハッシュを求めた後の値を渡すようになっているので、それ以外を実装していることになる。


PDFとソースは一致してるんだろう、という前提で読むと、何をしているのかは分からないが、順番にやっているだけのようだ。
mbedtls_ecp_gen_keypair()でephemeral keypairの(k, R)が得られているのだが、f_rng()とp_rng()で変化を付けているのだろうか?
BitcoinではDeterministic signatureが推奨されているので、mbedtls_ecdsa_sign_det()を使っているのだが、f_rng()としてmbedtls_hmac_drbg_random()を使っているようだ。
だからまあ、うまいことやってくれているのだろう。


これとlibsecp256k1の署名処理を見比べると、何をやっているのかわかりやすくなるだろう。

まず、nonceは、kに当たるようだ。
rpがRで、それをbにして、sigrになっているようだ。
secp256k1_fe_normalize()がmod nで正規化する部分に相当しているのか。

で、このbからsigrにしているところでoverflowしているか取得して、それとr.yが奇数かどうかを判定してrecidを決定しているようだ。
最後は、署名がis_high()だったらrecidを1でxorしている。


ということは、何をやっているかはやはりわからなかったものの、最後のxorする材料はis_high()がTRUEのときの処理をする前じゃないと取得できないことになる。

PDFには、is_high()のようなチェックをすることは書かれていないので、sを求めるときのmod nが必要かどうかという判定になるのだろうか?
しかし、やっているのはsecp256k1_scalar_negate()だから、反転をしているのだと思うのだ。


参考にするのは別のライブラリがよいのかもしれんが、当てがないのよねぇ。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。