safecrypto / libsafecrypto Goto Github PK

... required for use in other projects

Add query function to obtain the string used to configure the library and a list of all the public-key schemes, block ciphers, stream ciphers, hash functions, XOFs and RNG's that are incorporated into the library. Eventually these will all be exposed to the user for use external to the library.

Functional code is present in the src/utils/entropy folder that previously used to work. The API has since changed and only None or Huffman are available for lossless compression. This should be added back and (hopefully) improved upon.

An ENS/DLP memory leak associated with Gaussian sampling and the Huffman encoder is generating very large symbols, overflowing the packet buffer.
To repeat any of the ENS or DLP signature functional tests can be repeatedly run. In a debugger the leak is traced back to the signature packer buffer not being allocated sufficient bits, indicating that the Huffman encoder has expanded (~double) the size of the signature. The rate of occurrence can be reduced by increasing either the buffer size or number of packed symbol bits. The problem appears to be fundamentally associated with KeyGen and/or Gaussian sampling over the lattice.

This has been disabled for some time. Fixing the issue has been deemed a low priority as BLISS-B-0 has a toy security level and should not be used in practice.

It is not at all clear if the memory has been allocated for sc->temp or not (and if it is big enough)?
At L1230, the memory in sc->temp is zeroed
SC_MEMZERO(t, 5 * n * sizeof(SINT32));
But I cannot find where the memory pointed to by sc->temp is allocated...

... in safecrypto_private.c

The two unit tests unit_poly_limb and unit_sc_poly_mpz fail on 32-bit Lubuntu 17.10 Desktop (native, not VM) with an Atom N270 (32-bit, single core). All other unit tests pass. Latest bleeding_edge build with 32-bit bug fixes was used.

Clean up the crypto and NTT folders, removing research type functions that are no longer used.

