libgpg will have Kyber / FIPS 203 working soon (if the static build stops failing hard.)

SPHINCS+ / FIPS 205 should be available soon.

FALCON ...unknown FIPS draft TBA soon.

These are newer quantum resistant algorithms, and should be considered in your future maintenance cycle as they become available in the libraries.

NIST has some of the brightest minds in the world. When they suggest something, than one should probably take the advice very seriously. =3

My understanding is that NIST has like 2 cryptographers sitting in a closet somewhere. They're good cryptographers, but there isn't much of them.

One will find the pool of people that deal in esoteric problems tends to be rather small in every field. =3

NIST is basically the publishing arm of the NSA, so it really depends on whether the NSA is taking the "protect national information assets" or the "attack foreign information assets" part of its mandate more seriously from year to year.

NIST does a lot of really neat work outside of crypto standards. Judah Levine and all the other metrology folks are awesome. It's unfortunate that they get grouped together by comments like this.

Sorry, yes I only meant in the context of cryptography of course. NIST is a great organization and it's really a historical accident that they do anything with crypto.

What's libgpg? i only know libgpg-error and libgcrypt.

In general, the stable build usually requires:

gnupg 2.4.3

libassuan 2.5.6

libgcrypt 1.10.3

libgpgerror 1.47

libksba 1.6.5

npth 1.6

pinentry 1.2.1

However, the Kyber algorithm was only committed recently in libgcrypt 1.11.0, and will not build on some platforms due to an libassuan 3.0.1 issue.

Did you have additional details on when a working packaged set of dependencies will be available for static .a builds that support Kyber?

Have a great day =3

"Triple AES" sounds as something insecure if it is similar to triple DES. (Insecure in the sense of providing a small additional strength obtained with a big increase in the time and energy needed for encryption/decryption.)

Only amateurs would choose to implement a "Triple AES", so it is very likely that they will also write a buggy implementation. Triple DES has not been used because it was a good strengthening method, but only because it could be used with unmodified hardware modules designed for simple DES. When a cipher strengthening is done in software, there are much better methods.

The best way to strengthen AES above the standard AES-256 is to double the block length from 128 bits to 256 bits. Increasing the key length over 256 bits is much less useful, because the key length is not the weakest point of AES-256. A 256-bit key is strong enough even against quantum computers, but short 128-bit blocks can be a vulnerability in certain applications. The key schedule algorithm of AES, which converts the cipher key into a set of round keys, is mediocre, so the length of the cipher key is the least important concern about the strength of AES.

The original Rijndael proposal had a stronger variant with 256-bit blocks, which has not been retained in the standard. Nevertheless, it is easy to implement it with the Intel/AMD AES instructions or with the Arm Aarch64 AES instructions. Intel has even published an application note describing how to do this, when the AES instructions have been introduced in the Westmere CPUs.

After increasing the block length, increasing the number of rounds can provide additional strengthening. Another choice would be to replace the standard key schedule algorithm with a stronger non-standard algorithm (i.e. one providing more random round keys). Increasing the key over 256 bits provides a much less useful strengthening in comparison with the cost required for executing the additional necessary operations.

That was pretty much my feedback at the time a well. AES-256 is more than adequate to store some secret data.