Unknown algorithm ml-kem-512 on MacOS x86_64 with openssl-3.5

[quarckster]

I build openssl on MacOS using the following commands:

./config
make

After that I build perftools using cmake:

cmake -S . -B . -DOPENSSL_ROOT_DIR=$HOME/openssl-3.5
cmake --build . --config Release

Then I run newrawkey:

DYLD_LIBRARY_PATH="/Users/perf/openssl-3.5/" ./newrawkey -t -a ml-kem-512 16
Unknown algorithm ml-kem-512

This issue is not reproduced on MacOS x86_64 with openssl-master and MacOS M1 with both openssl-3.5 and openssl-master.

[levitte]

With CMake, you say $HOME/openssl-3.5. With newrawkey, you say /Users/perf/openssl-3.5/. Are they the same?

Also, the latter is probably wrong, I suspect the .dylib files are in a subdirectory, like 'lib', so I'm gonna guess that this will work better for you:

$ DYLD_LIBRARY_PATH="/Users/perf/openssl-3.5/lib" ./newrawkey -t -a ml-kem-512 16

[quarckster]

dylib files are in the openssl root.

[Sashan]

the problem seems to be caused by some change in cmake. My Mac-book has cmake 3.30 and it is doing the right thing:
'''
Mac:source sashan$ cmake -S . -B build -DOPENSSL_ROOT_DIR=/Users/sashan/work.openssl/openssl.binaries/openssl-master
-- The C compiler identification is AppleClang 17.0.0.17000013
-- The CXX compiler identification is AppleClang 17.0.0.17000013
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /Users/sashan/work.openssl/openssl.binaries/openssl-master/lib/libcrypto.dylib (found version "3.6.0")
-- Configuring done (0.6s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/sashan/work.openssl/perftools/source/build
Mac:source sashan$ cmake --version
cmake version 3.30.0
'''
Not the line 'Found OpenSSL:' in output above, it tells the build is going to use openssl library found at desired location

[Sashan]

and this is what happens on mac-mini I got from @quarckster

w-mac-mini-intel-2:source sashan$ cmake -S . -B build-3.5 -DOPENSSL_ROOT_DIR=/home/sashan/work.openssl/openssl.binaries/openssl-3.5
-- The C compiler identification is AppleClang 13.0.0.13000029
-- The CXX compiler identification is AppleClang 13.0.0.13000029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /usr/local/Cellar/openssl@3/3.3.1/lib/libcrypto.dylib (found version "3.3.1")
-- Configuring done (1.2s)
-- Generating done (0.1s)
-- Build files have been written to: /Users/sashan/work.openssl/perftools/source/build-3.5
w-mac-mini-intel-2:source sashan$ cmake --version
cmake version 4.1.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

The Found OpenSSL line just tells us the build is going to use openssl libraries found in package installed on system, it iginoes -DOPENSSL_ROOT_DIR completely. version 3.3 comes with no PQ crypto so things make sense.

Also note the different cmake versions might be red herring as I use brew packages on my macos. the brew installed openssl package but it does not seem to be discovered by cmake.

at the moment I have no idea how to explain cmake to ignore openssl package found on system. those feels like some unfortunate glitch on mac-mini.

[Sashan]

OK so the problem with cmkake using a openssl from package installed on system was caused by wrong path I've used at cmake command line. It was:

cmake -S . -B build-3.5 -DOPENSSL_ROOT_DIR=/User/sashan/work.openssl/openssl.binaries/openssl-3.5

but it should be:

cmake -S . -B build-3.5 -DOPENSSL_ROOT_DIR=/Users/sashan/work.openssl/openssl.binaries/openssl-3.5

s/User/Users did the trick. but I'm still not out of the forest yet. the build is still using header files from system package which is openssl 3.3. Old headers disable ml-kem in newrawkey tool. How do I know? because if I patch newrawkey file with diff below:

