From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3566B41C8B; Mon, 13 Feb 2023 18:33:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 210A341151; Mon, 13 Feb 2023 18:33:06 +0100 (CET) Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by mails.dpdk.org (Postfix) with ESMTP id 61DC340EE4 for ; Mon, 13 Feb 2023 18:33:05 +0100 (CET) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-16df32f2ffdso5325566fac.1 for ; Mon, 13 Feb 2023 09:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=skEOw/YWaj1GSkeFqcTwiwxtsWIjkeTECFbMnSOYFbk=; b=B9iZp+J+Vdkpf2valywiXramNTeGjDP6DhE23a+gN2utREjpFLPZ91tj+EcoYVNq+F cdwsNBEfHNCQtMC2CdgiFacS0bt3UjAD/M216Nehei11/tXbCSU9m0UmwmLk2/gOsa7Q 0qSSU0Gudqoyov45WRmvCn7deAYH+CyHJeNfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=skEOw/YWaj1GSkeFqcTwiwxtsWIjkeTECFbMnSOYFbk=; b=AP7nO8gvRcfuMJxK+wb5NTqyBMCaZidoeDQcm69z/7QTsDa1zRCxMMlYWF68jDNyku bBUv2Wm8RkaUSTaQZ2v+1bWVoyM32HCKY59G8D3dV4igD46KwLZOOCZMl/kcnmvLvKqo Ria6JHRBiZX6MSYiF6rVsLBSYz9Ze2d/hP84dexMgVJx5IqFvb+q7EZ+ih//WWYEZIId 1Iwmfhn8PannOeZHyCa4GHTzCSj0lA/Je1KWuXP7GHm/8Orlz8O7iR8EJI4HgSBaLgas yTZxH3pfz9nc/RvvkLhxFBnIs2FGy42Q70bGRuKWY3tCsR6uUBA1oADyIxK8Zy4v1qXu lQBw== X-Gm-Message-State: AO0yUKXZFX7i5ZEdjDtyU/23KegTV3FVOO1uQRgtC1LA49pRZMhZtJIu w9PKu8zg6enSuyD/Xpw9HVH+jZlauT/to/9hlkXnmZMr75JyhC3a X-Google-Smtp-Source: AK7set+8pXK/0k5rAA/t0XAmcGT523AiHpMToRvhPq2u5f3kDmW8oBI5FHjnh/HknehceGU5iKt6qIOOfL3egfys3cY= X-Received: by 2002:a05:6870:fb8b:b0:16e:93a:2ae7 with SMTP id kv11-20020a056870fb8b00b0016e093a2ae7mr444423oab.269.1676309584360; Mon, 13 Feb 2023 09:33:04 -0800 (PST) MIME-Version: 1.0 From: Patrick Robb Date: Mon, 13 Feb 2023 12:32:53 -0500 Message-ID: Subject: Observed issues with the FIPS sample app To: dev@dpdk.org Content-Type: multipart/alternative; boundary="0000000000004f4c5705f4983d4c" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000004f4c5705f4983d4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99ve 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 ( https://git.dpdk.org/tools/dts/tree/test_plans/fips_cryptodev_test_plan.rst ), it is recommended that you pull from the intel-ipsec-mb github repository and then checkout a specific commit (noted as =E2=80=9Clatest working commi= t=E2=80=9D). The commit it recommends using in this documentation is a few commits after the version tagged =E2=80=9Cv0.50=E2=80=9D however, when trying to build DPDK u= sing this version of the library, it reports that it does not support any version older than =E2=80=9C1.0.0=E2=80=9D. When using the documented version of th= e 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 ( *https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html* ) 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=E2=80=9D.* There is a different crypto dev= ice used in the examples on this user guide (*crypto_aesni_mb*) but if you do build the IPsec library from github, on the =E2=80=9C0.50=E2=80=9D version you do= n=E2=80=99t 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 =E2=80=9CCipherText was not present in the TestCase.=E2=80=9D There= was recently a *patch* 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 =E2=80=9Ccrypto_aesni_mb=E2=80=9D virtual device on version 1.3 of the ipse= c library* *List of working algorithms*: - AES-CBC - AES-CMAC - AES-CTR - AES-GMAC - HMAC-SHA1 - TDES-CBC *List of failing algorithms*: - AES-GCM - =E2=80=9CCipherText missing from TestCase=E2=80=9D - This failure message is found in the verdict returned from the ACVP API - AES-XTS - =E2=80=9CACVP-AES-XTS-2.0: General exception. Contact service provide= r.=E2=80=9D - This failure happens before reaching DPDK application so likely a NIST problem - SHA-1 - =E2=80=9CDigests do not match=E2=80=9D - This failure message is found in the verdict returned from the ACVP API - Passes some test cases but fails others - SHA-256 - =E2=80=9CDigests do not match=E2=80=9D - This failure message is found in the verdict returned from the ACVP API - Like SHA-1, fails some but passes others - TDES-ECB - =E2=80=9CUSER1: Failed to get capability for cdev 0=E2=80=9D - =E2=80=9CUSER1: Error -22: test block=E2=80=9D - These errors are encountered during the validation phase (i.e., when the vectors are being run through the DPDK sample application) *Untested algorithms*: - RSA - ECDSA --=20 Patrick Robb Technical Service Manager UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 www.iol.unh.edu --0000000000004f4c5705f4983d4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=09 =09

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=E2=80=99ve 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.


