9afbfdc833
First deal with deleted files.
* Files deleted by us: keep them deleted.
* Files deleted by them, whether modified by us or not: keep our version.
```
git rm $(git status -s | sed -n 's/^DU //p')
git reset -- $(git status -s | sed -n 's/^D //p')
git checkout -- $(git status -s | sed -n 's/^ D //p')
git add -- $(git status -s | sed -n 's/^UD //p')
```
Individual files with conflicts:
* `3rdparty/everest/library/Hacl_Curve25519_joined.c`: spurious conflict because git mistakenly identified this file as a rename. Keep our version.
* `README.md`: conflict due to their change in a paragraph that doesn't exist in our version. Keep our version of this paragraph.
* `docs/architecture/Makefile`: near-identical additions. Adapt the definition of `all_markdown` and include the clean target.
* `doxygen/input/docs_mainpage.h`: conflict in the version number. Keep our version number.
* `include/mbedtls/config.h`: two delete/modify conflicts. Keep the removed chunks out.
* `library/CMakeLists.txt`: discard all their changes as they are not relevant.
* `library/Makefile`:
* Discard the added chunk about the crypto submodule starting with `INCLUDING_FROM_MBEDTLS:=1`.
* delete/modify: keep the removed chunk out.
* library build: This is almost delete/modify. Their changes are mostly not applicable. Do keep the `libmbedcrypto.$(DLEXT): | libmbedcrypto.a` order dependency.
* `.c.o`: `-o` was added on both sides but in a different place. Change to their place.
* `library/error.c`: to be regenerated.
* `library/version_features.c`: to be regenerated.
* `programs/Makefile`: Most of the changes are not relevant. The one relevant change is in the `clean` target for Windows; adapt it by removing `/S` from our version.
* `programs/test/query_config.c`: to be regenerated.
* `scripts/config.py`: added in parallel on both sides. Keep our version.
* `scripts/footprint.sh`: parallel changes. Keep our version.
* `scripts/generate_visualc_files.pl`: one delete/modify conflict. Keep the removed chunks out.
* `tests/Makefile`: discard all of their changes.
* `tests/scripts/all.sh`:
* `pre_initialize_variables` add `append_outcome`: add it.
* `pre_initialize_variables` add `ASAN_CFLAGS`: already there, keep our version.
* `pre_parse_command_line` add `--no-append-outcome`: add it.
* `pre_parse_command_line` add `--outcome-file`: add it.
* `pre_print_configuration`: add `MBEDTLS_TEST_OUTCOME_FILE`.
* Several changes in SSL-specific components: keep our version without them.
* Several changes where `config.pl` was changed to `config.py` and there was an adjacent difference: keep our version.
* Changes regarding the inclusion of `MBEDTLS_MEMORY_xxx`: ignore them here, they will be normalized in a subsequent commit.
* `component_test_full_cmake_gcc_asan`: add it without the TLS tests.
* `component_test_no_use_psa_crypto_full_cmake_asan`: keep the fixed `msg`, discard other changes.
* `component_test_memory_buffer_allocator_backtrace`, `component_test_memory_buffer_allocator`: add them without the TLS tests.
* `component_test_m32_everest`: added in parallel on both sides. Keep our version.
* `tests/scripts/check-names.sh`, `tests/scripts/list-enum-consts.pl`, `tests/scripts/list-identifiers.sh`, ``tests/scripts/list-macros.sh`: discard all of their changes.
* `tests/scripts/test-ref-configs.pl`: the change in the conflict is not relevant, so keep our version there.
* `visualc/VS2010/*.vcxproj`: to be regenerated.
Regenerate files:
```
scripts/generate_visualc_files.pl
git add visualc/VS2010/*.vcxproj
scripts/generate_errors.pl
git add library/error.c
scripts/generate_features.pl
git add library/version_features.c
scripts/generate_query_config.pl
git add programs/test/query_config.c
```
Rejected changes in non-conflicting files:
* `CMakeLists.txt`: discard their addition which has already been side-ported.
* `doxygen/mbedtls.doxyfile`: keep the version number change. Discard the changes related to `../crypto` paths.
Keep the following changes after examination:
* `.travis.yml`: all of their changes are relevant.
* `include/mbedtls/error.h`: do keep their changes. Even though Crypto doesn't use TLS errors, it must not encroach on TLS's allocated numbers.
* `tests/scripts/check-test-cases.py`: keep the code dealing with `ssl-opt.sh`. It works correctly when the file is not present.
|
||
|---|---|---|
| .. | ||
| aes | ||
| hash | ||
| pkey | ||
| psa | ||
| random | ||
| test | ||
| util | ||
| .gitignore | ||
| CMakeLists.txt | ||
| Makefile | ||
| README.md | ||
| 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 thepkcs5module). 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
-
hash/generic_sum.c: file hash calculator and verifier, demonstrating the message digest (md) interface. -
hash/hello.c: hello-world program for MD5.
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
-
pkey/ecdsa.c: generates an ECDSA key, signs a fixed message and verifies the signature. -
pkey/rsa_encrypt.c,pkey/rsa_decrypt.c: loads an RSA public/private key and uses it to encrypt/decrypt a short string through the low-level RSA interface. -
pkey/rsa_genkey.c: generates an RSA key and writes it to a file that can be used with the other RSA sample programs. -
pkey/rsa_sign.c,pkey/rsa_verify.c: loads an RSA private/public key and uses it to sign/verify a short string with the RSA PKCS#1 v1.5 algorithm. -
pkey/rsa_sign_pss.c,pkey/rsa_verify_pss.c: loads an RSA private/public key and uses it to sign/verify a short string with the RSASSA-PSS algorithm.
Diffie-Hellman key exchange examples
pkey/ecdh_curve25519.c: demonstration of a elliptic curve Diffie-Hellman (ECDH) key agreement.
Bignum (mpi) usage examples
-
pkey/dh_genprime.c: shows how to use the bignum (mpi) interface to generate Diffie-Hellman parameters. -
pkey/mpi_demo.c: demonstrates operations on big integers.
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 byrandom/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.
Test utilities
-
test/benchmark.c: benchmark for cryptographic algorithms. -
test/selftest.c: runs the self-test function in each library module. -
test/udp_proxy.c: a UDP proxy that can inject certain failures (delay, duplicate, drop). Useful for testing DTLS. -
test/zeroize.c: a test program formbedtls_platform_zeroize, used bytests/scripts/test_zeroize.gdb.
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.