[ssh_x509] is "key-shielding" ready for use ... or why do not use secure hardware?

[ssh_x509 at roumenpetrov.info]

Historical introduction:
NEXT: 17.1.2(?)
(*) allows building key-shielding on operating systems without memory 
mapped pages


(*) PKIX-SSH 16.0, 8 Mar 2025
allows key-shielding to be enabled at build time


(*) PKIX-SSH 15.3, 3 Oct 2024
place shielded keys into memory excluded from a core dump

Note key-shielding is not enabled by default. Limited to Linux and *BSD.


(*) PKIX-SSH 12.3, 13 Oct 2019
"key shielding" feature

Not enabled by default as key stored on secure device has better protection.

///https://gitlab.com/secsh/pkixssh/-/commit/b1c2bb5c4c2f4a36a46d872a1ae40f874ca40d03


++++

As is visible "key-shielding" functionality is added to PKIX-SSH before 
5 years.
For protocol functionality uses aes256-ctr cipher.

The release 15.3 (excluded from a core dump) limits functionality to 
Linux and *BSD.

What means "allow" in PKIX-SSH 16.0?
Functionality is considered experimental and before this release code 
has line:
#undef USE_SSHKEY_SHIELDING

So, after 16.0 release functionality could be activated at configuration 
time with preprocessor directive:
CPPFLAGS="-DUSE_SSHKEY_SHIELDING ..." ../configure ....


Upcoming release avoids "core dump" limitation.

Should project activate "key-shielding" by default?


++++

Daemon host-keys are stored unprotected on disk. So why to protect them 
in memory?

It seem to me functionality does not impacted use of secure-token. 
Tested wit current code base.

PKIX-SSH support TPM keys (either by store or by engine).
PKIX-SSH support PKCS#11 interface (direct, by store, by engine).

To protect client keys use secure device.


++++

Conclusion:
I cannot see reason to add option to configuration script that allows 
user to activates functionality.


Regards,
Roumen Petrov