Giter Site home page Giter Site logo

usnistgov / acvp Goto Github PK

View Code? Open in Web Editor NEW
151.0 53.0 64.0 17.95 MB

Industry Working Group on Automated Cryptographic Algorithm Validation

Home Page: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program

Makefile 0.87% Ruby 0.09% HTML 99.04%
cryptography protocol nist cryptographic-algorithms

acvp's Introduction

ACVP

The Automated Cryptographic Validation Protocol (ACVP) is a protocol to support a new National Voluntary Laboratory Accreditation Program (NVLAP) testing scope at the National Institute of Standards and Technology (NIST).

The new testing scope, 17ACVT, is available, and defined in NIST Handbook 150-17.

All current information about ACVP protocol may be found within this Github project at https://github.com/usnistgov/ACVP. View the protocol documents at https://pages.nist.gov/ACVP/.

For issues regarding the actual ACVP Server implementation, as well as pre-release (demo) and release notes (prod), see the ACVP-Server repository: https://github.com/usnistgov/ACVP-Server/.

Jump to

Background

The rapid development of cryptographic technology over the last two decades and its adoption in many different technology domains has resulted in a sharp increase in the number and complexity of approved algorithms. The volume of cryptographic algorithm validations has outstripped the available human resources available to test, report, and validate results. The plethora of different algorithms has created a dire need for consistent requesting and reporting of test data and results. We also live in times of unprecedented levels of threats and exploits that require frequent product updates to fix defects and remove security vulnerabilities, which in turn requires much faster turnaround of validation updates than what the existing validation model allows. See the NIST Automated Cryptographic Validation Testing project for broader context and information.

Requirements documents for the existing Cryptographic Algorithm Validation Program (CAVP) and the 17CAV scope can be found at https://nvlpubs.nist.gov/nistpubs/hb/2020/NIST.HB.150-2020.pdf. The requirements documents for the 17ACVT scope can be found on the same page.

General information about CAVP can be found at https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program with the CAVP management manual found at https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/CAVPMM.pdf and the FAQ at https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/CAVPFAQ.pdf.

How to use Metanorma

Using Metanorma is not required to view the documents in the GitHub repository. When changes occur, documents will automatically be built and deployed to https://pages.nist.gov/ACVP.

Metanorma is a library for writing standards. It can compile .adoc files into multiple common standards formats including the IETF's RFC format.

Use the instructions here to set up Metanorma: https://www.metanorma.org/install/

To compile an individual file, to make sure your gem versions are up to date run

gem install metanorma-cli

From there run

metanorma compile -t ietf -x html file.adoc

You can switch between -x html and -x txt for different RFC output formats.

If you make changes to a file that's referenced by a top level spec, run metanorma on the referenced file prior to running it on the top level file. E.g.,

metanorma compile -t ietf -x html symmetric/sections/04-testtypes.adoc
metanorma compile -t ietf -x html draft-celi-acvp-symmetric.adoc

Or you can use the Makefile which is available.

To build all documents, html and txt

make all

To build a specific file

make specific-file.html

To remove all xml, txt, html, err produces files,

make clean

Objective

The objective of this project is to define a protocol allowing independent implementation by all vendors participating in the NIST cryptographic validation programs (CAVP and CMVP) for accelerated test data generation and requisition, reporting of test results, and validation of NIST-approved cryptographic algorithms (see FIPS140-2 Annex A, Annex C and Annex D). For FIPS140-3, the NIST-approved cryptographic algorithms are defined in the SP800-140 Document Series.

Project Goals

The development of an Automated Cryptographic Validation Protocol (ACVP) that enables the generation and validation of standardized algorithm test evidence to facilitate the modernization of CAVP and CMVP.

Status

The demo server (demo.acvts.nist.gov) supports ACVP version 1.0. All endpoints defined in the protocol specification are available. Some additional endpoinds defined in https://github.com/usnistgov/ACVP-Server are also available but not considered part of this protocol.

The prod server (acvts.nist.gov) also supports ACVP version 1.0, with the same endpoints defined.

Supported Algorithms

Block Cipher Modes

Secure Hash

XOFs

Message Authentication

DRBG

Digital Signature

SP 800-56 Series Algorithms

Full KAS and KTS IFC Testing

Tests against shared secret computation (SSC), key derivation functions (KDF) or key derivation algorithms (KDA), and optionally key confirmation (KC). Test vectors issued under this set of tests (with the exception of 1.0 component based tests) are considered "full KAS" testing.

KAS SSC Testing

Standalone KAS SSC testing from SP800-56A/B. Can be used in conjunction with KDF/KDA testing and optionally key confirmation testing (as opposed to "full KAS" testing) to be considered a valid KAS implementation.

KDA Testing SP800-56Cr1/r2

Standalone KDA testing from SP800-56Cr1 or SP800-56Cr2. Can be used in conjunction with SSC testing and optionally key confirmation testing (as opposed to "full KAS" testing) to be considered a valid KAS implementation.

KAS KC Testing SP800-56

Standalone KAS Key Confirmation testing from SP800-56Ar3 and/or SP800-56Br2. Can be as a KC primitive validation as a part of a KAS validation.