Issu= es with current documentation for IPsec-mb library:


Accord= ing to the current test plan documentation for how to utilize the DPDK FIPS Validation Application (https://git.dpdk.org/tools/dts/tree/test_plans/fips_cryptodev= _test_plan.rst),

it is recommended that you pull from the intel-ipsec-mb github repository and then checkout a specific commit (noted as =E2=80=9Clatest working commit=E2=80=9D). The commit it recommends using in this documentation is a few commits after the version tagged =E2=80=9Cv0.50=E2= =80=9D however, when trying to build DPDK using this version of the library, it reports that it does not support any version older than =E2=80=9C1.0.0= =E2=80=9D. 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 (https://doc.dpdk.org/guides/sample_ap= p_ug/fips_validation.html) 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=E2=80=9D. 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 =E2=80=9C0.50=E2=80= =9D version you don=E2=80=99t 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.


Othe= r 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 =E2=80=9CCipherText was not present in the TestCase.= =E2=80=9D There was recently a patch<= /span> put out to fix the AES-GCM validation, however we are seeing it fail to compile with DPDK.


A= ll algorithm testing listed below was performed using the =E2=80=9Ccrypto_aesni_mb=E2=80=9D virtual device on version 1.3 of the ipse= c library


List of working algorithms:

  • AES-CBC

  • AES-CMAC

  • AES-CTR

  • AES-GMAC

  • HMAC-SHA1

  • TDES-CBC

List of failing algorithms:

  • AES-GCM

    • =E2=80=9CCipherText missing from TestCase=E2=80=9D

    • This failure message is found in the verdict returned from the ACVP API=

  • AES-XTS

    • =E2=80=9CACVP-AES-XTS-2.0: General exception. Contact service provider.=E2=80=9D

    • This failure happens before reaching DPDK application so likely a NIST problem

  • SHA-1

    • =E2=80=9CDigests do not match=E2=80=9D

    • This failure message is found in the verdict returned from the ACVP API=

    • Passes some test cases but fails others

  • SHA-256

    • =E2=80=9CDigests do not match=E2=80=9D

    • This failure message is found in the verdict returned from the ACVP API=

    • Like SHA-1, fails some but passes others

  • TDES-ECB

    • =E2=80=9CUSER1: Failed to get capability for cdev 0=E2=80=9D

    • =E2=80=9CUSER1: Error -22: test block=E2=80=9D

    • These errors are encountered during the validation phase (i.e., when the vectors are being run through the DPDK sample application)

Unte= sted algorithms:

  • RSA

  • ECDSA


--

Pat= rick Robb

Technical Service Manager

UNH In= terOperability Laboratory

21 Madbury Rd, Suite 100, Durh= am, NH 03824

www.iol.unh.edu


--0000000000004f4c5705f4983d4c--