Using liboqs supported algorithms in the fork

If an algorithm is provided by liboqs but has not been listed as being supported by OQS-OpenSSH it can still be used/activated via the mechanism documented below.

Code Generation

The oqs-template folder contains a mechanism by which the code to add and activate new key-exchange or digital signature algorithm(s) is automatically generated and inserted at the appropriate locations in the OpenSSH code base.

1. • If support for a new algorithm/variant is required, add the algorithm to oqs-template/generate.yml, following the conventions by which the other algorithms have been specified.
   • If a signature algorithm variant that is disabled by default is to be enabled, simply change the enable value of that variant in oqs-template/generate.yml from false to true, keeping in mind that at most 64 variants can be enabled at a time.
   • Due to technical limitations in the upstream code (maximum number of supported algorithms, typically at a power-of-2 boundary), it may be necessary to disable currently enabled algorithms when enabling algorithms; a typical indication for this is compilation errors after only enabling an algorithm as per these instructions. The safest approach is to disable one algorithm for each new algorithm enabled.

2. From the project root directory, run python3 oqs-template/generate.py, and re-build the fork.

3. Run the fork, with <KEX> and <SIG> taking values as follows:

• If the new algorithm is a digital signature algorithm, <SIG> is the value specified in the name field in the oqs-template/generate.yml file, with all alphabetic characters in lowercase and underscores removed (e.g. if "name" is SPHINCS_HARAKA_128F_ROBUST, then <SIG> is sphincsharaka128frobust)
• If the new algorithm is a key-exchange algorithm, <KEX> is the value specified in the ssh_name field in the oqs-template/generate.yml without the sha384 suffix (e.g. if name is ntru-hps-2048-677-sha384 then <KEX> is ntru-hps-2048-677)