KDFs

Safe Primes

Conditioning Components

Stateful Hash-Based Signatures

The prod server supports all of the above except for AES-FF3-1, and AES-GCM-SIV. Some of these algorithms have NIST SP800 series drafts in progress and will be available on the prod server when the draft becomes a standard.

Accessing the Server

To access the demo server one needs a TLS credential and a one-time password (OTP). The protocol specification and other development information are available in this repository. You may want to use the companion ACVP client to jump-start your work.

To set expectations, since this is a demo system, it will be in a state of flux and any all data on the system is considered temporary and may be reset to accommodate development of the Automated Cryptographic Validation Protocol (ACVP) service. We will try to keep the demo service relatively stable, but we plan to update it as we continue to add new algorithms and capabilities.

To access the prod server, first you must demonstrate compentency on the demo server. Then follow the instructions available at https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/how-to-access-acvts.

Obtaining TLS credentials

To access the demo environment you will need to send your CSR to us. Please use a 2048-bit RSA key pair and sign using at least a SHA-256 hash. Please send a request to [email protected] with 'CSR REQUEST FOR ACCESS TO DEMO' in the subject line. You will receive instructions for how to upload your CSR.

You are expected to protect the key pair from unauthorized use and to notify NIST in the event the keypair becomes compromised. Also, since we do not have a formal login page the following notice applies when accessing the ACVP system:

"***WARNING***WARNING***WARNING
You are accessing a U.S. Government information system, which includes: 1) this computer, 2) this computer network, 3) all computers connected to this network, and 4) all devices and storage media attached to this network or to a computer on this network. You understand and consent to the following: you may access this information system for authorized use only; you have no reasonable expectation of privacy regarding any communication of data transiting or stored on this information system; at any time and for any lawful Government purpose, the Government may monitor, intercept, and search and seize any communication or data transiting or stored on this information system; and any communications or data transiting or stored on this information system may be disclosed or used for any lawful Government purpose.
***WARNING***WARNING***WARNING"

Configuring and using One-Time-Passwords (OTP)

TOTP has been configured on all servers. See details here.

Contribution Guidelines

If you want to contribute, please follow the simple rules below and send us pull requests.

  • See Metanorma for installation instructions
  • Documents are templated out and organized into folders, find and edit the appropriate document and build the HTML or TXT file to ensure the changes are correct
  • Create a Pull Request with the updated ADOC files. GitHub Actions will verify the files can compile.
  • Once approved by a NIST member, GitHub Actions will rebuild the nist-pages branch to be reflected on https://pages.nist.gov/ACVP

If you would like to talk to our developers, you may want to send email to our mailing list [email protected]. You may also report bugs or request new tests.

Related Projects

Licensing Terms

This data was developed by employees of the National Institute of Standards and Technology (NIST), an agency of the Federal Government, in collaboration with third-party contributors. Pursuant to title 17 United States Code Section 105, works of NIST employees are not subject to copyright protection in the United States and are considered to be in the public domain. The data is provided by NIST as a public service and is expressly provided "AS IS." NIST MAKES NO WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT AND DATA ACCURACY. NIST does not warrant or make any representations regarding the use of the data or the results thereof, including but not limited to the correctness, accuracy, reliability or usefulness of the data. NIST SHALL NOT BE LIABLE AND YOU HEREBY RELEASE NIST FROM LIABILITY FOR ANY INDIRECT, CONSEQUENTIAL, SPECIAL, OR INCIDENTAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, AND THE LIKE), WHETHER ARISING IN TORT, CONTRACT, OR OTHERWISE, ARISING FROM OR RELATING TO THE DATA (OR THE USE OF OR INABILITY TO USE THIS DATA), EVEN IF NIST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

To the extent that NIST may hold copyright in countries other than the United States, you are hereby granted the non-exclusive irrevocable and unconditional right to print, publish, prepare derivative works and distribute the NIST data, in any medium, or authorize others to do so on your behalf, on a royalty-free basis throughout the world.

You may improve, modify, and create derivative works of the data or any portion of the data, and you may copy and distribute such modifications or works. Modified works should carry a notice stating that you changed the data and should note the date and nature of any such change. Please explicitly acknowledge the National Institute of Standards and Technology as the source of the data: Data citation recommendations are provided below. Permission to use this data is contingent upon your acceptance of the terms of this agreement and upon your providing appropriate acknowledgments of NIST's creation of the data.

Citation Format

Author/editor (Publication Year), Title, Publisher, Persistent Identifier (PID) or URL (Access date).

acvp's People

Contributors

acronymhaterheidi avatar agl avatar ashman-p avatar atvassilev avatar bfussell avatar celic avatar cipherboy avatar dmchodnicki avatar dstroud3 avatar elliemdaw avatar fliphil avatar hbooth avatar jbrock24 avatar jfigus avatar jvdsn avatar kneckter avatar kritner avatar livebe01 avatar locksmithone avatar okilker avatar pagubo avatar rkinsey avatar ronaldtse avatar sam1689 avatar schneidersoft avatar smuellerdd avatar tomofod avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