diff --git a/source/newrawkey.c b/source/newrawkey.c
index 3b380a9..26fae15 100644
--- a/source/newrawkey.c
+++ b/source/newrawkey.c
@@ -30,6 +30,7 @@ OSSL_TIME max_time;
 enum {
     ALGO_X25519,
 #if OPENSSL_VERSION_NUMBER >= 0x30500000L
+#error " O H   N O "
     ALGO_ML_KEM_512,
     ALGO_ML_KEM_768,
     ALGO_ML_KEM_1024

build still passes.So the OPENSSL_VERSION_NUMBER must be coming from openssl package headers and not from OPENSSL_ROOT_DIR location.

EDIT adding otool output:

w-mac-mini-intel-2:source sashan$ otool -L build/newrawkey 
build/newrawkey:
        /Users/sashan/work.openssl/openssl.binaries/openssl-3.5/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /Users/sashan/work.openssl/openssl.binaries/openssl-3.5/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

[Sashan]

after including openssl/opensslv.h I could get it working on that mac-mini. I have no idea how does it come other systems are happy without this oneliner. newrawkey output wiht #45 applied:

w-mac-mini-intel-2:source sashan$ ./build/newrawkey -a ml-kem-512 1
Average time per EVP_PKEY_new_raw_public_key_ex() call for algorithm ML-KEM-512: 12.995316us

[t8m]

What are the actual cc invocation command lines when building perftools? We need to avoid building and linking against the system openssl installation. cmake needs to be properly adjusted to avoid looking for the system openssl installation if OPENSSL_ROOT_DIR is defined. Otherwise we are just creating a mess with the build.

[quarckster]

Here is the "make VERBOSE=1" output

[ 55%] Building C object CMakeFiles/newrawkey.dir/newrawkey.c.o

/usr/bin/cc  -I/Users/dmitry/perftools-openssl-3.5/source -isystem /Users/dmitry/openssl-3.5/dist/include  -MD -MT CMakeFiles/newrawkey.dir/newrawkey.c.o -MF CMakeFiles/newrawkey.dir/newrawkey.c.o.d -o CMakeFiles/newrawkey.dir/newrawkey.c.o -c /Users/dmitry/perftools-openssl-3.5/source/newrawkey.c

[ 58%] Linking C executable newrawkey

/usr/local/bin/cmake -E cmake_link_script CMakeFiles/newrawkey.dir/link.txt --verbose=1

/usr/bin/cc -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/newrawkey.dir/newrawkey.c.o -o newrawkey  libperf.a /Users/dmitry/openssl-3.5/dist/lib/libssl.dylib /Users/dmitry/openssl-3.5/dist/lib/libcrypto.dylib

[ 58%] Built target newrawkey

/Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/rsasign.dir/build.make CMakeFiles/rsasign.dir/depend

cd /Users/dmitry/perftools-openssl-3.5/source/build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /Users/dmitry/perftools-openssl-3.5/source /Users/dmitry/perftools-openssl-3.5/source /Users/dmitry/perftools-openssl-3.5/source/build /Users/dmitry/perftools-openssl-3.5/source/build /Users/dmitry/perftools-openssl-3.5/source/build/CMakeFiles/rsasign.dir/DependInfo.cmake "--color="

/Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/rsasign.dir/build.make CMakeFiles/rsasign.dir/build

[t8m]

/usr/bin/cc -I/Users/dmitry/perftools-openssl-3.5/source -isystem /Users/dmitry/openssl-3.5/dist/include -MD -MT CMakeFiles/newrawkey.dir/newrawkey.c.o -MF CMakeFiles/newrawkey.dir/newrawkey.c.o.d -o CMakeFiles/newrawkey.dir/newrawkey.c.o -c /Users/dmitry/perftools-openssl-3.5/source/newrawkey.c

Assuming /Users/dmitry/openssl-3.5/dist/include contains openssl/opensslv.h and -isystem works as expected, the ML-KEM-512 should be available.

[t8m]

I wonder what would happen if -I was used instead of -isystem.

[quarckster]

I found if I run newrawkey in this way:

DYLD_LIBRARY_PATH=/Users/dmitry/openssl-3.5/dist/lib/ ./newrawkey -t 16 -a ml-kem-512

It shows the numbers.

Looks like something is wrong in argument parsing and the error message is very misleading.