mbedtls/programs
Gilles Peskine b99bd39b4e Merge mbed-crypto into mbedtls: the merge commit
Merge `unremove-non-crypto` into `mbedtls/development`. The branch
`unremove-non-crypto` was obtained by starting from `mbed-crypto/development`,
then reverting many commits that removed X.509 and TLS functionality when Mbed
Crypto forked from Mbed TLS (the “unremoval”), then make a few tweaks to
facilitate the merge.

The unremoval step restored old versions of some tls files. If a file doesn't
exist in mbed-crypto, check out the mbedtls version, regardless of what
happened during the unremoval of tls files in the crypto tree. Also
unconditionally take the mbedtls version of a few files where the
modifications are completely project-specific and are not relevant in
mbed-crypto:

* `.github/issue_template.md`: completely different. We may want to reconcile
  them independently as a follow-up.
* `.travis.yml`: would only be reverted to an earlier tls version.
* `README.md`: completely different. We may want to reconcile them
  independently as a follow-up.
* `doxygen/input/doc_mainpage.h`: the changes in crypto were minimal and not
  relevant except as a stopgap as mbed-crypto did not have its own product
  versioning in the Doxygen documentation.
* `tests/.jenkins/Jenkinsfile`: completely different.
* `tests/data_files/Makefile`: there were no changes in mbed-crypto,
  but the unremoval step restored an old version.

Shell script for everything to do after the merge apart from the conflict
resolution:
```
tls_files=($(comm -23 <(git ls-tree -r --name-only HEAD) <(git ls-tree -r --name-only $(git merge-base upstream-crypto/development MERGE_HEAD))))
tls_files+=($tls_files .github/issue_template.md .travis.yml README.md doxygen/input/doc_mainpage.h tests/.jenkins/Jenkinsfile tests/data_files/Makefile)
git checkout --theirs HEAD -- $tls_files
git add -- $tls_files
```

Resolve the remaining conflicts:

* `library/CMakeLists.txt`:
    * Keep the TLS definition of `src_crypto`
    * `USE_SHARED_MBEDTLS_LIBRARY`: keep all three libraries, with both
      `include` and `crypto/include` in `target_include_directories`, all with
      version `2.21.0`.
* `programs/Makefile`:
    * Reconcile the APPS lists (add/add from a differently-formatted common
      ancestor): insert the `psa/*` from crypto into the tls list.
    * Keep the `fuzz` target defined only in tls version.
    * Keep the recipe (only in tls version) cleaning `ssl_pthread_server`
      stuff for the `clean` target.
* `scripts/config.py`:
    * `include_in_full`: add/add conflict. Keep both.
* `tests/scripts/all.sh`:
    * `component_test_no_use_psa_crypto_full_cmake_asan`: partially old
      version in crypto. Take the tls version.
    * `component_test_malloc_0_null` and more: take
      `component_test_malloc_0_null` from crypto (with `config.py` rather than
      `config.pl`, and with `$ASAN_FLAGS` rather than an explicit list), but
      add the call to `ssl-opt.sh` from tls. Take the other components from
      crypto.

With this commit, building and running the unit tests with both `make ` and
`cmake` work in the default configuration on Linux. Other platforms, build
systems and configurations are likely not to work, and there is some
regression in test coverage.

There is some loss of functionality because the unremoval step restored older
versions of tls content. This commit contains the latest tls version of
tls-only files, but some changes from the tls side in files that existed on
both sides have regressed. Most problematic changes are hunks that remove some
tls-specific feature and contain either a C preprocessor symbol identifying a
tls-specific module or option, or the name of a tls-specific file. Hunks
that remove a tls-specific preprocessor symbol can be identified with the
regular expression `^-.*MBEDTLS_(ERR_)?(PKCS11|X509|NET|SSL)_`.

Subsequent commits will revert a few parts of the patch from this merge commit
in order to restore the tls functionality that it removes, ensure that the
test coverage includes what was covered in either branch, and fix test
failures.
2020-03-23 17:54:46 +01:00
..
aes Revert "programs, tests: Depend only on libmbedcrypto" 2020-03-19 14:07:55 +01:00
fuzz If a key is not of a supported type, something went wrong 2020-02-25 19:54:27 +01:00
hash Revert "programs, tests: Depend only on libmbedcrypto" 2020-03-19 14:07:55 +01:00
pkey Revert "Remove Diffie-Hellman examples" 2020-03-19 14:23:45 +01:00
psa Revert "programs, tests: Depend only on libmbedcrypto" 2020-03-19 14:07:55 +01:00
random Revert "programs, tests: Depend only on libmbedcrypto" 2020-03-19 14:07:55 +01:00
ssl Revert "Remove programs that depend on TLS or X.509" 2020-03-19 14:07:55 +01:00
test Merge mbed-crypto into mbedtls: the merge commit 2020-03-23 17:54:46 +01:00
util Revert "programs, tests: Depend only on libmbedcrypto" 2020-03-19 14:07:55 +01:00
x509 Revert "Remove programs that depend on TLS or X.509" 2020-03-19 14:07:55 +01:00
.gitignore Revert "Remove Diffie-Hellman examples" 2020-03-19 14:23:45 +01:00
CMakeLists.txt Revert "Remove programs that depend on TLS or X.509" 2020-03-19 14:07:55 +01:00
Makefile Merge mbed-crypto into mbedtls: the merge commit 2020-03-23 17:54:46 +01:00
README.md Revert "Remove Diffie-Hellman examples" 2020-03-19 14:23:45 +01:00
wince_main.c