kritner dmchodnicki bfuss sam1689 elliemdaw janderse pagubo hihellobolke fliphil acronymhaterheidi kenrictran tomihouse agl celic jpatchell bfussell fbr-resources chinahby zacwdev bserma hareesh-d jonahmvp dsikkema-atsec prouddeath garrettburk123 zishan11 ronaldtse alexthurston hassoon1986 gaybro8777 iowatchgate rkinsey hixtink livebe01 donnacn ekmixon themelic generic-github-user ronsherfey sitedata pmgdeb cipherboy schneidersoft pjehkonen tomofod locksmithone kneckter kriskwiatkowski krakenmeister haleyx at-corp fangzihuan xkey- jbrock24 majed14567 okilker st-rnd securesubstrates acidburn0zzz jvdsn syedzubeen

acvp's Issues

Update symmetric spec to account for valid AAD length values for AES-CCM

From the symmetric spec:

image

Currently the CCM -> AAD information does not account for the fact that AAD lengths of 2^16 can be tested. It may make sense to state that AAD lengths of 2^16 can be specified, as that is currently the maximum value allowed for testing purposes.

If ranges are implemented as suggested in #67, the aadLen registration could become:


{
	"aadLen": {
		"min": 0,
		"max": 65536
	}
}

In the above, test vectors would continue to be generated for aadLens of 0 through 32, but additional testing would also be done on 2^16. At this time, the additional testing would be minimal to help keep json sizes smaller.

Need data-at-rest protection on the NIST ACVP server

Per Harold's email to the algotest mailing list:

"Hi All,
ephmeral-key.pdf

I have started the design and analysis for what the production architecture will look like for the NIST Validation server. As part of that work I encountered an issue dealing with how to store what could possibly be business proprietary information. The assumption here is that at least some (if not all) vendors may view the fact they are submitting tests for particular algorithms on a particular operating environment as business proprietary information and we (NIST) need to appropriately protect that information. Apostol suggested the idea of generating an ephemeral key (perhaps this is optional) that could be provided back to the client as part of the registration request and this key would then be used to encrypt the data at rest within our storage. This would protect the data in the event that an adversary were to gain access to our public facing database. We will have a protected zone outside the DMZ where the “real” work of generating test vectors and validating test results will happen. This zone will be able to use the ephemeral key to encrypt and decrypt information as needed, but will only have the ephemeral key for the limited period of time it needs to perform work. Once the work is completed, it will “forget” the key leaving the ACVP client as the only entity that will know the ephemeral key. Attached is a high-level sequence diagram that helps to illustrate what we are thinking about. We can discuss this and the attached diagram further on the call on Thursday, but I wanted to provide this material as “read-ahead” to help with the conversation.

Regards,

-Harold
"

Need to rethink partial test response validation

A new issue from NIST Sprint 1:

The validation of partial test results offers some flexibility but creates substantial complications in managing validation status on the NIST server. We believe all benefits intended by this protocol feature can be attained in other ways that result in much simpler and robust validation server architecture. In order to simplify the storage and data processing on the ACV servers it would be beneficial to disallow the submission of partial test results. We would like to remove this capability from the protocol.

Utilize "length" specified within TestGroup for TestCases

This might not be a good title, but through integration testing with AES-GCM it became apparent that different (CAVS) implementations of algorithms represent a zero length hex string differently. In AES-GCM, a zero length plaintext is represented as "", whereas in AES-CCM, the same is represented as "00".

It would be beneficial to decide on a consistent way to represent this, and @celic may have some additional input as it relates to SHA. Regardless of the decision, both the client and server should take into account the PropertyLen from the TestGroup when parsing hex strings. As it currently stands, that does not appear to be the case.

Error handling

Need to expand error handling section.

Possible Error message:

{
   "acv_version" : "0.3",
   "error" : "Example error message goes here." 
}

Some example HTTP Error codes:
404 if a resource is not found (i.e. a Vector Set Id is provided and it does not exist)
400 if the input to the server is not correct
500 Internal Server Error (i.e. internal database connection issue)

Inconsistency in acvp_protocol section 11.5

Seems that there is an inconsistency in acvp_protocol section 11.5

11.5. Test Results Request

The client will send this request to learn the results for an individual vector set.

GET /validation/acvp/results?vsId=1 HTTP1.1
User Agent:
Host: www.my-acvpserver.com
Accept: /
HTTP 1.1 200 OK
Status: 200 OK
Content-Type: application/json
Content-Length: <length of results>
{
    "version" : "0.2",
    "results" : {
        "vsId" : 930,
        "disposition" : "incomplete",
        "tests" : [
            { "tcId" : 12340, "result" : "passed" },
            { "tcId" : 12341, "result" : "passed" },
            { "tcId" : 12342, "result" : "incomplete" },
            { "tcId" : 12343, "result" : "passed" }
        ]
    }
}

The text prior to the block states it's the client request, which the top of it does appear to be a get request from the client. However, the JSON included in the block looks to be what the server would respond with, perhaps it was intended to be separated into two blocks to show client request -> server response?

