Keygrip broken in master for cv25519
Closed, ResolvedPublic


Yesterday I switched to the current Libgcrypt master and this morning I realized that I was not anymore able to decrypt mails addressed to me. The reason is a change in the computation of the keygrip vor cv25519. This regression was part of commit rGc3f39b6b55db618f77e983125072081c15bfbdd6 which came with the comment

  • cipher/ecc-curves.c (domain_parms): Fix as the errata of RFC.

The errata is which changed the y coordinate of the base point:

The Montgomery form of the curve is generally used with a ladder, where the v coordinate is unused and   unspecified. Thus I picked the smaller of the two possible values for v.

However, the curve is birationally equivalent to edwards25519, where both coordinates of the base point are used and are already in widespread use. Sadly, picking the smaller of the values for v ends up mapping to the negative of the base point on edwards25519.

This change replaces v with -v so that it matches up.

As stated in the description it does not matter for our purpose and keeping the keygrip the same is obviously more important than a correct parameter description. The simplest way to fix that would be to revert the change. Another option will be a dedicated keygrip computation for that curve.

werner created this task.Sep 28 2019, 10:56 AM
werner lowered the priority of this task from Unbreak Now! to Normal.Sep 28 2019, 11:08 AM
werner added projects: libgcrypt, Bug Report.
gniibe claimed this task.Oct 1 2019, 7:17 AM
gniibe added a subscriber: gniibe.

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

For possible fix which can have correct value, we can do something similar as negative value (a, b) in ed25519 curve.
We change the parameters in _gcry_ecc_fill_in_curve for the curve. I think that we can only use incorrect value for keygrip computation. Let me try.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

gniibe closed this task as Resolved.Nov 16 2020, 8:08 AM