Crypto Tests

Starting with version 4.3.2, libstrongswan supports self tests of crypto algorithms. As pluto and charon use the same crypto plugins, both daemons benefit from this framework. Currently the crypto tester supports testing of encryption algorithms, integrity algorithms, hash functions, pseudo random functions and random number generators.

Test vectors

The self test framework is always built into the crypto factory. But to actually run the self tests, the framework requires test vectors. Any plugin can register test vectors with the crypto factory. strongSwan ships with a default set of test vectors in a separate test_vector plugin. To build and load the plugin, add

--enable-test-vectors

to your ./configure options.

Running tests

There are currently two ways to run crypto tests:

At startup

During daemon initialization, each plugin registers the crypto algorithms it provides. To accept an implementation, the algorithms can be tested by setting the following in strongswan.conf.

libstrongswan {
  crypto_test {
    on_add = yes
  }
}

Implementations failing a test vector are not accepted and can't be used by the daemon. Adding

   required = yes

to the crypto_test section above requires an algorithm to be tested at least against one vector. If no test vectors are available, the algorithm will not be available to the daemon.

During operation

Besides, or in addition to, startup tests the crypto factory can run algorithm tests each time a crypto primitive is instantiated. This gives you some guarantee that an implementation is behaving correctly over a longer time period. But keep in mind: Some crypto primitives are instantiated only once at startup and used over the whole runtime. These are not tested periodically.

Adding

   on_create = yes

to the crypto_test section enables self testing during instantiation. You can also use the required option discussed above.

Entropy for RNG tests

Depending on your test vectors, testing random number generators needs some thousand bytes of input. This might be problematic for RNGs with high quality, as such implementations often block if not enough entropy is available.

Testing RNGs with RNG_TRUE quality is disabled by default, as you usually do not have enough entropy to complete the tests in reasonable time. If you have a hardware based source of randomness, you can enable the tests for high quality RNGs by adding

   rng_true = yes

to the crypto_test section.