0.3 Symmetric sub spec specifies direction at the vector instead of test_group

I took a look at the .3 spec of the symmetric specification thinking it would be similar to the .2 spec except for some naming differences and I noticed a fairly substantive change that caught me off-guard.

The “direction” JSON field is analogous to the .2 JSON field name “mode” and for some reason it was moved from being a child of a “test_group” object to being in the top-level and a peer/sibling of the “test_groups” field at the test vector level.

How should "expected failure" decrypt results be formatted?

On a related note to #27 - some test vectors generated will have expected failures. A failure (in the example of AES-GCM) could be an invalid tag for the operation. In this case the original vector/tcId could look like:

{
    "tcId": 9999,
    "key": "FEFFE9928665731C6D6A8F9467308308",
    "iv": "CAFEBABEFACEDBADDECAF888",
    "ct": "42831EC2217774244B7221B784D0D49CE3AA212F2C02A4E035C17E2329ACA12E21D514B25466931C7D8F6A5AAC84AA051BA30B396A0AAC973D58E091473F5985",
    "aad": "3AD77BB40D7A3660A89ECAF32466EF97F5D3D58503B9699DE785895A96FDBAAF43B1CD7F598ECE23881B00E3ED0306887B0C785E27E8AD3F8223207104725DD4",
    "tag": "64C0232904AF398A5B67C10BD4205A35",  
},

Where the actual tag should be 64C0232904AF398A5B67C10B53A5024D (last 8 characters of the tag were reversed in the test case.)

In this case, we would expect the client to report a failure (in some manner) for the decryption operation, as the tag will be unverifiable.

How will a decryption result of "failure" be represented in the result JSON?

tag sent as "FAIL":

{
    "tcId": 9999,
    "iv": "CAFEBABEFACEDBADDECAF888",
    "pt": "D9313225F88406E5A55909C5AFF5269A86A7A9531534F7DA2E4C303D8A318A721C3C0C95956809532FCF0E2449A6B525B16AEDF5AA0DE657BA637B391AAFD255",
    "tag": "FAIL"
}

new property "success" or similar result:

{
    "tcId": 9999,
    "iv": "CAFEBABEFACEDBADDECAF888",
    "pt": "D9313225F88406E5A55909C5AFF5269A86A7A9531534F7DA2E4C303D8A318A721C3C0C95956809532FCF0E2449A6B525B16AEDF5AA0DE657BA637B391AAFD255",
    "tag": "64C0232904AF398A5B67C10BD4205A35",
    "failureTest" : true
}

Other possibilities?

Improve the OE description as part of the registration for ACVP

A new issue from NIST Sprint 1:

Need to identify how to improve the description of the operation environment field contained within the registration step of the ACV protocol.

Some thoughts include:

  • Need a unique identifier for the module/implementation;
  • interoperable way to talk about OS, hardware platform, module;
  • valid values list for OE.

Inconsistent bits/bytes in symmetric specification

The specification for the most part uses a bit representation in its "length" properties. The AES-CCM table:

image

Payload, IV/Nonce, Tag, and AAD are represented as bits in the AES-GCM and AES-XTS rows. However the values in AES-CCM are bytes, though that is not specified.

The AES-CCM values should probably be updated to be specified in bits to remain consistent. The disadvantage to going this route is the ranges of valid values, as well as (2^16)*8 for max AAD length is a much larger value.

Thoughts?

Switch KAT to some other term to avoid overloading

KAT is an existing term in other documentation and it would be desirable to switch the ACVP documentation to use another term/acronym that accurately communicates the test type while not colliding with other terms. My initial thought was something functional test, but any non-conflicting term is fine by me.

Provide algorithm/capability query service

As the list of approved algorithms evolves over time, it would be nice to a have an ACVP server query that would return all approved algorithms/modes available for testing at a particular moment in time.

Under the current model, the client registers capabilities with the server with the underlying assumption that both the client and server know the valid options. However, it is conceivable in some cases the client may need to discover what is available for testing. Such a query would provide the needed information to the client.

Need failure reason in test results response from ACVP server

Do we want to add a reason failure to the test results in section 11.4 for failed test cases? The JSON response would look something like this...

{
"version" : "0.2",
"results" : {
"vsId" : 1437,
"disposition" : "incomplete",
"tests" : [
{ "tcId" : 12340, "result" : "passed", "reason" : "" },
{ "tcId" : 12341, "result" : "incomplete", "reason" : "" },
{ "tcId" : 12342, "result" : "failed", "reason" : "Authentication tag failure" }
]
}
}

Specify Field order?

Although JSON does not require it, as I am going through implementation I am wondering if we shouldn't require a particular field order. I am trying to be somewhat accepting and will ignore any unknown fields, but there are a few fields that I really need to know in a particular order. Largely, the order they are described in the specs are the order that I need. For the record, I am currently trying to process the input as a stream, if we cannot (or do not) want to specify the order then I will need to use a different implementation (not hard) but the consequence for us will be one of memory usage. I will need to load the whole file in memory and perform some random access. (The library I am using has the ability to create a tree-node representation and I can switch to that.)