Existing countermeasures (Markku's blinding, Ziggurat pattern masking) need to be expanded as per discussions with Ayesha and from Seamus' Ziggurat work.

1. Markku's blinding will be modified to use an in-place Knuth shuffle to avoid shuffling after generation (as done now). This Knuth shuffle of a ring polynomial will also be provided as a "cheaper" option than Markku's technique - it must be constant-time.
2. Add an option to randomly discard samples at a user defined rate - to disturb statistical analysis.
3. An option will be added such that access to Gaussian LUTs will be randomly performed elsewhere in the crypto functions - perturbation to deter cache attack.
4. Where multiple Gaussian ring polynomials are generated simultaneously with the same statistical properties permit them to be randomly shuffled together - perturbation again.
5. If dynamic memory is used investigate the possibility of periodically moving LUTs to a different address.
6. Investigate the possibility of randomly changing the Gaussian sampler mechanism (e.g. switch from CDT to Ziggurat) when generating ring polynomials.
7. Investigate cleaning and expanding the previous work on multi-threaded BLISS-B where ring polynomials where generated by worker threads - displace power and time analysis by exploiting context switches, changing thread priorities, using different samplers, etc.

Disabling DLP-IBE, DLP signatures and ENS signatures disables support for multiple-precision arithmetic, both integer and floating-point. However, high-precision Gaussian sampling has recently been added to CDT which requires MP floating-point arithmetic.

To recreate a build error you must disable GMP and MPFR and the three schemes above ( --disable-gmp --disable-mpfr --disable-ibe-dlp --disable-sig-dlp --disable-sig-ens). The configure.ac script disables support for MP arithmetic (WITH_ARITH_MP), but the CDT Gaussian sampler requires it causing a linker error.

To fix: (a) provide a dedicated configure switch to enable support for high-precision Gaussian sampling (may not be wanted on microcontrollers), (b) separate WITH_ARITH_MP into integer and floating-point variants, (c) ensure that libgmp and libmpfr are linked as necessary, (d) modify the CDT sampler to enable/disable high-precision sampling during compilation.

If WP5 HW is using Trivium anywhere that requires its identical use in another implementation it should be added to WP6 SW with a low priority.

Will be added in a future version after academic publication.

Kyber has not received sufficient attention and it's performance can be further optimized.

Neil - I am concerned about this comment! The 'f' array and the 'g' array are contiguous, but the 'g' portion follows on from the 'f' portion. The loop is counting backwards from the maximum value of 'i', which looks like it should be the size of 'f' - so what is the relevance of the comment about 'g'?

Problem discovered in 3rd party integration that did not specify any flags to the create function.

1. Dilithium fails if the default system calls are used to provide a PRNG (i.e. the user does not specify a PRNG with the safecrypto_create() flags parameter), if the user specifies any other PRNG it functions correctly.
2. No other schemes are affected.
3. The Dilithium testbenches use AES CTR DRBG and are unaffected.

Until resolved, it is recommended that a specific PRNG is used.

NOTE: A default PRNG other than SC_PRNG_SYSTEM should be used - the system rand() calls are for research purposes only and should not be used in the real world. System rand() calls should NOT be the default option in any fix.

GNU GMP is currently the default but optional choice to support DLP IBE, DLP signatures and ENS signatures. Native MP arithmetic can be used instead and is fully functional in order to avoid use of the copyleft GPL license of GMP.

However, it's performance isn't great - specifically the mpn_mul() function is quite naive. For example, it accounts for 60% of a DLP KeyGen() when profiled - when optimized this should bring the native solution within range of GMP performance. This has started with a half-complete Karatsuba multiplier that is currently disabled.

Also, when analyzing compiler decisions the sc_mpn.c source is not using auto-vectorization where it should be possible.

After I build the docker file, I found that it needs to install zip package.
However, I get the following error message after exec apt-get install zip

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

How to solve it?
Thanks!

There are a handful if conditional statements in the periphery functions that shoul dbe modified for constant-time operation.

Huffman decoder operates iteratively on bits, at the cost of RAM this can be modified to peek ahead into the bit buffer and decode against a table.

In preparation for the native solution the detection of GMP and MPFR by the configure script should be automated - MPFR doesn't appear to be detected and later causes a build error with make.

The correct behavior at the moment should be to fail the configure script and give an error statement if MPFR is not detected and GMP is enabled (this is either by default or explicitly using "--enable-gmp").

Support for Mac OSX may be added in future, Sarah is currently going through the pain of trying to build it. Biggest issues seem to be system calls for random and time functions.

Specific ARM implementations of any components are very limited and should be expanded to complement the Intel AVX2 intrinsics already in place for NTT/reduction arithmetic.

The MPFR version of "sc_mpf" is fully functional. To date only the CDT sampler has been modified to provide a 128-bit version. This should be expanded to other samplers and increased precision offered in line with that suggested by the configuration flags "SC_FLAG_0_SAMPLE_192BIT" and "SC_FLAG_0_SAMPLE_256BIT" in safecrypto.h.

Add the ability to pack 64-bit arrays into a byte stream, as well as 32, 16 and 8.

2-way forward secure AKE is currently supported with any Signature scheme and KEM in the func_alg_2way_ake test. This code is a little tedious and tricky to test, so it should be integrated with the API for ease of use.

Compilation functions, but a half dozen unit tests fail, principally due to incorrect casting of types.

Currently available by dynamically linking against MPFR (copyleft license), this is disabled using the "--disable-gmp" switch with configure (enabled by default). Currently only used with the 128-bit Gaussian sampler.

Just started work on a native version, only get and set functions have been added. A native version will also allow easier implementation on baremetal or obscure systems where GMP is not available.

Requires some sort of integration with the more commonly available IEEE754 type available in gcc, i.e. "__float128" and the quadmath.h header, and provided by src/utils/arith/sc_mpf128.c. While this only gives 112-bit precision (113 bits including the hidden leading one) it may be optimized on certain platforms.

the code at line 105 clears the flag value set in the preceding lines (92-103), such that Huffman and BAC compression are not tested...

configure_output.txt
test-suite.log

func_alg_dlp_ibe fails for parameter set 2, decrypted message mismatch

Hello together,

Thank you for this library! I am currently trying to cross-compile the library for an ARM Cortex-M4 device on Ubuntu 20 x86_64 with this command:
./configure --host=arm-none-eabi --prefix=$TOOLCHAIN --without-tests --disable-multithreading CFLAGS="-mcpu=cortex-m4 -mthumb -mfpu=neon -O2 -falign-functions=16 -ffunction-sections -fdata-sections --specs=nosys.specs"

But I get the following error:
./configure: line 13266: syntax error near unexpected token `-mfpu=neon,'

./configure: line 13266: ` AX_CHECK_COMPILE_FLAG(-mfpu=neon, ax_cv_support_neon_ext=yes, )'

Is there anything that I am missing or doing wrong?

Best regards
Alex

Some schemes use different modulus, sigma's and constants for different parameters sets, consuming storage/ROM (e.g. Ring-TESLA, ENS Signatures, DLP IBE, hardcoded Gaussian sample tables).

To reduce the size of the library it should be possible to somehow disable parameter sets that are not required. This should be done preferably using configure/Autotools, but specific preprocessor defines may be more suitable as a lot of switches may be required.

• without MPFR but with GMP the build fails
• without MPFR and without GMP several tests segfault

Memory leak checking currently requires manual checking using the functional test programs using Valgrind. There are scripts within Autotools to automate this process - this needs to be investigated and used if feasible.