Mailing List Archive

[PATCH] cipher: Add Classic McEliece mceliece6688128f.
Hi

This patch adds Classic McEliece mceliece6688128f based on the public
domain libmceliece code. What do you think?

jas@kaka:~/src/libgcrypt$ tests/t-kem --mceliece6688128f --loops 100 --verbose
t-kem: Checking KEM.
t-kem: 100 tests done
t-kem: All tests completed in 29540ms. Errors: 0
jas@kaka:~/src/libgcrypt$ tests/t-kem --sntrup761 --loops 100 --verbose
t-kem: Checking KEM.
t-kem: 100 tests done
t-kem: All tests completed in 6530ms. Errors: 0
jas@kaka:~/src/libgcrypt$

/Simon
Re: [PATCH] cipher: Add Classic McEliece mceliece6688128f. [ In reply to ]
On Tue, 30 Jan 2024 10:20, Simon Josefsson said:

> This patch adds Classic McEliece mceliece6688128f based on the public
> domain libmceliece code. What do you think?

Seems people want that.

- I think the name is too long, we should find an abbreviation.
- C++ comments neeed to be remoced
- __attribute__ need to be removed or replaced by GGPRT macros.
- Probably other cleanups.

Gniibe has some experience with that. However, Kyber has higher
priority right now.


Salam-Shalom,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: [PATCH] cipher: Add Classic McEliece mceliece6688128f. [ In reply to ]
Hello,

Let us apply the patch of Classic McEliece mceliece6688128f.

(Personally, I need to do this before adding more curves to ECC KEM.)

On Tue, 30 Jan 2024 10:20 +0100, Simon Josefsson wrote:
> This patch adds Classic McEliece mceliece6688128f based on the public
> domain libmceliece code. What do you think?

On Tue, 30 Jan 2024 16:48 +0100, Werner Koch wrote:
> Seems people want that.

Indeed. It's good to have different one other than lattice based.

> - I think the name is too long, we should find an abbreviation.
> - C++ comments neeed to be remoced
> - __attribute__ need to be removed or replaced by GGPRT macros.
> - Probably other cleanups.

Let me do these changes after the first push of the patch.

Is there any good shorter name, or an abbreviation? Libgcrypt tries to
support building by older C compilers (< C99) for older systems. Older
compiler needs shorter name.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: [PATCH] cipher: Add Classic McEliece mceliece6688128f. [ In reply to ]
NIIBE Yutaka <gniibe@fsij.org> writes:

> Hello,
>
> Let us apply the patch of Classic McEliece mceliece6688128f.

Thank you.

> (Personally, I need to do this before adding more curves to ECC KEM.)
>
> On Tue, 30 Jan 2024 10:20 +0100, Simon Josefsson wrote:
>> This patch adds Classic McEliece mceliece6688128f based on the public
>> domain libmceliece code. What do you think?
>
> On Tue, 30 Jan 2024 16:48 +0100, Werner Koch wrote:
>> Seems people want that.
>
> Indeed. It's good to have different one other than lattice based.
>
>> - I think the name is too long, we should find an abbreviation.
>> - C++ comments neeed to be remoced
>> - __attribute__ need to be removed or replaced by GGPRT macros.
>> - Probably other cleanups.
>
> Let me do these changes after the first push of the patch.
>
> Is there any good shorter name, or an abbreviation? Libgcrypt tries to
> support building by older C compilers (< C99) for older systems. Older
> compiler needs shorter name.

Classic McEliece is abbreviated 'CM' in its specification document, so
s/MCELIECE6688128/CM6688128/g' is one approach.

Are pre-C99 compilers supported for real, or is this merely an obsolete
desired feature? Do you have any example of a pre-C99 compiler that can
build libgcrypt? I recall trying to get libgcrypt to build with tcc
long time ago and failed.

I think the names aren't unreasonable long, and if someone wants support
a pre-C99 compiler that can be achieved with a conditional #define
GCRY_KEM_MCELIECE6688128F GCRY_KEM_CM6688128F', couldn't it? But maybe
not worry about it until there is a known real use-case.

/Simon
Re: [PATCH] cipher: Add Classic McEliece mceliece6688128f. [ In reply to ]
Hi!

On Wed, 17 Apr 2024 11:57, Simon Josefsson said:

> Classic McEliece is abbreviated 'CM' in its specification document, so
> s/MCELIECE6688128/CM6688128/g' is one approach.

Good idea. I prefer easy to type names and the 6688128 is already long
enough ;-).

> Are pre-C99 compilers supported for real, or is this merely an obsolete
> desired feature? Do you have any example of a pre-C99 compiler that can

No, it is not obsolete and forces us to keep the code readable. It is
hard to test these days but things should be limited to what is really
needed. The __func__ macro and the __VA_ARGS__ are so useful that we
should allow them. But struct initializers and trailing commas are
problematic (older but still used AIX and HPUX compilers). //-comments
are a severe aesthetic annoyance.

> build libgcrypt? I recall trying to get libgcrypt to build with tcc
> long time ago and failed.

Charles H. Beebe used to test on all kinds of Unices.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: trailing comma compiler suuport (was: [PATCH] cipher: Add Classic McEliece mceliece6688128f.) [ In reply to ]
Werner Koch via Gcrypt-devel wrote:
> Hi!
>
> On Wed, 17 Apr 2024 11:57, Simon Josefsson said:
> [...]
>> Are pre-C99 compilers supported for real, or is this merely an obsolete
>> desired feature? Do you have any example of a pre-C99 compiler that can
>>
>
> [...] But struct initializers and trailing commas are
> problematic (older but still used AIX and HPUX compilers).

Wait... I thought trailing commas in initializer lists had always been
allowed, since the original K&R C, in order to facilitate tools that
generate C code. Is this incorrect or are those compilers outliers?
(To be fair, this is history for me---when C89 was published, I was not
old enough to type.)


-- Jacob

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: trailing comma compiler suuport [ In reply to ]
On Thu, 18 Apr 2024 21:10, Jacob Bachmeyer said:

> Wait... I thought trailing commas in initializer lists had always been
> allowed, since the original K&R C, in order to facilitate tools that
> generate C code. Is this incorrect or are those compilers outliers?

I always had this issue with HP compilers and some other compilers also
complain/warn about it. IIRC, even the crippled K&R cc installed by
default on HPUX, which you need to bootstrap gcc, has this problem. We
should find not too old reports in the bug tracker.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein