From 0fb5dbc39cd8db6145fddfe4a471e556edd77de5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Meusel?= Date: Thu, 13 Jun 2024 14:45:24 +0200 Subject: [PATCH 1/4] Since Botan 3.0 PointGFp is called EC_Point --- docs/cryptodoc/src/05_03_ecc.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/cryptodoc/src/05_03_ecc.rst b/docs/cryptodoc/src/05_03_ecc.rst index ac4dc4d7..a28ccf00 100644 --- a/docs/cryptodoc/src/05_03_ecc.rst +++ b/docs/cryptodoc/src/05_03_ecc.rst @@ -100,11 +100,11 @@ For efficiency purposes Botan uses Jacobian projective coordinates for all elliptic curve points and point operations as described in [ISO-15946-1]_ with the line at infinity defined as ``[0,Y,0]``. The affine coordinates can be obtained by using the conversion -functions ``PointGFp::get_affine_x()`` and ``PointGFp::get_affine_y()``. +functions ``EC_Point::get_affine_x()`` and ``EC_Point::get_affine_y()``. -The function ``PointGFp::get_affine_x()`` operates as follows. +The function ``EC_Point::get_affine_x()`` operates as follows. -.. admonition:: ``PointGFp::get_affine_x()`` +.. admonition:: ``EC_Point::get_affine_x()`` **Input:** @@ -126,9 +126,9 @@ The function ``PointGFp::get_affine_x()`` operates as follows. 3. Otherwise compute affine ``x`` coordinate as :math:`\frac{X}{Z^{2}}`. -The conversion function ``PointGFp::get_affine_y()`` performs the following steps. +The conversion function ``EC_Point::get_affine_y()`` performs the following steps. -.. admonition:: ``PointGFp::get_affine_y()`` +.. admonition:: ``EC_Point::get_affine_y()`` **Input:** From 5fcdd917552ba4a434a27399bd140ca750ce09d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Meusel?= Date: Thu, 13 Jun 2024 14:46:54 +0200 Subject: [PATCH 2/4] FIX: sampling of k is described in TR-03111 ... TR-02102-1 simply refers to the other TR. --- docs/cryptodoc/src/05_03_ecc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cryptodoc/src/05_03_ecc.rst b/docs/cryptodoc/src/05_03_ecc.rst index a28ccf00..a82cb1ce 100644 --- a/docs/cryptodoc/src/05_03_ecc.rst +++ b/docs/cryptodoc/src/05_03_ecc.rst @@ -329,7 +329,7 @@ The signature generation algorithm works as follows: the algorithm terminates with an error. **Remark:** If Botan is built with the RFC6979 module, it implements -deterministic ECDSA signatures, which are not covered by [TR-02102-1]_. In +deterministic ECDSA signatures, which are not covered by [TR-03111]_. In this case the implemented ECDSA signature algorithm is not [FIPS-186-4]_ conform. However, the RFC6979 module is prohibited in the BSI module policy. From f86c635220fca85c27ed34877e681ea8baa54b8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Meusel?= Date: Thu, 13 Jun 2024 14:49:54 +0200 Subject: [PATCH 3/4] FIX: minor inconsistencies ECDSA: Verification checks the x-coordinate of the computed point, not the entire point. ECKCDSA: The public point is denoted by Q not q. --- docs/cryptodoc/src/05_03_ecc.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/cryptodoc/src/05_03_ecc.rst b/docs/cryptodoc/src/05_03_ecc.rst index a82cb1ce..0e90d466 100644 --- a/docs/cryptodoc/src/05_03_ecc.rst +++ b/docs/cryptodoc/src/05_03_ecc.rst @@ -361,7 +361,7 @@ The signature verification algorithm works as follows: 3. Compute :math:`w=s^{-1}\bmod n` 4. Compute :math:`v_1=m*w \bmod n` and :math:`v_2=r*w \bmod n` 5. Compute the point :math:`v=(x_1, y_1)=v_1*G+v_2*Q` with Shamir's trick [DI08]_. - 6. Return ``true`` if :math:`v \equiv r \bmod n` applies. ``false`` otherwise. + 6. Return ``true`` if :math:`x_1 \equiv r \bmod n` applies. ``false`` otherwise. ECKCDSA @@ -446,7 +446,7 @@ The signature verification algorithm works as follows: 1. Perform preliminary parameter checks and verifies that :math:`0 Date: Thu, 13 Jun 2024 14:50:05 +0200 Subject: [PATCH 4/4] FIX: typo --- docs/cryptodoc/src/05_03_ecc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cryptodoc/src/05_03_ecc.rst b/docs/cryptodoc/src/05_03_ecc.rst index 0e90d466..da41b23d 100644 --- a/docs/cryptodoc/src/05_03_ecc.rst +++ b/docs/cryptodoc/src/05_03_ecc.rst @@ -391,7 +391,7 @@ The signature generation algorithm works as follows: - ``m``: raw bytes to sign (the hash-code ``H`` in [ISO-14888-3]_, which is the truncated hash from the public key and message) - - EC_Privatekey with invers: ``d``, ``Q``, domain (curve parameters (first coefficient + - EC_Privatekey with inverse: ``d``, ``Q``, domain (curve parameters (first coefficient ``a``, second coefficient ``b``, prime ``p``), base point ``G``, ``ord(G) n``, cofactor of the curve ``h``) - ``rng``: random number generator