secmem limits for PQC schemes

[Falko Strenzke]

We are currently working on the implementation of the "CRYSTALS" schemes 
Kyber
and Dilithium (SPHINCS⁺ to follow soon) in Libgcrypt. In this course we came
across a problem with the secure memory [^1] management in Libgcrypt. 
Namely,
the current hard limit for secure memory is 32kB. That seems to be a 
reasonable
default value as there are apparently indeed OSs which have limits for 
locked in
this domain.  However, the heap memory requirements for the largest 
parameter
sets of the CRYSTALS schemes are
- Kyber 33,376 bytes (key generation)
- Dilithium 135,968 bytes (probably also key generation, but not 
determined yet)

For Kyber we could possibly increase the default pool size to still 
reasonable
64kB. But in the case of multiple threads using Kyber operations this 
will still
not suffice.

This raises the question of how to deal with this limitation. When the 
secure
memory pool set up with the default size is exhausted, even in non-FIPS 
mode,
further requests for secure memory fail. This is not ideal, since many 
modern
systems will provide much higher margins for lockable memory.

So one possibility I see is to
- implement an allocation function for the CRYSTALS schemes that first 
tries to
   allocate secure memory and if that fails, and FIPS mode is not 
activated, then
   simply allocates non-secure memory
- possibly rework the secure memory management so that it tries to lock 
further
   memory blocks when secure memory is requested after the initially set 
up pool
   is exhausted. For instance on my Debian 11 x86 for instance I have 
limit of 4
   MB for locked memory, thus allowing to exceed the rather pessimistic 
default
   value by orders of magnitude.

The Libgcrypt core developers please let us know their thoughts 
regarding these
issues.


[^1]: i.e. heap memory that is protected from being swapped (locked 
memory) to
disk and overwritten when freed

-- 

*MTG AG*
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.strenzke at mtg.de
Web: mtg.de <https://www.mtg.de>


*MTG Exhibitions – See you in 2023*

------------------------------------------------------------------------
<https://community.e-world-essen.com/institutions/allExhibitors?query=true&keywords=mtg> 
<https://www.itsa365.de/de-de/companies/m/mtg-ag>

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230803/119017fe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yWPupc80CWA8GrDP.png
Type: image/png
Size: 5256 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230803/119017fe/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wjsdBueg0xHvmEfQ.png
Type: image/png
Size: 4906 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230803/119017fe/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4764 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230803/119017fe/attachment-0001.bin>