Next: , Previous: Architecture, Up: Top


Appendix A Description of the Self-Tests

In addition to the build time regression test suite, Libgcrypt implements self-tests to be performed at runtime. Which self-tests are actually used depends on the mode Libgcrypt is used in. In standard mode a limited set of self-tests is run at the time an algorithm is first used. Note that not all algorithms feature a self-test in standard mode. The GCRYCTL_SELFTEST control command may be used to run all implemented self-tests at any time; this will even run more tests than those run in FIPS mode.

If any of the self-tests fails, the library immediately returns an error code to the caller. If Libgcrypt is in FIPS mode the self-tests will be performed within the “Self-Test” state and any failure puts the library into the “Error” state.

A.1 Power-Up Tests

Power-up tests are only performed if Libgcrypt is in FIPS mode.

A.1.1 Symmetric Cipher Algorithm Power-Up Tests

The following symmetric encryption algorithm tests are run during power-up:

3DES
To test the 3DES 3-key EDE encryption in ECB mode these tests are run:
  1. A known answer test is run on a 64 bit test vector processed by 64 rounds of Single-DES block encryption and decryption using a key changed with each round.
  2. A known answer test is run on a 64 bit test vector processed by 16 rounds of 2-key and 3-key Triple-DES block encryption and decryptions using a key changed with each round.
  3. 10 known answer tests using 3-key Triple-DES EDE encryption, comparing the ciphertext to the known value, then running a decryption and comparing it to the initial plaintext.
(cipher/des.c:selftest)
AES-128
A known answer tests is run using one test vector and one test key with AES in ECB mode. (cipher/rijndael.c:selftest_basic_128)
AES-192
A known answer tests is run using one test vector and one test key with AES in ECB mode. (cipher/rijndael.c:selftest_basic_192)
AES-256
A known answer tests is run using one test vector and one test key with AES in ECB mode. (cipher/rijndael.c:selftest_basic_256)

A.1.2 Hash Algorithm Power-Up Tests

The following hash algorithm tests are run during power-up:

SHA-1
A known answer test using the string "abc" is run. (cipher/sha1.c:selftests_sha1)
SHA-224
A known answer test using the string "abc" is run. (cipher/sha256.c:selftests_sha224)
SHA-256
A known answer test using the string "abc" is run. (cipher/sha256.c:selftests_sha256)
SHA-384
A known answer test using the string "abc" is run. (cipher/sha512.c:selftests_sha384)
SHA-512
A known answer test using the string "abc" is run. (cipher/sha512.c:selftests_sha512)

A.1.3 MAC Algorithm Power-Up Tests

The following MAC algorithm tests are run during power-up:

HMAC SHA-1
A known answer test using 9 byte of data and a 64 byte key is run. (cipher/hmac-tests.c:selftests_sha1)
HMAC SHA-224
A known answer test using 28 byte of data and a 4 byte key is run. (cipher/hmac-tests.c:selftests_sha224)
HMAC SHA-256
A known answer test using 28 byte of data and a 4 byte key is run. (cipher/hmac-tests.c:selftests_sha256)
HMAC SHA-384
A known answer test using 28 byte of data and a 4 byte key is run. (cipher/hmac-tests.c:selftests_sha384)
HMAC SHA-512
A known answer test using 28 byte of data and a 4 byte key is run. (cipher/hmac-tests.c:selftests_sha512)

A.1.4 Random Number Power-Up Test

The DRNG is tested during power-up this way:

  1. Requesting one block of random using the public interface to check general working and the duplicated block detection.
  2. 3 know answer tests using pre-defined keys, seed and initial DT values. For each test 3 blocks of 16 bytes are requested and compared to the expected result. The DT value is incremented for each block.

A.1.5 Public Key Algorithm Power-Up Tests

The public key algorithms are tested during power-up:

RSA
A pre-defined 1024 bit RSA key is used and these tests are run in turn:
  1. Conversion of S-expression to internal format. (cipher/rsa.c:selftests_rsa)
  2. Private key consistency check. (cipher/rsa.c:selftests_rsa)
  3. A pre-defined 20 byte value is signed with PKCS#1 padding for SHA-1. The result is verified using the public key against the original data and against modified data. (cipher/rsa.c:selftest_sign_1024)
  4. A 1000 bit random value is encrypted and checked that it does not match the orginal random value. The encrtypted result is then decrypted and checked that it macthes the original random value. (cipher/rsa.c:selftest_encr_1024)

DSA
A pre-defined 1024 bit DSA key is used and these tests are run in turn:
  1. Conversion of S-expression to internal format. (cipher/dsa.c:selftests_dsa)
  2. Private key consistency check. (cipher/dsa.c:selftests_dsa)
  3. A pre-defined 20 byte value is signed with PKCS#1 padding for SHA-1. The result is verified using the public key against the original data and against modified data. (cipher/dsa.c:selftest_sign_1024)

