<div dir="ltr"> Hello all, At the UNH Community Lab, we are now running CI testing for cryptodev validation using the FIPS sample application. In setting up testing we have run into issues with the sample app documentation being out of date. In places it points to dependency versions which do not work with the sample app, and we are also seeing the sample application failing to run on some of the supported test vectors. We hope to start a conversation about these issues with interested community members responsible for maintaining cryptodev functions in DPDK and the FIPS sample application. If desired, we could produce an updated setup guide according to how we’ve set up our environment. But, others who are more involved in developing the sample app may want to provide their own input. We are grateful for any feedback to us or development of the sample app which may come out of this conversation. A synopsis of our experience using the FIPS sample app is below. Issues with current documentation for IPsec-mb library: According to the current test plan documentation for how to utilize the DPDK FIPS Validation Application (<a href="https://git.dpdk.org/tools/dts/tree/test_plans/fips_cryptodev_test_plan.rst">https://git.dpdk.org/tools/dts/tree/test_plans/fips_cryptodev_test_plan.rst</a>), it is recommended that you pull from the intel-ipsec-mb github repository and then checkout a specific commit (noted as “latest working commit”). The commit it recommends using in this documentation is a few commits after the version tagged “v0.50” however, when trying to build DPDK using this version of the library, it reports that it does not support any version older than “1.0.0”. When using the documented version of the library, you also do not get access to the virtual crypto device that is used in the examples on this page. There is also the DPDK user guide for the application (<a href="https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html" style="color:rgb(0,0,128)">https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html</a>) and this guide does not list any of those same prerequisites, but when building DPDK without said prerequisites, you receive the driver warning crypto/ipsec_mb: missing dependency, "libIPSec_MB”. There is a different crypto device used in the examples on this user guide (crypto_aesni_mb) but if you do build the IPsec library from github, on the “0.50” version you don’t get access to this device. However, if you instead build the IPsec library on the latest tagged version (v1.3) you can run the sample application using the crypto device that is mentioned on this page. Even with being able to run the sample application on the latest version, not all supported algorithms pass, there are a few algorithms listed as supported that return a failed verdict. It is unclear which steps should be followed and which parts are accurate as it seems some pieces of each form of documentation are true while others are outdated. Other things to note: There are other algorithms that pass on some hosts, but fail on others. Using an ubuntu 20.04 container, on some hosts, validation of AES-GCM algorithms works and returns a passing verdict. However, running inside the same container on our production hosts, these algorithms fail with the message “CipherText was not present in the TestCase.” There was recently a <a href="http://mails.dpdk.org/archives/test-report/2023-February/350635.html" style="color:rgb(0,0,128)">patch</a> put out to fix the AES-GCM validation, however we are seeing it fail to compile with DPDK. All algorithm testing listed below was performed using the “crypto_aesni_mb” virtual device on version 1.3 of the ipsec library List of working algorithms: <ul> <li> AES-CBC </li><li> AES-CMAC </li><li> AES-CTR </li><li> AES-GMAC </li><li> HMAC-SHA1 </li><li> TDES-CBC </li></ul> List of failing algorithms: <ul> <li> AES-GCM <ul> <li> “CipherText missing from TestCase” </li><li> This failure message is found in the verdict returned from the ACVP API </li></ul> </li><li> AES-XTS <ul> <li> “ACVP-AES-XTS-2.0: General exception. Contact service provider.” </li><li> This failure happens before reaching DPDK application so likely a NIST problem </li></ul> </li><li> SHA-1 <ul> <li> “Digests do not match” </li><li> This failure message is found in the verdict returned from the ACVP API </li><li> Passes some test cases but fails others </li></ul> </li><li> SHA-256 <ul> <li> “Digests do not match” </li><li> This failure message is found in the verdict returned from the ACVP API </li><li> Like SHA-1, fails some but passes others </li></ul> </li><li> TDES-ECB <ul> <li> “USER1: Failed to get capability for cdev 0” </li><li> “USER1: Error -22: test block” </li><li> These errors are encountered during the validation phase (i.e., when the vectors are being run through the DPDK sample application) </li></ul> </li></ul> Untested algorithms: <ul> <li> RSA </li><li> ECDSA </li></ul><div> </div>-- <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Patrick RobbTechnical Service ManagerUNH InterOperability Laboratory21 Madbury Rd, Suite 100, Durham, NH 03824<a href="http://www.iol.unh.edu/" style="color:rgb(17,85,204)" target="_blank">www.iol.unh.edu</a> <img src="https://lh4.googleusercontent.com/7sTY8VswXadak_YT0J13osh5ockNVRX2BuYaRsKoTTpkpilBokA0WlocYHLB4q7XUgXNHka6-ns47S8R_am0sOt7MYQQ1ILQ3S-P5aezsrjp3-IsJMmMrErHWmTARNgZhpAx06n2" width="150" height="37" style="border:none"></div></div></div>