A couple of examples:

  • the acv_version field must be first or I don't know how to process the rest of the file.
  • need the algorithm field before any of the other fields and so on

I do need to know sooner rather than later though how we want to address this moving forward.

Put ACVP draft in repo

Should we commit the current ACVP draft into this repo? I've started a sub-specification to define the JSON for symmetric ciphers. But the main ACVP draft isn't in the repo. Do we want to convert the main spec to RFC form first?

Branching for v0.3

It looks to me the specs are ready to branch for v0.3. Let’s plan accordingly to rev up every spec to 0.3 prior to the branch. Once this is done and the v0.3 branch is created we need to rev the main line up to v0.4.

Please let me know what you think and which specs you are planning to touch.

Variable Output Tests for SHAKE -- Minor

Right now, the SHA3 spec outlines 3 test types. "AFT", "MCT", and "variable". I propose changing "variable" to "VOT" (variable output test) in order to keep it in line with the existing test types while describing the test more accurately.

Include version in URI

Should we consider adding the ACVP version to the URI. For instance, section 11 currently defines the URI as:
www://my-acpserver.com:123/validation/acvp/

We would change this to something like:
www://my-acpserver.com:123/validation/acvp/v0.2/

This would allow more deployment options for servers that needed to simultaneously support multiple versions of the protocol. This would be required for supporting legacy devices in the field.

"KeyingOption" Symmetric Algorithm Capabilities - applies to TDES

It appears the spec would benefit from a "KeyingOption" (or similar) capability for specifying the type of tests to generate for a TDES registration.

The Keying Options as per http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-20.pdf are described as:

