Mailing List Archive

Baptiste Beauplat wrote:
> I noticed that the key size reported by gpg --with-colons for ECC keys
> (ed25519) have changed from 256 to 255.

Thank you for sharing. I didn't know that it is exposed to users.
(I considered it were (only) internal thing in libgcrypt.)

> I was wondering if that's a bug, since from what I understand (certainly
> way to little) the public key size of ed25519 is fixed at 256 and the
> value 255 is only used in the prime number calculation (2^255 - 19).
>
> Note: The changed comes from the following commit in libgcrypt:
>
> https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d

Yes, I did it.

Let me explain the reason why I did.

It is certainly a "fix", from the viewpoint of the library.

The field is NBITS, number of bits (of the curve). This information
(exact number of bits, instead of rounded one to 2^n) is needed. For
example, in the computation of X25519, it needs to check if there are
more bit(s) in octet. Besides, for other curves, this field is used in
this semantics (See NIST P-521).
--

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Baptiste,

usually the bit length of the characteristic /p /of the finite field,
where all the coordinate computationa are made, is taken as the key
length. And whereas this bit length of the prime for the NIST curve
P-256  is 256 , it is 255 for Curve25519. Therefore the key length value
is correct, despite the public key has a bitlength of 256.

/Ann.

Am 2021-09-15 um 20:30 schrieb Baptiste Beauplat via Gnupg-users:
> Hi,
>
> I noticed that the key size reported by gpg --with-colons for ECC keys
> (ed25519) have changed from 256 to 255.
>
> For instance, on my key I previously got:
>
> $gpg --with-colons -k lyknode@cilg.org | grep pub | cut -d : -f 3
> 256
>
> While now the result is:
>
> $gpg --with-colons -k lyknode@cilg.org | grep pub | cut -d : -f 3
> 255
>
> I was wondering if that's a bug, since from what I understand (certainly
> way to little) the public key size of ed25519 is fixed at 256 and the
> value 255 is only used in the prime number calculation (2^255 - 19).
>
> Note: The changed comes from the following commit in libgcrypt:
>
> https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d
>
> Best,
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi Yutaka,

On 2021/09/17 03:30 PM, NIIBE Yutaka wrote:
> Baptiste Beauplat wrote:
> > I noticed that the key size reported by gpg --with-colons for ECC keys
> > (ed25519) have changed from 256 to 255.
>
> Thank you for sharing. I didn't know that it is exposed to users.
> (I considered it were (only) internal thing in libgcrypt.)
>
> > I was wondering if that's a bug, since from what I understand (certainly
> > way to little) the public key size of ed25519 is fixed at 256 and the
> > value 255 is only used in the prime number calculation (2^255 - 19).
> >
> > Note: The changed comes from the following commit in libgcrypt:
> >
> > https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d
>
> Yes, I did it.
>
> Let me explain the reason why I did.
>
> It is certainly a "fix", from the viewpoint of the library.
>
> The field is NBITS, number of bits (of the curve). This information
> (exact number of bits, instead of rounded one to 2^n) is needed. For
> example, in the computation of X25519, it needs to check if there are
> more bit(s) in octet. Besides, for other curves, this field is used in
> this semantics (See NIST P-521).

Thank you for clarifying this.

If I understood correctly, my problem comes from the fact that the size
of the public key isn't strictly equal to NBITS however that's the
value used in the frontend part.

In that case, I'll open a bug against gnupg itself.

--
Baptiste Beauplat - lyknode