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()だから、反転をしているのだと思うのだ。

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