Mbed TLS sample programs

This subdirectory mostly contains sample programs that illustrate specific features of the library, as well as a few test and support programs.

Symmetric cryptography (AES) examples

  • aes/aescrypt2.c: file encryption and authentication with a key derived from a low-entropy secret, demonstrating the low-level AES interface, the digest interface and HMAC.
    Warning: this program illustrates how to use low-level functions in the library. It should not be taken as an example of how to build a secure encryption mechanism. To derive a key from a low-entropy secret such as a password, use a standard key stretching mechanism such as PBKDF2 (provided by the pkcs5 module). To encrypt and authenticate data, use a standard mode such as GCM or CCM (both available as library module).

  • aes/crypt_and_hash.c: file encryption and authentication, demonstrating the generic cipher interface and the generic hash interface.

Hash (digest) examples

Public-key cryptography examples

Generic public-key cryptography (pk) examples

  • pkey/gen_key.c: generates a key for any of the supported public-key algorithms (RSA or ECC) and writes it to a file that can be used by the other pk sample programs.

  • pkey/key_app.c: loads a PEM or DER public key or private key file and dumps its content.

  • pkey/key_app_writer.c: loads a PEM or DER public key or private key file and writes it to a new PEM or DER file.

  • pkey/pk_encrypt.c, pkey/pk_decrypt.c: loads a PEM or DER public/private key file and uses the key to encrypt/decrypt a short string through the generic public-key interface.

  • pkey/pk_sign.c, pkey/pk_verify.c: loads a PEM or DER private/public key file and uses the key to sign/verify a short string.

ECDSA and RSA signature examples

Diffie-Hellman key exchange examples

  • pkey/dh_client.c, pkey/dh_server.c: secure channel demonstrators (client, server). This pair of programs illustrates how to set up a secure channel using RSA for authentication and Diffie-Hellman to generate a shared AES session key.

  • pkey/ecdh_curve25519.c: demonstration of a elliptic curve Diffie-Hellman (ECDH) key agreement.

Bignum (mpi) usage examples

Random number generator (RNG) examples

  • random/gen_entropy.c: shows how to use the default entropy sources to generate random data.
    Note: most applications should only use the entropy generator to seed a cryptographic pseudorandom generator, as illustrated by random/gen_random_ctr_drbg.c.

  • random/gen_random_ctr_drbg.c: shows how to use the default entropy sources to seed a pseudorandom generator, and how to use the resulting random generator to generate random data.

  • random/gen_random_havege.c: demonstrates the HAVEGE entropy collector.

SSL/TLS examples

SSL/TLS sample applications

  • ssl/dtls_client.c: a simple DTLS client program, which sends one datagram to the server and reads one datagram in response.

  • ssl/dtls_server.c: a simple DTLS server program, which expects one datagram from the client and writes one datagram in response. This program supports DTLS cookies for hello verification.

  • ssl/mini_client.c: a minimalistic SSL client, which sends a short string and disconnects. This is primarily intended as a benchmark; for a better example of a typical TLS client, see ssl/ssl_client1.c.

  • ssl/ssl_client1.c: a simple HTTPS client that sends a fixed request and displays the response.

  • ssl/ssl_fork_server.c: a simple HTTPS server using one process per client to send a fixed response. This program requires a Unix/POSIX environment implementing the fork system call.

  • ssl/ssl_mail_client.c: a simple SMTP-over-TLS or SMTP-STARTTLS client. This client sends an email with fixed content.

  • ssl/ssl_pthread_server.c: a simple HTTPS server using one thread per client to send a fixed response. This program requires the pthread library.

  • ssl/ssl_server.c: a simple HTTPS server that sends a fixed response. It serves a single client at a time.

SSL/TLS feature demonstrators

Note: unlike most of the other programs under the programs/ directory, these two programs are not intended as a basis for writing an application. They combine most of the features supported by the library, and most applications require only a few features. To write a new application, we recommended that you start with ssl_client1.c or ssl_server.c, and then look inside ssl/ssl_client2.c or ssl/ssl_server2.c to see how to use the specific features that your application needs.

  • ssl/ssl_client2.c: an HTTPS client that sends a fixed request and displays the response, with options to select TLS protocol features and Mbed TLS library features.

  • ssl/ssl_server2.c: an HTTPS server that sends a fixed response, with options to select TLS protocol features and Mbed TLS library features.

In addition to providing options for testing client-side features, the ssl_client2 program has options that allow you to trigger certain behaviors in the server. For example, there are options to select ciphersuites, or to force a renegotiation. These options are useful for testing the corresponding features in a TLS server. Likewise, ssl_server2 has options to activate certain behaviors that are useful for testing a TLS client.

Test utilities

Development utilities

  • util/pem2der.c: a PEM to DER converter. Mbed TLS can read PEM files directly, but this utility can be useful for interacting with other tools or with minimal Mbed TLS builds that lack PEM support.

  • util/strerror.c: prints the error description corresponding to an integer status returned by an Mbed TLS function.

X.509 certificate examples

  • x509/cert_app.c: connects to a TLS server and verifies its certificate chain.

  • x509/cert_req.c: generates a certificate signing request (CSR) for a private key.

  • x509/cert_write.c: signs a certificate signing request, or self-signs a certificate.

  • x509/crl_app.c: loads and dumps a certificate revocation list (CRL).

  • x509/req_app.c: loads and dumps a certificate signing request (CSR).