A.1.6 Integrity Power-Up Tests

The integrity of the Libgcrypt is tested during power-up but only if checking has been enabled at build time. The check works by computing a HMAC SHA-256 checksum over the file used to load Libgcrypt into memory. That checksum is compared against a checksum stored in a file of the same name but with a single dot as a prefix and a suffix of .hmac.

A.1.7 Critical Functions Power-Up Tests

The 3DES weak key detection is tested during power-up by calling the detection function with keys taken from a table listening all weak keys. The table itself is protected using a SHA-1 hash. (cipher/des.c:selftest)

A.2 Conditional Tests

The conditional tests are performed if a certain contidion is met. This may occur at any time; the library does not necessary enter the “Self-Test” state to run these tests but will transit to the “Error” state if a test failed.

A.2.1 Key-Pair Generation Tests

After an asymmetric key-pair has been generated, Libgcrypt runs a pair-wise consistency tests on the generated key. On failure the generated key is not used, an error code is returned and, if in FIPS mode, the library is put into the “Error” state.

RSA
The test uses a random number 64 bits less the size of the modulus as plaintext and runs an encryption and decryption operation in turn. The encrypted value is checked to not match the plaintext and the result of the decryption is checked to match the plaintext.

A new random number of the same size is generated, signed and verified to test the correctness of the signing operation. As a second signing test, the signature is modified by incrementing its value and then verified with the expected result that the verification fails. (cipher/rsa.c:test_keys)

DSA
The test uses a random number of the size of the Q parameter to create a signature and then checks that the signature verifies. As a second signing test, the data is modified by incrementing its value and then verified against the signature with the expected result that the verification fails. (cipher/dsa.c:test_keys)

A.2.2 Software Load Tests

Loading of extra modules into libgcrypt is disabled in FIPS mode and thus no tests are implemented. (cipher/cipher.c:_gcry_cipher_register, cipher/md.c:_gcry_md_register, cipher/pubkey.c:_gcry_pk_register)

A.2.3 Manual Key Entry Tests

A manual key entry feature is not implemented in Libgcrypt.

A.2.4 Continuous RNG Tests

The continuous random number test is only used in FIPS mode. The RNG generates blocks of 128 bit size; the first block generated per context is saved in the context and another block is generated to be returned to the caller. Each block is compared against the saved block and then stored in the context. If a duplicated block is detected an error is signaled and the library is put into the “Fatal-Error” state. (random/random-fips.c:x931_aes_driver)

A.3 Application Requested Tests

The application may requests tests at any time by means of the GCRYCTL_SELFTEST control command. Note that using these tests is not FIPS conform: Although Libgcrypt rejects all application requests for services while running self-tests, it does not ensure that no other operations of Libgcrypt are still being executed. Thus, in FIPS mode an application requesting self-tests needs to power-cycle Libgcrypt instead.

When self-tests are requested, Libgcrypt runs all the tests it does during power-up as well as a few extra checks as described below.

A.3.1 Symmetric Cipher Algorithm Tests

The following symmetric encryption algorithm tests are run in addition to the power-up tests:

AES-128
A known answer tests with test vectors taken from NIST SP800-38a and using the high level functions is run for block modes CFB and OFB.

A.3.2 Hash Algorithm Tests

The following hash algorithm tests are run in addition to the power-up tests:

SHA-1
SHA-224
SHA-256
  1. A known answer test using a 56 byte string is run.
  2. A known answer test using a string of one million letters "a" is run.
(cipher/sha1.c:selftests_sha1, cipher/sha256.c:selftests_sha224, cipher/sha256.c:selftests_sha256)
SHA-384
SHA-512
  1. A known answer test using a 112 byte string is run.
  2. A known answer test using a string of one million letters "a" is run.
(cipher/sha512.c:selftests_sha384, cipher/sha512.c:selftests_sha512)

A.3.3 MAC Algorithm Tests

The following MAC algorithm tests are run in addition to the power-up tests:

HMAC SHA-1
  1. A known answer test using 9 byte of data and a 20 byte key is run.
  2. A known answer test using 9 byte of data and a 100 byte key is run.
  3. A known answer test using 9 byte of data and a 49 byte key is run.
(cipher/hmac-tests.c:selftests_sha1)
HMAC SHA-224
HMAC SHA-256
HMAC SHA-384
HMAC SHA-512
  1. A known answer test using 9 byte of data and a 20 byte key is run.
  2. A known answer test using 50 byte of data and a 20 byte key is run.
  3. A known answer test using 50 byte of data and a 26 byte key is run.
  4. A known answer test using 54 byte of data and a 131 byte key is run.
  5. A known answer test using 152 byte of data and a 131 byte key is run.
(cipher/hmac-tests.c:selftests_sha224, cipher/hmac-tests.c:selftests_sha256, cipher/hmac-tests.c:selftests_sha384, cipher/hmac-tests.c:selftests_sha512)