Three different keying options are allowed by the TDEA. The first option specifies that all the keys
are independent, i.e., KEY1, KEY2, and KEY3 are independent. This is referred to as Keying
Option 1 in FIPS PUB 46-3 – 1999 (and ANSI X9.52 – 1998). It will be referred to as 3-key
TDES in this document. The second option specifies that KEY1 and KEY2 are independent and
KEY3 is equal to KEY1, i.e., KEY1 and KEY2 are independent, KEY3 = KEY1. This is referred
to as Keying Option 2 in FIPS PUB 46-3 – 1999 (and ANSI X9.52 – 1998) and will be referred to
as 2-key TDES in this document. And the third option specifies that KEY1, KEY2 and KEY3 are
equal, i.e., KEY1=KEY2=KEY3. This is referred to as Keying Option 3 in FIPS PUB 46-3 – 1999
(and ANSI X9.52 – 1998 and will be referred to as 1-key TDES in this document. 1-key TDES is
equivalent to single DES.

Keying Options 1 and 2 are the only valid keying options for registration. Keying Option 3 is still used for performing KATs, but is not specified during registration.

How should decrypt result responses be formatted?

Since AES-GCM is slated as the first algorithm to be implemented, I'll use it as an example. Given the current result sample JSON from acvp_sub_symmetric:

{
    "acvVersion": "0.2",
    "vsId": 1564,
    "testResults": [
        {
            "tcId": 2171,
            "iv": "01020304C077A707E56C22AC",
            "ct": "",
            "tag": "53B15E85E377F8B5B6BFC2DE915FD622"
        },
        {
            "tcId": 2172,
            "iv": "01020304D666587803BCBAD7",
            "ct": "",
            "tag": "E7B1F2D77D82C6EB3C9CEFF16C376D9C"
        },
        {
            "tcId": 2173,
            "iv": "01020304D3B09894BB14B6CF",
            "ct": "",
            "tag": "DFF22B329AC87B82726EBBF20E66EEE2"
        },
        {
            "tcId": 2174,
            "iv": "01020304D678FBCC2EA341A2",
            "ct": "",
            "tag": "BAFBFA38AD5D6C6E7C97D08DDEC26580"
        },
        {
            "tcId": 2186,
            "iv": "01020304C6A745B0C4C9F2D5",
            "ct": "",
            "tag": "429FD5A0DAB344EF69B594A44CCAD3EB"
        },
        {
            "tcId": 2187,
            "iv": "010203043E56946A9C9E18D7",
            "ct": "",
            "tag": "7DA8BA92D64071909972395C981C4567"
        },
        {
            "tcId": 2201,
            "iv": "0102030479FD178FEB555D99",
            "ct": "FA2AF4B01BA610DE3A3EDE0B88946E2D",
            "tag": "3E77B921DB447F541EB5CC508D74CE4E"
        },
        {
            "tcId": 2202,
            "iv": "01020304C70FB9D3B9E1E329",
            "ct": "568028D34EA82E8D30D1A3B952849A70",
            "tag": "3D20D5935D6D37F6EE82FE0D2C7006F8"
        },
        {
            "tcId": 2203,
            "iv": "010203040D66A6EEA797B757",
            "ct": "B2E10E2ECEC9FC3477841D3AED6469DB",
            "tag": "DEF33A719333CAADE8002752922EC124"
        },
        {
            "tcId": 2204,
            "iv": "010203045B6CDA4B5CA26883",
            "ct": "CF72C75B4E550AEA535750D6B16393DF",
            "tag": "370D1175CF36A72585F20B379D064BCF"
        },
        {
            "tcId": 2205,
            "iv": "010203041E9FD60F49957FF5",
            "ct": "A1F124EE6E98CAB776CCD601B7F65D6A",
            "tag": "F4D7D0D75FC9961A12B3C6A3E6379972"
        },
        {
            "tcId": 2206,
            "iv": "0102030474CBC83C647DBEAF",
            "ct": "2CE1129D3E2F25468A9EE13ED39C902C",
            "tag": "48F3D4D7EB4B9FCB924ACC05B3834F98"
        }
    ]
}

In above, it appears that all samples are "encrypt" samples, however "decrypt" test vectors/test cases will also be generated.

Decrypt test case possibility:

{
    "tcId": 9999,
    "key": "FEFFE9928665731C6D6A8F9467308308",
    "iv": "CAFEBABEFACEDBADDECAF888",
    "ct": "42831EC2217774244B7221B784D0D49CE3AA212F2C02A4E035C17E2329ACA12E21D514B25466931C7D8F6A5AAC84AA051BA30B396A0AAC973D58E091473F5985",
    "aad": "3AD77BB40D7A3660A89ECAF32466EF97F5D3D58503B9699DE785895A96FDBAAF43B1CD7F598ECE23881B00E3ED0306887B0C785E27E8AD3F8223207104725DD4",
    "tag": "64C0232904AF398A5B67C10B53A5024D",  
},

I would think the result for a decrypt test case would look something like:

{
    "tcId": 9999,
    "iv": "CAFEBABEFACEDBADDECAF888",
    "pt": "D9313225F88406E5A55909C5AFF5269A86A7A9531534F7DA2E4C303D8A318A721C3C0C95956809532FCF0E2449A6B525B16AEDF5AA0DE657BA637B391AAFD255",
    "tag": "64C0232904AF398A5B67C10B53A5024D"
}

Where ct (cipherText) is replaced with pt (plainText). Both "iv" and "tag" are not actually needed in a decrypt operation result, so those could potentially be removed.

Thoughts?

Protocol specification needs additional detail for vectors and results

Additional detail is needed in the high-level protocol specification to describe the vectors and results URLs. Obviously, the specific details for each algorithm are in the algorithm sub-specifications, but a high-level description of what the expected inputs are (pointing out the details are in the sub specs) and expected response is needed.

Update DRBG testGroups Examples

The DRBG spec identifies the following as being part of the test group.
"derFunc":"yes",
"predResistance": "yes",
"entropyInputLen":"112",
"nonceLen":"56",
"persoStringLen":"112",
"additionalInputLen":"112",
but the the example does not reflect this.

Current example ....
{
"version": "0.2",
"vectorSetId": "1133",
"algorithm": "ctrDRBG",
"mode": "3KeyTDEA",
"derFunc":"yes",
"predResistance": "yes",
"entropyInputLen":"112",
"nonceLen":"56",
"persoStringLen":"112",
"additionalInputLen":"112",
"returnedBitsLen":"256",
"testGroups": [
{
"type": "long",
"tests": [
{
"tcId": "1815",

Correction needed is ...

Current example ....
{
"version": "0.2",
"vectorSetId": "1133",
"algorithm": "ctrDRBG",
"mode": "3KeyTDEA",
"derFunc":"yes",
"predResistance": "yes",
"entropyInputLen":"112",
"nonceLen":"56",
"persoStringLen":"112",
"additionalInputLen":"112",
"returnedBitsLen":"256",
"testGroups": [
{
"type": "long",
"tests": [
{
"tcId": "1815",

Correction should include.

{
"version": "0.2",
"vectorSetId": "1133",
"algorithm": "ctrDRBG",
"mode": "3KeyTDEA",
"derFunc":"yes",
"predResistance": "yes",
"entropyInputLen":"112",
"nonceLen":"56",
"persoStringLen":"112",
"additionalInputLen":"112",
"returnedBitsLen":"256",
"testGroups": [
"derFunc":"yes",
"predResistance": "yes",
"entropyInputLen":"112",
"nonceLen":"56",
"persoStringLen":"112",
"additionalInputLen":"112",
{
"type": "long",
"tests": [
{
"tcId": "1815",

Hash Protocol Specification

Is anybody working on getting together a specification for hashing algorithms? This should be separate from the already included HMAC protocol.

If this hasn't been started yet, I can begin work on it. Otherwise, if someone has begun work on the document I can contribute to make sure it matches the server's expectations.

Update symmetric specification to account for GCM-AES-XPN

GCM-AES-XPN is a relatively new addition, and is not currently accounted for in the specification. The GCM validation document at http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmvs.pdf has been updated to include testing information for GCM-AES-XPN.

The additional information needed in GCM-AES-XPN registration is a salt - specifically whether or not that salt is generated internally or externally (similar to the current IV for AES-GCM). Additionally, GCM-AES-XPN only supports a 96 bit IV, and only supports key sizes of 128 and 256 bits.

Investigate DRBG prediction resistance testing

Wanted to keep this as generic as possible (can update as details get fleshed out).

The spec does not currently account for CAVS parameters EntropyInputReseed and AdditionalInputReseed. Both of these parameters were utilized for tests with the following options:

Prediction Resistance Not Enabled = true
Reseeding not Implemented = false,

There is some potential confusion around why reseeding would be tested in a non PR scenario. While details and potential solutions are considered, this issue is here to track the conversation.

Questions on DRBG

Just a few questions on DRBG Test vector handling ...
Take the following example from the spec ...

  1. persoStringLen and additionalInputLen are 0 however the fields persoString and additionalInput are populated. Should they be ignored?

  2. entropyInputPR and entropyInput will always be the same size?

  3. Should "additionalInput" and "entropyInputPR" be displayed in an array called "predResistanceInput" ?

             {
           "version": "0.2",
           "vectorSetId": "1146",
           "algorithm": "hmacDRBG",
           "mode": "AES-256",
           "predResistance": "yes",
           "entropyInputLen":"256",
           "nonceLen":"128",
           "persoStringLen":"0",   ******
           "additionalInputLen":"0",  **** 
           "returnedBitsLen":"1024",
           "testGroups": [
             {
               "type": "long",
               "tests": [
                 {
                   "tcId": "2111",
                   "entropyInput":"ee3392c5f3de6f3f8c4f28d852afacd2cbaa89ed48d1c5d4311662962aa70a98",
                   "nonce":"b991a820fac75fd02642ad8fa651eda4",
                   "persoString":"30f3a50b0e2309dab93ea2aa095e5df8e4b2a42690572b31e53fb79a195481e5",
                   "additionalInput":"4ea46abe95b2e4184113f908ae30123207d481908b7af7ef348657bbf3b4a002",
                   "entropyInputPR": "e4413a2e404f12c644b0b1d7a49a0fbf3d8703d571ffd02168c11b4ade6fc903",
                   "additionalInput" : "61b7204c8fef294f2a9f2e73a83a8a7a04c38e3b3eaaed1b920abfceab912492",
                   "entropyInputPR" : "968ea185d1439fa2d67eb55ac93ba596b1ea679de7c6e44f80dc6f213455f1ed"
                   },
                 {
                   "tcId": "2112",
                   "entropyInput" : "a0ace75784b97224de2957e5f60dc85b25331fcf7901f37418d3c9de17ed4261",
                   "nonce": "b671308068fc7909a360c772f62a4c5e",
                   "persoString" : "338d5f2bd93262da154385e9ed90b7862e3c892f13e1d7d19924b2eb8b3bab21",
                   "additionalInput" : "7acd8bfae17ff4edbac3437817d6b3fce12a04c4034ac6bef0b1b88f7dcd7c85",
                   "entropyInputPR" : "47b26bbe93a5cc19a410523a072e04333f06c54af0049fc41e66213763020ef7",
                   "additionalInput" : "d4b24c74538e3a1083a2cc0a4414a9f558f0a2dc186e3b9a5294cd541acdad87",
                   "entropyInputPR" : "acb63f3b5995608a1331641cd43208444a9ec95e4bb2a438f614156b6a77c8c3"
                 }
               ]
             }
           ]

}

  1. If the array predResistanceInput is used, the test results
    "testResults": [
    {
    "tcId": "2111",
    "returnedBits": "e42130fd1d920a2bcd177c0de0d5834c9b05a6ecdf3bc46e3733869f762dc2e7d97357934d8061db033670c3739369924b321216c30b3e45d9bc8c0bad61d8fdc03dffd70725e793ebfe98bc15358764402f4e2c71be4acfad898649b51c5d2625374a61be2b59833d2dfcc593eddcffbac79016b22a992ae6f5f82bae194e06"

(Second generated value???)
"e42130fd1d920a2bcd177c0de0d5834c9b05a6ecdf3bc46e3733869f762dc2e7d97357934d8061db033670c3739369924b321216c30b3e45d9bc8c0bad61d8fdc03dffd70725e793ebfe98bc15358764402f4e2c71be4acfad898649b51c5d2625374a61be2b59833d2dfcc593eddcffbac79016b22a992ae6f5f82bae194e06"

},

Symmetric Unique Numeric Test Id Scope

In Section 3.2, tcId is defined as "Unique numeric identifier for the test case". Is this id unique within the context of the Test Group or all the Test Cases within the Test Vector?

no-certificate option

Should we add a 'no-certificate' option to ACVP in the registration? There are cases where a company may want to validate a crypto implementation without getting a public certificate. Example scenarios are beta versions of unannounced products - the company may want to ensure the beta is good but does not want to preempt a public product release.

If this option is set, the validation server would perform all validation work except it would not publish a certificate. The server would only return a success, e.g. 200 OK, just like it is described in Section 11.4 of the current ACVP spec.

What do you all think?

Suggestion: "Range" object utilized in spec

Some algorithms may benefit from beginning to use a range object that allows for the specifying of a min and max value that is allowed for the parameter.

AES-CCM and SHAKE specifically use a range of values that are entered. If 0 min and 32 max are entered in the case of AES-CCM, all values between 0 and 32 are tested. A random sampling of values within the range is also feasible.

AES-GCM could also use this range object, as currently the aadLen array accepts up to 5 values, one can be a 0, 2 can be divisible by 128, and 2 are not divisible by 128. AES-GCM could begin accepting a min and max, and a separate flag for supportsNonBlockBoundryAadLen or similar.

This range value will potentially lead to a few new parameters, but should make things a bit more explicit, and hopefully easier to understand.

Example of current registration for AES-GCM:

{
	"aadLen": [0, 128, 256, 120, 248]
}

could become:

{
	"aadLen": {
		"min": 0,
		"max": 256
	},
	"supportsNonBlockBoundryAadLen": true
}

Thoughts?

Prerequisite Modeling

Instead of having individual prereq fields (the majority of which will be likely be null) for each algorithm, I think it would be preferable to have array of prereqs. For example, the ECDSA spec currently has...
shaVal
sha2Val
sha3Val
drgbVal
drbg2Val

This is not easy to read much less implement things like validation. Dealing with these in any capacity becomes 5 separate property reads with an inconsistent naming convention.

It would be better to have an array of prereqs, which not allows the easy use of loop, it reduces the data passed around to what is actually needed. It also allows the easy addition of additional prereqs if the need should arise. In the current model, if you want to add a third drbg prereq, that's an API change.

Suggest something along the lines of

prereqVals Prerequisite validations, see section 2.X.X array

Which would look like
[{algorithm: 'drbg', value: '1234'}, {algorithm: 'sha', value: 'same'}]

The allowed prereq algorithms would be supplied in the associated section and used to limit valid inputs.

Symmetric Model Section 3.2 Name Clarification

Currently we have these sections...
3. Test Vectors
3.1 Test Groups JSON Schema
3.2 Test Vectors JSON Schema

I believe this is confusing as Test Vector is used twice in the hierachy . Recommend we go to the following...
3. Test Vectors
3.1 Test Groups
3.2 Test Cases

and change all references to Test Vector in the Section 3.2 text to Test Case

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test case to be processed by the ACVP client. The following table describes the JSON elements for each test case.

SHA3 Test Cases are Little Endian

Keccak was designed with little-endianness in mind. The algorithm expects little-endian messages and produces little-endian digests. Unfortunately this is not documented in FIPS-202 and SHA3VS. It should be documented in our spec for SHA3.

Example JSON, Protocol, Product Registration with Capabilities

Hi,

The following:

     {
     "implementationDescription" : 
          "Sample crypto module for demonstrating ACV protocol."
     },

does not appear to be valid JSON, it is missing a comma then a label.

http://jsonlint.com/ reports:

Error: Parse error on line 18:
...ystem": "Linux 3.1" {				"implementatio
-----------------------^
Expecting 'EOF', '}', ':', ',', ']', got '{'

Handling of Monte-Carlo tests for symmetric ciphers

The MC Test for the different modes of symmetric ciphers relies on an algorithm with an initial state (e.g., key, IV, plaintext) - see for example http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf. The algorithm is different/specific for each mode.

Traditionally, CAVS supplied the initial value for the algorithm and the tested implementation was expected to implement the MCT algorithm, feed the initial condition in it and report the results from the execution.

The definition of the MCT is not well suited for expanding it into a series of simple test cases because the values for each test depend on the results from the previous test.

The current specification in sub_symmetric does not appear to have a handle for this type of test. A new type of test is needed for this

@jfigus if you see this differently, please chime in.

Enabled protection of master and v_0.3 branches

As we continue the development of ACVP, I thought it would be good to enable protection of the two main areas of work: master and v_0.3. Git information on branch protection is available here: https://help.github.com/articles/about-protected-branches/

Note that only the basic protection of these two branches is currently enabled: i) cannot force push and ii) cannot delete them. Hopefully, these protections are enough but if you feel some of the other optional features are needed, please chime in.

The protections currently enabled should have no effect on your work and please let me know if you encounter any issue.

Suggestion/Poll: Convert "values" with valid response of "yes/no" to boolean

I know we're getting close to our branch date of the spec, so wanted to get this out there just to get an opinion. We have several parts of the spec that state an expectation of a value with valid responses being yes or no; what are everyone's thoughts on using the primitive boolean instead?

I'm not (necessarily) suggesting this change be made prior to the branch, but was curious on what everyone's thoughts are - if it's wanted at all, and if it should be done before or after the branch.

Symmetric Test Model Lacks Function

Currently there is no indication in Section 3.1 Test Group or 3.2 Test of what function (encryption or decryption) is being tested. Believe this probably belongs in Section 3.1.

Need hooks for data expiration policy and management in ACVP

A new issue from NIST Sprint 1:

Need to establish some boundaries around when data will expire. This includes:
How long should registration/capabilities be available before test vectors are retrieved?
How long should test vectors be available after they are retrieved? It is it even necessary to keep them?
How long should a test id be active before it is no longer possible to submit test results?
Should the length of time be based on last interaction or total time taken?

Need to think how all these should be handled by the ACV protocol.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.