Internet-Draft | ACVP Symmetric Block Ciphers | August 2020 |
Celi | Expires 11 February 2021 | [Page] |
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 February 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The authors thank John Foley for putting together an early draft of this specification.¶
This document defines the JSON schema for testing Symmetric Block Cipher implementations with the ACVP specification.¶
The Automated Crypto Validation Protocol (ACVP) defines a mechanism to automatically verify the cryptographic implementation of a software or hardware crypto module. The ACVP specification defines how a crypto module communicates with an ACVP server, including crypto capabilities negotiation, session management, authentication, vector processing and more. The ACVP specification does not define algorithm specific JSON constructs for performing the crypto validation. A series of ACVP sub-specifications define the constructs for testing individual crypto algorithms. Each sub-specification addresses a specific class of crypto algorithms. This sub-specification defines the JSON constructs for testing Symmetric Block Cipher implementations using ACVP. The ACVP server performs a set of tests on the block ciphers in order to assess the correctness and robustness of the implementation. A typical ACVP validation session would require multiple tests to be performed for every supported cryptographic algorithm, such as AES-ECB, AES-CBC, AES-CTR, AES-GCM, TDES-CBC, TDES-CTR, etc.¶
No terms and definitions are listed in this document.¶
The following block cipher algorithms MAY be advertised by the ACVP compliant cryptographic module:¶
ACVP-AES-ECB¶
ACVP-AES-CBC¶
ACVP-AES-CBC-CS1¶
ACVP-AES-CBC-CS2¶
ACVP-AES-CBC-CS3¶
ACVP-AES-OFB¶
ACVP-AES-CFB1¶
ACVP-AES-CFB8¶
ACVP-AES-CFB128¶
ACVP-AES-CTR¶
ACVP-AES-GCM¶
ACVP-AES-GCM-SIV¶
ACVP-AES-XPN¶
ACVP-AES-CCM¶
ACVP-AES-XTS¶
ACVP-AES-KW¶
ACVP-AES-KWP¶
ACVP-TDES-ECB¶
ACVP-TDES-CBC¶
ACVP-TDES-CBCI¶
ACVP-TDES-CFB1¶
ACVP-TDES-CFB8¶
ACVP-TDES-CFB64¶
ACVP-TDES-CFBP1¶
ACVP-TDES-CFBP8¶
ACVP-TDES-CFBP64¶
ACVP-TDES-OFB¶
ACVP-TDES-OFBI¶
ACVP-TDES-CTR¶
ACVP-TDES-KW¶
The following conformances MAY be advertised by the ACVP compliant cryptogrpahic module:¶
This section describes the design of the tests used to validate implementations of block cipher algorithms.¶
There are three types of tests for block ciphers: functional tests, Monte Carlo tests and counter tests. Each has a specific value to be used in the testType field. The testType field definitions are:¶
"AFT" - Algorithm Functional Test. These tests can be processed by the client using a normal 'encrypt' or 'decrypt' operation. AFTs cause the implementation under test to exercise normal operations on a single block, multiple blocks, or (where applicable) partial blocks. In some cases random data is used, in others, static, predetermined tests are provided. The functional tests of the block cipher are designed to verify that the logical components of the cipher (GFSbox, KeySbox, block chaining etc.) are operating correctly.¶
"MCT" - Monte Carlo Test. These tests exercise the implementation under test under strenuous circumstances. The implementation under test must process the test vectors according to the correct algorithm and mode in this document. MCTs can help detect potential memory leaks over time, and problems in allocation of resources, addressing variables, error handling and generally improper behavior in response to random inputs. Each MCT processes 100 pseudorandom tests. Not every algorithm and mode combination has an MCT. See Section 6.1.1 for implementation details.¶
"CTR" - Counter Mode Test. Counter tests are specifically for counter modes (AES-CTR and TDES-CTR) and require an implementation under test to exercise their counter mechanism. The server will send a long message to the client for encryption or decryption and back-compute the IVs used by the implementation under test. These IVs are then verified for uniqueness and an increasing (or decreasing) nature. The client processes these tests as normal AFTs. The different mode is highlighted here to signify the difference on the server side for processing.¶
The MCTs start with an initial condition (plaintext/ciphertext, key, and optional, or maybe multiple IVs) and perform a series of chained computations. For modes that use an IV, the IV is used in the beginning of each pseudorandom process. The IV is implicitly advanced according to the block cipher mode in use. There are separate rounds of MCT for encryption and decryption. Because some block cipher modes rely on an IV and perform calculations differently from other modes, there are specific definitions of MCT for many of the block cipher modes.¶
The initial condition for the test is the tuple (KEY, PT) set to some values.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values. An initial payload length is chosen based on the payloadLen values the IUT registers with.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY, IV, PT) set to some values.¶
The initial condition for the routine is a tuple (KEY, CT) set to some values. This pseudocode is specifically for encryption. For decryption, swap all instances of CT with PT.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, PT) set to some values.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV1, IV2, IV3, PT1, PT2, PT3) set to some values.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV, PT) set to some values. PT and CT are k-bit where k is the feedback size, for example CFB1 has a feedback size of 1-bit.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV1, IV2, IV3, PT) set to some values. PT and CT are k-bit where k is the feedback size, for example CFB8-P has a feedback size of 8-bits.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV, PT) set to some values.¶
The initial condition for the test is the tuple (KEY1, KEY2, KEY3, IV1, IV2, IV3, PT) set to some values.¶
The tests described in this document have the intention of ensuring an implementation is conformant to [FIPS-197] and [SP800-38A].¶
In [SP800-38A], both Section 5 and Section 6 which describe general modes of operation for block ciphers are tested. In [FIPS-197], Section 4 outlines the AES engine and necessary functions to perform simple encrypt an decrypt operations. All AES tests perform such operations and thus rely heavily on this section. Section 5 specifically outlines the algorithm for AES and thus all AES tests rely heavily on this section as well. All of [SP800-38A-Add] requirements are covered. In [AES-XTS], the IEEE outlines the encrypt and decrypt operations for AES-XTS.¶
Some requirements in the outlined specifications are not easily tested. Often they are not ideal for black-box testing such as the ACVP. In [SP800-38A], Appendix A outlines padding for when the data being encrypted does not evenly fill the blocks. In these tests, all data, unless otherwise specified, is assumed to be a multiple of the block length. All exceptions to those cases are when stream ciphers specifically are being tested. In Section 5.3, IV generation which is required for all modes of AES and TDES outside of ECB, is not tested. Appendix D outlines how errors are to be handled. As some symmetric ciphers aren't authenticated, ACVP does not include tests that change random bits in payload, IV, key or results, as these results can be successfully encrypted/decrypted, but errors aren't necessarily detectable.¶
In [SP800-67r2], Section 3 outlines the use for TDES with keying option 1 (three distinct keys) and decryption only for keying option 2 (K1 == K3 != K2). Depending on the cipher mode, both the forward and inverse cipher are tested. The known answer tests address these requirements.¶
In [SP800-67r2], Section 3.3 outlines requirements for keys for proper usage of TDES. These requirements are not tested by ACVP. All keys used in the tests are randomly or staticly generated by the server. There are no checks for key equality or potentially weak keys. Section 3.3.2 outlines specific keys which are to be avoided. ACVP does not expect a client to be able to detect these keys.¶
In [SP800-38D], Section 7 outlines the encrypt and decrypt operations for AES-GCM. This and all prerequisites to these operations (such as GHASH) are tested as AES-GCM encrypt and decrypt operations.¶
In [SP800-38C], Section 6 outlines the encrypt and decrypt operations for AES-CCM. This and all prerequisites to these operations (such as CBC-MAC) are tested as AES-CCM encrypt and decrypt operations. In [AES-GCM-SIV], the draft outlines the encrypt and decrypt operations for AES-GCM-SIV.¶
In [SP800-38F] Section 5.2 defines the authenticated encryption and authenticated decryption operations for all three key-wrap algorithms. As well, the padding for key-wrap with padding is defined. Algorithm Functional Tests provide assurance of these requirements for encrypt operations. For decrypt operations, there is a possibility to reject the ciphertext due to improper wrapping. This is also assured by the Algorithm Functional Tests.¶
Sections 6 and 7 outline the specific ciphers in both encrypt and decrypt directions. All facsets of these processes are tested with random data via the Algorithm Functional Tests.¶
In [SP800-38F] Section 5.3 defines the length requirements allowed by an optimal implementation. The upper bounds are unreasonably large to test in a web-based model and thus an artificial maximum is selected for the payloadLen property (corresponding to both plaintext and ciphertext). The Algorithm Functional Tests SHOULD utilize both the minimum and maximum values provided in the client's registration optimally with other values.¶
ACVP requires crypto modules to register their capabilities. This allows the crypto module to advertise support for specific algorithms, notifying the ACVP server which algorithms need test vectors generated for the validation process. This section describes the constructs for advertising support of Block Cipher algorithms to the ACVP server.¶
The algorithm capabilities MUST be advertised as JSON objects within the 'algorithms' value of the ACVP registration message. The 'algorithms' value is an array, where each array element is an individual JSON object defined in this section. The 'algorithms' value is part of the 'capability_exchange' element of the ACVP JSON registration message. See the ACVP specification [ACVP] for more details on the registration message.¶
Each algorithm implementation MAY rely on other cryptographic primitives. For example, RSA Signature algorithms depend on an underlying hash function. Each of these underlying algorithm primitives must be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:¶
Prerequisites, if applicable, MUST be submitted in the registration as the prereqVals
JSON property array inside each element of the algorithms
array. Each element in the prereqVals
array MUST contain the following properties¶
JSON Property | Description | JSON Type |
---|---|---|
algorithm | a prerequisite algorithm | string |
valValue | algorithm validation number | string |
A "valValue" of "same" SHALL be used to indicate that the prerequisite is being met by a different algorithm in the capability exchange in the same registration.¶
An example description of prerequisites within a single algorithm capability exchange looks like this¶
Some block cipher algorithm implementations rely on other cryptographic primitives. For example, AES-CCM uses an underlying AES-ECB algorithm. Each of these underlying algorithm primitives MUST be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:¶
JSON Value | Description | JSON type | Example Values |
---|---|---|---|
algorithm | a prerequisite algorithm | string | AES, DRBG, TDES |
valValue | algorithm validation number | string | actual number or "same" to refer to the same submission |
prereqAlgVal | prerequisite algorithm validation | object | exactly one algorithm property and one valValue property |
Each algorithm capability advertised is a self-contained JSON object and SHALL use the following values when appropriate:¶
JSON Value | Description | JSON type |
---|---|---|
algorithm | The block cipher algorithm and mode to be validated. | string |
revision | The version of the testing methodology the IUT is requesting to validate against. | string |
conformances | The additional conformance for the algorithm for a specific use-case | array of string |
prereqVals | Prerequisite algorithm validations | array of prereqAlgVal objects described in Table 2 |
direction | The IUT processing direction | array of strings |
keyLen | The supported key lengths in bits | array of integers |
payloadLen | The supported plain and cipher text lengths in bits. This varies depending on the algorithm type, for additional details see Table 5 and Table 7 | domain |
ivLen | The supported IV/Nonce lengths in bits, see Table 5 | domain |
ivGen | IV generation method for AES-GCM/AES-XPN algorithms | string |
ivGenMode | IV generation mode for AES-GCM/AES-XPN algorithms | string |
saltGen | Salt generation method for AES-XPN mode only | string |
aadLen | The supported AAD lengths in bits for AEAD algorithms | domain |
tagLen | The supported Tag lengths in bits for AEAD algorithms, see Table 5 | domain |
kwCipher | The cipher as defined in SP800-38F for key wrap mode | array of strings |
tweakMode | The format of tweak value input for AES-XTS. Hex refers to the tweakValue being a literal hex string. Number refers to the tweakValue being an integer number represented as a hex string. | array of strings |
keyingOption | The Keying Option used in TDES. Keying option 1 (1) is 3 distinct keys (K1, K2, K3). Keying Option 2 (2) is 2 distinct keys only suitable for decrypt (K1, K2, K1). | array of integers |
overflowCounter | Indicates if the implementation can handle a counter exceeding the maximum value | boolean |
incrementalCounter | Indicates if the implementation increments the counter (versus decrementing the counter) | boolean |
The following grid outlines which properties are REQUIRED, as well as all the possible values a server MAY support for each standard block cipher algorithm:¶
algorithm | revision | direction | keyLen | keyingOption |
---|---|---|---|---|
AES-ECB | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
AES-CBC | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
AES-OFB | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
AES-CFB1 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
AES-CFB8 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
AES-CFB128 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | |
TDES-ECB | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CBC | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CBCI | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFB1 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFB8 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFB64 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFBP1 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFBP8 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-CFBP64 | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-OFB | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations | |
TDES-OFBI | "1.0" | ["encrypt", "decrypt"] | [1, 2] Note: 2 is only available for decrypt operations |
The following grid outlines which properties are REQUIRED, as well as the possible values a server MAY support for each authenticated block cipher algorithm:¶
algorithm | revision | direction | keyLen | kwCipher | keyingOption |
---|---|---|---|---|---|
AES-KW | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | ["cipher", "inverse"] | |
AES-KWP | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | ["cipher", "inverse"] | |
TDES-KW | "1.0" | ["encrypt", "decrypt"] | ["cipher", "inverse"] | [1, 2] Note: 2 is only available for decrypt operations |
The following grid outlines which properties are REQUIRED, as well as the possible values a server MAY support for each key-wrap block cipher algorithm:¶
algorithm | revision | direction | keyLen | payloadLen | ivLen | ivGen | ivGenMode | saltGen | aadLen | tagLen |
---|---|---|---|---|---|---|---|---|---|---|
AES-GCM | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 0, "Max": 65536, "Inc": any} | {"Min": 8, "Max": 1024, "Inc": any} | ["internal", "external"] | ["8.2.1", "8.2.2"] | {"Min": 0, "Max": 65536, "Inc": any} | {[32, 64, 96, 104, 112, 120, 128]} | |
AES-GCM-SIV | "1.0" | ["encrypt", "decrypt"] | [128, 256] | {"Min": 0, "Max": 65536, "Inc": 8} | {"Min": 0, "Max": 65536, "Inc": 8} | |||||
AES-XPN | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 0, "Max": 65536, "Inc": any} | ["internal", "external"] | ["8.2.1", "8.2.2"] | ["internal", "external"] | {"Min": 1, "Max": 65536, "Inc": any} | {[32, 64, 96, 104, 112, 120, 128]} | |
AES-CCM | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 0, "Max": 256, "Inc": 8} | {"Min": 56, "Max": 104, "Inc": 8} | {"Min": 0, "Max": 524288, "Inc": any} | {[32, 64, 96, 104, 112, 120, 128]} |
The following grid outlines which properties are REQUIRED, as well as the possible values a server MAY support for each miscellaneous block cipher algorithm:¶
algorithm | revision | direction | keyLen | payloadLen | tweakMode | keyingOption | overflowCounter | incrementalCounter |
---|---|---|---|---|---|---|---|---|
AES-CBC-CS1 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 128, "Max": 65536, "Inc": any} | ||||
AES-CBC-CS2 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 128, "Max": 65536, "Inc": any} | ||||
AES-CBC-CS3 | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 128, "Max": 65536, "Inc": any} | ||||
AES-CTR | "1.0" | ["encrypt", "decrypt"] | [128, 192, 256] | {"Min": 1, "Max": 128, "Inc": any} | true, false | true, false | ||
AES-XTS | "1.0" | ["encrypt", "decrypt"] | [128, 256] | {"Min": 128, "Max": 65536, "Inc": 128} | ["hex", "number"] | |||
TDES-CTR | "1.0" | ["encrypt", "decrypt"] | {"Min": 1, "Max": 64, "Inc": any} | [1, 2] Note: 2 is only available for decrypt operations | true, false | true, false |
The ACVP server provides test vectors to the ACVP client, which are then processed and returned to the ACVP server for validation. A typical ACVP validation test session would require multiple test vector sets to be downloaded and processed by the ACVP client. Each test vector set represents an individual algorithm defined during the capability exchange. This section describes the JSON schema for a test vector set used with Symmetric Block Cipher algorithms.¶
The test vector set JSON schema is a multi-level hierarchy that contains meta data for the entire vector set as well as individual test vectors to be processed by the ACVP client. The following table describes the JSON elements at the top level of the hierarchy.¶
JSON Values | Description | JSON Type |
---|---|---|
acvVersion | Protocol version identifier | string |
vsId | Unique numeric vector set identifier | integer |
algorithm | Algorithm defined in the capability exchange | string |
mode | Mode defined in the capability exchange | string |
revision | Protocol test revision selected | string |
testGroups | Array of test groups containing test data, see Section 8.1 | array |
An example of this would look like this¶
Test vector sets MUST contain one or many test groups, each sharing similar properties. For instance, all test vectors that use the same key size would be grouped together. The testGroups element at the top level of the test vector JSON object SHALL be the array of test groups. The Test Group JSON object MUST contain meta-data that applies to all test cases within the group. The following table describes the JSON elements that MAY appear from the server in the Test Group JSON object:¶
JSON Value | Description | JSON type |
---|---|---|
tgId | Numeric identifier for the test group, unique across the entire vector set. | integer |
direction | The IUT processing direction: encrypt or decrypt | string |
ivGen | IV generation method | string |
ivGenMode | IV generation method | string |
saltGen | Salt generation method | string |
keyLen | Length of key in bits to use | integer |
keyingOption | The TDES keying option to use | integer |
ivLen | Length of IV in bits to use | integer |
payloadLen | Length of plaintext or ciphertext in bits to use | integer |
aadLen | Length of AAD in bits to use | integer |
tagLen | Length of AEAD tag in bits to use | integer |
testType | The test category type (AFT, MCT or counter). See Section 6 for more information about what these tests do, and how to implement them. | string |
tests | Array of individual test case JSON objects, which are defined in Section 8.2 | array of testCase objects |
Some properties MUST appear in the prompt file from the server for every testGroup object. They are as follows:¶
The other properties MAY appear depending on the algorithm selected for the test vector set. The following grid defines the REQUIRED properties for each standard block cipher, as well as the valid values a server MAY use:¶
algorithm | keyLen | keyingOption |
---|---|---|
AES-ECB | 128, 192, 256 | |
AES-CBC | 128, 192, 256 | |
AES-OFB | 128, 192, 256 | |
AES-CFB1 | 128, 192, 256 | |
AES-CFB8 | 128, 192, 256 | |
AES-CFB128 | 128, 192, 256 | |
TDES-ECB | 1, 2 | |
TDES-CBC | 1, 2 | |
TDES-CBCI | 1, 2 | |
TDES-CFB1 | 1, 2 | |
TDES-CFB8 | 1, 2 | |
TDES-CFB64 | 1, 2 | |
TDES-CFBP1 | 1, 2 | |
TDES-CFBP8 | 1, 2 | |
TDES-CFBP64 | 1, 2 | |
TDES-OFB | 1, 2 | |
TDES-OFBI | 1, 2 |
The following grid defines when each property is REQUIRED from a server for each authenticated block cipher:¶
algorithm | keyLen | ivGen | ivGenMode | saltGen | ivLen | payloadLen | aadLen | tagLen | saltLen |
---|---|---|---|---|---|---|---|---|---|
AES-GCM | 128, 192, 256 | "internal", "external" | "8.2.1", "8.2.2" | within domain | within domain | within domain | within domain | ||
AES-GCM-SIV | 128, 256 | 96 | within domain | within domain | 128 | ||||
AES-XPN | 128, 192, 256 | "internal", "external" | "8.2.1", "8.2.2" | "internal", "external" | within domain | within domain | within domain | within domain | within domain |
AES-CCM | 128, 192, 256 | within domain | within domain | within domain | within domain |
The following grid defines when each property is REQUIRED from a server for a key-wrap block cipher:¶
algorithm | keyLen | kwCipher | payloadLen |
---|---|---|---|
AES-KW | 128, 192, 256 | "cipher", "inverse" | within domain |
AES-KWP | 128, 192, 256 | "cipher", "inverse" | within domain |
TDES-KW | "cipher", "inverse" | within domain |
The following grid defines when each property is REQUIRED from a server for the miscellaneous block ciphers:¶
algorithm | keyLen | keyingOption | incremental | overflow | tweakMode | payloadLen |
---|---|---|---|---|---|---|
AES-CBC-CS1 | 128, 192, 256 | within domain | ||||
AES-CTR | 128, 192, 256 | true, false | true, false | |||
AES-XTS | 128, 256 | "hex", "number" | within domain | |||
TDES-CTR | 1, 2 | true, false | true, false |
Each test group SHALL contain an array of one or more test cases. Each test case is a JSON object that represents a single case to be processed by the ACVP client. The following table describes the JSON elements for each test case.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set. | integer |
key | Encryption key to use for AES | string (hex) |
key1, key2, key3 | Encryption keys to use for TDES | string (hex) |
iv | IV to use | string (hex) |
tweakValue | tweakValue used to form an IV for AES-XTS when the tweakMode for the group is 'hex' | string (hex) |
sequenceNumber | integer used to form an IV for AES-XTS when the tweakMode for the group is 'number' | integer |
salt | The salt to use in AES-XPN (required for AES-XPN only) | string (hex) |
pt | Plaintext to use | string (hex) |
ct | Ciphertext to use | string (hex) |
payloadLen | Plaintext or Ciphertext length to use in bits. Only the most significant 'payloadLen' bits will be used. | string (hex) |
aad | AAD to use for AEAD algorithms | string (hex) |
tag | Tag to use for AEAD algorithms | string (hex) |
After the ACVP client downloads and processes a vector set, it SHALL send the response vectors back to the ACVP server within the alloted timeframe. The following table describes the JSON object that represents a vector set response.¶
JSON Value | Description | JSON type |
---|---|---|
acvVersion | Protocol version identifier | string |
vsId | Unique numeric identifier for the vector set | integer |
testGroups | Array of JSON objects that represent each test vector group. See Table 16 | array of testGroup objects |
The testGroup Response section is used to organize the ACVP client response in a similar manner to how it receives vectors. Several algorithms SHALL require the client to send back group level properties in its response. This structure helps accommodate that.¶
JSON Value | Description | JSON type |
---|---|---|
tgId | The test group identifier | integer |
tests | The tests associated to the group specified in tgId | array of testCase objects |
Each test case is a JSON object that represents a single test object to be processed by the ACVP client. The following table describes the JSON elements for each test case object.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set. | integer |
pt | The IUT's pt response to a decrypt test | string (hex) |
ct | The IUT's ct response to an encrypt test | string (hex) |
testPassed | Some test cases included with decrypt operations in AES-GCM, AES-CCM, AES-XPN, AES-KW, AES-KWP, and TDES-KW will have expected failures. | boolean |
resultsArray | Array of JSON objects that represent each iteration of a Monte Carlo Test. Each iteration will contain the key(s), pt, ct and iv | array of objects containing pt, ct and iv (except for ECB mode) |
There are no additional security considerations outside of those outlined in the ACVP document.¶
This document does not require any action by IANA.¶
The following is a example JSON object advertising support for all block ciphers.¶
[{ "acvVersion": <acvp-version> },{ "vsId": 2055, "algorithm": "ACVP-AES-GCM", "revision": "1.0", "testGroups": [{ tgId": 1, "testType": "AFT", "direction": "encrypt", "keyLen": 128, "ivLen": 96, "ivGen": "external", "ivGenMode": "8.2.2", "payloadLen": 0, "aadLen": 0, "tagLen": 32, "tests": [ { "tcId": 1, "plainText": "", "key": "10B8D4C9658590A...", "aad": "", "iv": "3D026F3D590BF1A7..." }, { "tcId": 2, "plainText": "", "key": "934865822A3ECCB...", "aad": "", "iv": "273F3B30341C779E..." } ] }, { "tgId": 19, "testType": "AFT", "direction": "decrypt", "keyLen": 128, "ivLen": 96, "ivGen": "external", "ivGenMode": "8.2.2", "payloadLen": 0, "aadLen": 120, "tagLen": 32, "tests": [ { "tcId": 271, "key": "88AB5441AE2...", "aad": "4E956EF528D...", "iv": "810628011BB0...", "cipherText": "", "tag": "1180FD89" }, { "tcId": 272, "key": "9149BE47FAEB...", "aad": "938A8FA71324...", "iv": "FF6B72FF25B55...", "cipherText": "", "tag": "6C7528F0" } ] } ] }]¶
The following shows AES-CCM AFT request vectors.¶
The following shows AES-CCM AFT responses.¶
The following shows AES-CBC AFT and MCT request vectors.¶
The following shows AES-CBC AFT and MCT responses.¶
The following shows AES-CBC-CS1 AFT and MCT request vectors.¶
The following shows AES-CBC-CS1 AFT and MCT responses.¶
The following shows AES-CBC-CS2 AFT and MCT request vectors.¶
The following shows AES-CBC-CS2 AFT and MCT responses.¶
The following shows AES-CBC-CS3 AFT and MCT request vectors.¶
The following shows AES-CBC-CS3 AFT and MCT responses.¶
The following shows AES-ECB AFT and MCT request vectors.¶
The following shows AES-ECB AFT and MCT responses.¶
The following shows AES-OFB AFT and MCT request vectors.¶
The following shows AES-OFB AFT and MCT responses.¶
The following shows AES-CFB1 AFT and MCT request vectors.¶
The following shows AES-CFB1 AFT and MCT responses.¶
The following shows AES-CFB8 AFT and MCT request vectors.¶
The following shows AES-CFB8 AFT and MCT responses.¶
The following shows AES-CFB128 AFT and MCT request vectors.¶
The following shows AES-CFB128 AFT and MCT responses.¶
The following shows AES-CTR AFT and counter request vectors.¶
The following shows AES-CTR AFT and counter responses.¶
The following shows AES-XPN AFT request vectors.¶
The following shows AES-XPN AFT responses.¶
The following shows AES-XTS AFT request vectors.¶
The following shows AES-XTS AFT responses.¶
The following shows AES-KW request vectors.¶
The following shows AES-KW responses.¶
The following shows AES-KWP request vectors.¶
The following shows AES-KWP responses.¶
The following is a example JSON object for test vectors sent from the ACVP server to the crypto module for an TDES-ECB algorithm functional test.¶
The following is a example JSON object for test results sent from the crypto module to the ACVP server for an TDES-ECB algorithm functional test.¶
The following is a example JSON object for test vectors sent from the ACVP server to the crypto module for the TDES-CFB1 algorithm functional test.¶
The following is a example JSON object for test results sent from the crypto module to the ACVP server for an TDES-CFB1 algorithm functional test.¶
The following is a example JSON object for test vectors sent from the ACVP server to the crypto module for an TDES-ECB Monte Carlo test.¶
The following is a example JSON object for test results sent from the crypto module to the ACVP server for an TDES-ECB Monte Carlo test, only 2 iterations shown for brevity. For MCT results of each iteration are fed into the next iteration. Therefore the results carry all fields to assist in any failure diagnosis.¶