mbedtls_aes_crypt_xts() currently takes a `bits_length` parameter, unlike
the other block modes. Change the parameter to accept a bytes length
instead, as the `bits_length` parameter is not actually ever used in the
current implementation.
Add a new context structure for XTS. Adjust the API for XTS to use the new
context structure, including tests suites and the benchmark program. Update
Doxgen documentation accordingly.
AES-XEX is a building block for other cryptographic standards and not yet a
standard in and of itself. We'll just provide the standardized AES-XTS
algorithm, and not AES-XEX. The AES-XTS algorithm and interface provided
can be used to perform the AES-XEX algorithm when the length of the input
is a multiple of the AES block size.
XTS mode is fully known as "xor-encrypt-xor with ciphertext-stealing".
This is the generalization of the XEX mode.
This implementation is limited to an 8-bits (1 byte) boundary, which
doesn't seem to be what was thought considering some test vectors [1].
This commit comes with tests, extracted from [1], and benchmarks.
Although, benchmarks aren't really nice here, as they work with a buffer
of a multiple of 16 bytes, which isn't a challenge for XTS compared to
XEX.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
The test cases come from the XTS test vectors given by the CAVP initiative
from NIST (see [1]).
As mentioned in a previous commit, XEX is a simpler case of XTS.
Therefore, to construct the test_suite_aes.xex.data file, extraction of
the XEX-possible cases has been done on the given test vectors.
All of the extracted test vectors pass the tests on a Linux x86_64 machine.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
Adds error handling into mbedtls_aes_crypt_ofb for AES errors, a self-test
for the OFB mode using NIST SP 800-38A test vectors and adds a check to
potential return errors in setting the AES encryption key in the OFB test
suite.
* development: (97 commits)
Updated version number to 2.10.0 for release
Add a disabled CMAC define in the no-entropy configuration
Adapt the ARIA test cases for new ECB function
Fix file permissions for ssl.h
Add ChangeLog entry for PR#1651
Fix MicroBlaze register typo.
Fix typo in doc and copy missing warning
Fix edit mistake in cipher_wrap.c
Update CTR doc for the 64-bit block cipher
Update CTR doc for other 128-bit block ciphers
Slightly tune ARIA CTR documentation
Remove double declaration of mbedtls_ssl_list_ciphersuites
Update CTR documentation
Use zeroize function from new platform_util
Move to new header style for ALT implementations
Add ifdef for selftest in header file
Fix typo in comments
Use more appropriate type for local variable
Remove useless parameter from function
Wipe sensitive info from the stack
...
Commit 08c337d058 "Remove useless parameter from function" removed the
parameter mode from the functions mbedtls_aria_crypt_ecb() which broke their
respective test suite.
This commit fixes those test cases.
Allowing DECRYPT with crypt_and_tag is a risk as people might fail to check
the tag correctly (or at all). So force them to use auth_decrypt() instead.
See also https://github.com/ARMmbed/mbedtls/pull/1668
- need HW failure codes too
- re-use relevant poly codes for chachapoly to save on limited space
Values were chosen to leave 3 free slots at the end of the NET odd range.
This module used (len, pointer) while (pointer, len) is more common in the
rest of the library, in particular it's what's used in the CMAC API that is
very comparable to Poly1305, so switch to (pointer, len) for consistency.
In addition to making the APIs of the various AEAD modules more consistent
with each other, it's useful to have an auth_decrypt() function so that we can
safely check the tag ourselves, as the user might otherwise do it in an
insecure way (or even forget to do it altogether).
While the old name is explicit and aligned with the RFC, it's also very long,
so with the mbedtls_ prefix prepended we get a 31-char prefix to each
identifier, which quickly conflicts with our 80-column policy.
The new name is shorter, it's what a lot of people use when speaking about
that construction anyway, and hopefully should not introduce confusion at
it seems unlikely that variants other than 20/1305 be standardised in the
foreseeable future.
This implementation is based off the description in RFC 7539.
The ChaCha20 code is also updated to provide a means of generating
keystream blocks with arbitrary counter values. This is used to
generated the one-time Poly1305 key in the AEAD construction.
* development: (504 commits)
Fix minor code style issues
Add the uodate to the soversion to the ChangeLog
Fix the ChangeLog for clarity, english and credit
Update version to 2.9.0
ecp: Fix binary compatibility with group ID
Changelog entry
Change accepted ciphersuite versions when parsing server hello
Remove preprocessor directives around platform_util.h include
Fix style for mbedtls_mpi_zeroize()
Improve mbedtls_platform_zeroize() docs
mbedtls_zeroize -> mbedtls_platform_zeroize in docs
Reword config.h docs for MBEDTLS_PLATFORM_ZEROIZE_ALT
Organize CMakeLists targets in alphabetical order
Organize output objs in alfabetical order in Makefile
Regenerate errors after ecp.h updates
Update ecp.h
Change variable bytes_written to header_bytes in record decompression
Update ecp.h
Update ecp.h
Update ecp.h
...
The specification requires that numbers are the raw entropy (except for odd/
even) and at least 2^(nbits-0.5). If not, new random bits need to be used for
the next number. Similarly, if the number is not prime new random bits need to
be used.
Conflict resolution:
* ChangeLog
* tests/data_files/Makefile: concurrent additions, order irrelevant
* tests/data_files/test-ca.opensslconf: concurrent additions, order irrelevant
* tests/scripts/all.sh: one comment change conflicted with a code
addition. In addition some of the additions in the
iotssl-1381-x509-verify-refactor-restricted branch need support for
keep-going mode, this will be added in a subsequent commit.
The relevant ASN.1 definitions for a PKCS#8 encoded Elliptic Curve key are:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
Because of the two optional fields, there are 4 possible variants that need to
be parsed: no optional fields, only parameters, only public key, and both
optional fields. Previously mbedTLS was unable to parse keys with "only
parameters". Also, only "only public key" was tested. There was a test for "no
optional fields", but it was labelled incorrectly as SEC.1 and not run because
of a great renaming mixup.
The 'critical' boolean can be set to false in two ways:
- by leaving it implicit (test data generated by openssl)
- by explicitly setting it to false (generated by hand)
This covers all lines added in the previous commit. Coverage was tested using:
make CFLAGS='--coverage -g3 -O0'
(cd tests && ./test_suite_x509parse)
make lcov
firefox Coverage/index.html # then visual check
Test data was generated by taking a copy of tests/data_files/crl-idp.pem,
encoding it as hex, and then manually changing the values of some bytes to
achieve the desired errors, using https://lapo.it/asn1js/ for help in locating
the desired bytes.
Found by running:
CC=clang cmake -D CMAKE_BUILD_TYPE="Check"
tests/scripts/depend-pkalgs.pl
(Also tested with same command but CC=gcc)
Another PR will address improving all.sh and/or the depend-xxx.pl scripts
themselves to catch this kind of thing.
* development: (557 commits)
Add attribution for #1351 report
Adapt version_features.c
Note incompatibility of truncated HMAC extension in ChangeLog
Add LinkLibraryDependencies to VS2010 app template
Add ChangeLog entry for PR #1382
MD: Make deprecated functions not inline
Add ChangeLog entry for PR #1384
Have Visual Studio handle linking to mbedTLS.lib internally
Mention in ChangeLog that this fixes#1351
Add issue number to ChangeLog
Note in the changelog that this fixes an interoperability issue.
Style fix in ChangeLog
Add ChangeLog entries for PR #1168 and #1362
Add ChangeLog entry for PR #1165
ctr_drbg: Typo fix in the file description comment.
dhm: Fix typo in RFC 5114 constants
tests_suite_pkparse: new PKCS8-v2 keys with PRF != SHA1
data_files/pkcs8-v2: add keys generated with PRF != SHA1
tests/pkcs5/pbkdf2_hmac: extend array to accommodate longer results
tests/pkcs5/pbkdf2_hmac: add unit tests for additional SHA algorithms
...
Extend the pkparse test suite with the newly created keys
encrypted using PKCS#8 with PKCS#5 v2.0 with PRF being
SHA224, 256, 384 and 512.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Some unit tests for pbkdf2_hmac() have results longer than
99bytes when represented in hexadecimal form.
For this reason extend the result array to accommodate
longer strings.
At the same time make memset() parametric to avoid
bugs in the future.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Test vectors for SHA224,256,384 and 512 have been
generated using Python's hashlib module by the
following oneliner:
import binascii, hashlib
binascii.hexlify(hashlib.pbkdf2_hmac(ALGO, binascii.unhexlify('PASSWORD'), binascii.unhexlify('SALT'), ITER, KEYLEN)))
where ALGO was 'sha224', 'sha256', 'sha384' and 'sha512'
respectively.
Values for PASSWORD, SALT, ITER and KEYLEN were copied from the
existent test vectors for SHA1.
For SHA256 we also have two test vectors coming from RFC7914 Sec 11.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Currently only SHA1 is supported as PRF algorithm for PBKDF2
(PKCS#5 v2.0).
This means that keys encrypted and authenticated using
another algorithm of the SHA family cannot be decrypted.
This deficiency has become particularly incumbent now that
PKIs created with OpenSSL1.1 are encrypting keys using
hmacSHA256 by default (OpenSSL1.0 used PKCS#5 v1.0 by default
and even if v2 was forced, it would still use hmacSHA1).
Enable support for all the digest algorithms of the SHA
family for PKCS#5 v2.0.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
1. Style issues fixes - remove redundant spacing.
2. Remove depency of `MBEDTLS_RSA_C` in `pk_parse_public_keyfile_rsa()`
tests, as the function itself is dependent on it.
This change fixes a problem in the tests pk_rsa_alt() and
pk_rsa_overflow() from test_suite_pk.function that would cause a
segmentation fault. The problem is that these tests are only designed
to run in computers where the SIZE_MAX > UINT_MAX.
Change function in tests named mbedtls_entropy_func to
mbedtls_test_entropy_func to avoid getting error from the linker when
calling the mbedtls_entropy_func elsewhere.
The _ext suffix suggests "new arguments", but the new functions have
the same arguments. Use _ret instead, to convey that the difference is
that the new functions return a value.
Conflict resolution:
* ChangeLog: put the new entries in their rightful place.
* library/x509write_crt.c: the change in development was whitespace
only, so use the one from the iotssl-1251 feature branch.
1) `mbedtls_rsa_import_raw` used an uninitialized return
value when it was called without any input parameters.
While not sensible, this is allowed and should be a
succeeding no-op.
2) The MPI test for prime generation missed a return value
check for a call to `mbedtls_mpi_shift_r`. This is neither
critical nor new but should be fixed.
3) Both the RSA keygeneration example program and the
RSA test suites contained code initializing an RSA context
after a potentially failing call to CTR DRBG initialization,
leaving the corresponding RSA context free call in the
cleanup section of the respective function orphaned.
While this defect existed before, Coverity picked up on
it again because of newly introduced MPI's that were
also wrongly initialized only after the call to CTR DRBG
init. The commit fixes both the old and the new issue
by moving the initializtion of both the RSA context and
all MPI's prior to the first potentially failing call.
* development:
Timing self test: shorten redundant tests
Timing self test: increased duration
Timing self test: increased tolerance
Timing unit tests: more protection against infinite loops
Unit test for mbedtls_timing_hardclock
New timing unit tests
selftest: allow excluding a subset of the tests
selftest: allow running a subset of the tests
selftest: refactor to separate the list of tests from the logic
Timing self test: print some diagnosis information
mbedtls_timing_get_timer: don't use uninitialized memory
timing interface documentation: minor clarifications
Timing: fix mbedtls_set_alarm(0) on Unix/POSIX
* public/pr/1136:
Timing self test: shorten redundant tests
Timing self test: increased duration
Timing self test: increased tolerance
Timing unit tests: more protection against infinite loops
Unit test for mbedtls_timing_hardclock
New timing unit tests
selftest: allow excluding a subset of the tests
selftest: allow running a subset of the tests
selftest: refactor to separate the list of tests from the logic
Timing self test: print some diagnosis information
mbedtls_timing_get_timer: don't use uninitialized memory
timing interface documentation: minor clarifications
Timing: fix mbedtls_set_alarm(0) on Unix/POSIX
* Correct order of sections in ChangeLog
* Restore unintentionally removed whitespace and
formatting improvements.
* Consistently rename MBEDTLS_ERR_RSA_EXPORT_UNSUPPORTED
to MBEDTLS_ERR_RSA_UNSUPPORTED_OPERATION in rsa.h
documentation.
During the work on the RSA change the issue was brought up,
and a fix was provided on development, that some RSA tests
use CTR DRBG and depend on the presence of a strong entropy
source to succeed. The RSA work introduced more tests using
CTR DRBG, and the dependency needs to be added for them, too.
If timing_timer_simple fails because it detects that timers are likely
to never expire (e.g. going backward or not incrementing), skip all
tests that rely on timers.
Do test mbedtls_timing_hardclock. We can't reliably test much about
it, but at least test that it doesn't crash, isn't constant, and
doesn't look completely random.
New set of unit tests for the timing module, instead of just running
the selftest function.
The selftest function sometimes fails on a heavily loaded
machine (such as a typical continuous integration system). Because of
the all-in-one nature of the test and because the exact load pattern
can be hard to reproduce, it is difficult to diagnose failures of CI
runs with selftest. The new tests are more separated and I strove to
point out potential failure modes in comments.
* mbedtls_timing_hardclock: not tested. This function gives so few
guarantees that there isn't much to test, and it is hard to test
reliably because clock cycles don't easily relate to time in any
remotely portable way. This function isn't used in the library
anyway, it's only there for benchmark programs.
* mbedtls_timing_get_timer: tested by setting a timer and verifying
that it reaches its target, and by verifying that a timer started
later than another always has a smaller elapsed time.
* mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it
and measuring the elapsed time with a timer.
* mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by
setting a delay object and watching it go through its two delay
values, using a timer to check that the delays are passed at the
expected time.
The tests pass under light to moderate load, but some of them can be
defeated with sufficiently heavy load. This is unavoidable since the
test process to be effectively suspended for any length of time,
making us think that a timer has gone on for too long.
* development:
Don't split error code description across multiple lines
Register new error code in error.h
Move deprecation to separate section in ChangeLog
Extend scope of ERR_RSA_UNSUPPORTED_OPERATION error code
Adapt RSA test suite
Adapt ChangeLog
Deprecate usage of RSA primitives with wrong key type
* restricted/pr/397:
Don't split error code description across multiple lines
Register new error code in error.h
Move deprecation to separate section in ChangeLog
Extend scope of ERR_RSA_UNSUPPORTED_OPERATION error code
Adapt RSA test suite
Adapt ChangeLog
Deprecate usage of RSA primitives with wrong key type
For a key of size 8N+1, check that the first byte after applying the
public key operation is 0 (it could have been 1 instead). The code was
incorrectly doing a no-op check instead, which led to invalid
signatures being accepted. Not a security flaw, since you would need the
private key to craft such an invalid signature, but a bug nonetheless.
The check introduced by the previous security fix was off by one. It
fixed the buffer overflow but was not compliant with the definition of
PSS which technically led to accepting some invalid signatures (but
not signatures made without the private key).
Fix buffer overflow in RSA-PSS signature verification when the hash is
too large for the key size. Found by Seth Terashima, Qualcomm.
Added a non-regression test and a positive test with the smallest
permitted key size for a SHA-512 hash.
1) use `pk_get_rsapubkey` instead of reimplementing the parsing
2) rename the key files, according to their type and key size
3) comment in the data_files/Makefile hoe the keys were generated
4) Fix issue of failure parsing pkcs#1 DER format parsing, missed in previous commit
The test case parses an RSA private key with N=P=Q=D=E=1 and expects a failure from the PK layer. With the weakened
semantics of `mbedtls_rsa_complete`, the latter won't throw an error on that key in case if MBEDTLS_RSA_NO_CRT is
set. This commit modifies the test case to use N=2 which is rejected by `mbedtls_rsa_complete` regardless of whether
MBEDTLS_RSA_NO_CRT is set or not.
The number of loop iterations per candidate in `mbedtls_deduce_primes` was off
by one. This commit corrects this and removes a toy non-example from the RSA
test suite, as it seems difficult to have the function fail on small values of N
even if D,E are corrupted.
This commit splits off the RSA helper functions into separate headers and
compilation units to have a clearer separation of the public RSA interface,
intended to be used by end-users, and the helper functions which are publicly
provided only for the benefit of designers of alternative RSA implementations.
The tests now accept two result parameters, one for the expected result of the
completion call, and one for the expected result of the subsequent sanity
check.
The change modifies the template code in tests/suites/helpers.function
and tests/suites/main.function so that error messages are printed to
stdout instead of being discarded. This makes errors visible regardless
of the --verbose flag being passed or not to the test suite programs.
The change modifies the template code in tests/suites/helpers.function
and tests/suites/main.function so that error messages are printed to
stdout instead of being discarded. This makes errors visible regardless
of the --verbose flag being passed or not to the test suite programs.
Add a test case calling ssl_set_hostname twice to test_suite_ssl.
When run in CMake build mode ASan, this catches the current leak,
but will hopefully be fine with the new version.
As the new PKCS v1.5 verification function opaquely compares an expected encoding to the given one, it cannot
distinguish multiple reasons of failure anymore and instead always returns MBEDTLS_ERR_RSA_VERIFY_FAILED. This
necessitates some modifications to the expected return values of some tests verifying signatures with bad padding.
This commit adds some tests to the RSA test suite verifying that RSA PKCS-v15 signatures with non-reduced length
encodings are refuted. Details are provided via comments in the test suite data file.
Add a test case calling ssl_set_hostname twice to test_suite_ssl.
When run in CMake build mode ASan, this catches the current leak,
but will hopefully be fine with the new version.
This commit adds a flag to the RSA import/export tests indicating whether it is
expected that a full RSA keypair can be set up from the provided parameters.
Further, the tests of `mbedtls_rsa_import` and `mbedtls_rsa_import_raw` are
expanded to perform key checks and an example encryption-decryption.
A bug in the dhm_check_range() function makes it pass even when the
parameters are not in the range. This commit adds tests for signalling
this problem as well as a couple of other negative tests.
This commit renames the test-only flag MBEDTLS_ENTROPY_HAVE_STRONG to ENTROPY_HAVE_STRONG to make it more transparent
that it's an internal flag, and also to content the testscript tests/scripts/check-names.pl which previously complained
about the macro occurring in a comment in `entropy.c` without being defined in a library file.
Previously, 2048-bit and 4096-bit RSA key files had their bitsize indicated in their filename, while the original
1024-bit keys hadn't. This commit unifies the naming scheme by always indicating the bitsize in the filename.
For uniformity, this commit adds tests for DER encoded, SHA1-2DES and SHA1-RC4-128-encrypted RSA keys; for SHA1-3DES encrypted keys, these were already present.
* mbedtls-2.6: (27 commits)
Update version number to 2.6.0
Fix language in Changelog for clarity
Improve documentation of PKCS1 decryption functions
Fix style and missing item in ChangeLog
Add credit to Changelog to fix for #666
Fix naked call to time() with platform call
Fix ChangeLog for duplication after merge
Rename time and index parameter to avoid name conflict.
Correct comment
Adapt ChangeLog
Reliably zeroize sensitive data in AES sample application
Reliably zeroize sensitive data in Crypt-and-Hash sample application
Fix potential integer overflow parsing DER CRT
Fix potential integer overflow parsing DER CRL
Move the git scripts to correct path
Update after @sbutcher-arm comments
Fix slash direction for linux path
Add note for the git_hoos README file
Pre push hook script
Check return code of mbedtls_mpi_fill_random
...
This commit adds test for the new library function mbedtls_rsa_check_params for
checking a set of RSA core parameters. There are some toy example tests with
small numbers that can be verified by hand, as well as tests with real world
numbers. Complete, partial and corrupted data are tested, as well the check for
primality exactly if a PRNG is provided.
This commit adds tests for the new library function mbedtls_rsa_export_raw.
Each test case performs the following steps:
- Parse and convert a set of hex-string decoded core RSA parameters into big
endian byte arrays.
- Use these to initialize an RSA context
- Export core RSA parameters as byte arrays again afterwards
- Compare byte strings.
Each test split is performed twice, once with successive and once with
simultaneous exporting.
This commit adds tests for the new library function mbedtls_rsa_export. Each
test case performs the following steps:
- Parse and convert a set of hex-string decoded core RSA parameters into MPI's.
- Use these to initialize an RSA context
- Export core RSA parameters as MPI's again afterwards
- Compare initial MPI's to exported ones.
In the private key case, all core parameters are exported and sanity-checked,
regardless of whether they were also used during setup.
Each test split is performed twice, once with successive and once with
simultaneous exporting.
This commit adds numerous tests for the new library functions mbedtls_rsa_import
and mbedtls_rsa_import_raw in conjunction with mbedtls_rsa_complete for
importing and completing core sets of core RSA parameters (N,P,Q,D,E) into an
RSA context, with the importing accepting either MPI's or raw big endian
buffers.
Each test is determined by the following parameters:
1) Set of parameters provided
We're testing full sets (N,P,Q,D,E), partial sets (N,-,-,D,E) and (N,P,Q,-,E)
that are sufficient to generate missing parameters, and the partial and
insufficient set (N, -, Q, -, E).
2) Simultaenous or successive importing
The functions rsa_import and rsa_import_raw accept importing parameters at
once or one after another. We test both.
3) Sanity of parameters
This commit adds test for the new library function mbedtls_rsa_deduce_moduli for
deducing the prime factors (P,Q) of an RSA modulus N from knowledge of a
pair (D,E) of public and private exponent:
- Two toy examples that can be checked by hand, one fine and with bad parameters.
- Two real world examples, one fine and one with bad parameters.
This commit adds tests for the new library function mbedtls_rsa_deduce_private
for deducing the private RSA exponent D from the public exponent E and the
factorization (P,Q) of the RSA modulus:
- Two toy examples with small numbers that can be checked by hand, one
working fine and another failing due to bad parameters.
- Two real world examples, one fine and one with bad parameters.
Our current behaviour is a bit inconsistent here:
- when the bad signature is made by a trusted CA, we stop here and don't
include the trusted CA in the chain (don't call vrfy on it)
- otherwise, we just add NOT_TRUSTED to the flags but keep building the chain
and call vrfy on the upper certs
This ensures that the callback can actually clear that flag, and that it is
seen by the callback at the right level. This flag is not set at the same
place than others, and this difference will get bigger in the upcoming
refactor, so let's ensure we don't break anything here.
When a trusted CA is rolling its root keys, it could happen that for some
users the list of trusted roots contains two versions of the same CA with the
same name but different keys. Currently this is supported but wasn't tested.
Note: the intermediate file test-ca-alt.csr is commited on purpose, as not
commiting intermediate files causes make to regenerate files that we don't
want it to touch.
As we accept EE certs that are explicitly trusted (in the list of trusted
roots) and usually look for parent by subject, and in the future we might want
to avoid checking the self-signature on trusted certs, there could a risk that we
incorrectly accept a cert that looks like a trusted root except it doesn't
have the same key. This test ensures this will never happen.
The tests cover chains of length 0, 1 and 2, with one error, located at any of
the available levels in the chain. This exercises all three call sites of
f_vrfy (two in verify_top, one in verify_child). Chains of greater length
would not cover any new code path or behaviour that I can see.
So far there was no test ensuring that the flags passed to the vrfy callback
are correct (ie the flags for the current certificate, not including those of
the parent).
Actual tests case making use of that test function will be added in the next
commit.
We have code to skip them but didn't have explicit tests ensuring they are
(the corresponding branch was never taken).
While at it, remove extra copy of the chain in server10*.crt, which was
duplicated for no reason.
This shows inconsistencies in how flags are handled when callback fails:
- sometimes the flags set by the callback are transmitted, sometimes not
- when the cert if not trusted, sometimes BADCERT_NOT_TRUSTED is set,
sometimes not
This adds coverage for 9 lines and 9 branches. Now all lines related to
callback failure are covered.
Now all checks related to profile are covered in:
- verify_with_profile()
- verify_child()
- verify_top()
(that's 10 lines that were previously not covered)
Leaving aside profile enforcement in CRLs for now, as the focus is on
preparing to refactor cert verification.
Previously flags was left to whatever value it had before. It's cleaner to
make sure it has a definite value, and all bits set looks like the safest way
for when it went very wrong.
The X509 test suite assumes that MBEDTLS_X509_MAX_INTERMEDIATE_CA is below the
hardcoded threshold 20 used in the long certificate chain generating script
tests/data_files/dir-max/long.sh. This commit adds a compile-time check for
that.
The RSA key generation test needs strong entropy to succeed. This commit captures the presence of a strong entropy
source in a preprocessor flag and only runs the key generation test if that flag is set.
The function `mbedtls_rsa_gen_key` from `test_suite_rsa.function` initialized a stack allocated RSA context only after
seeding the CTR DRBG. If the latter operation failed, the cleanup code tried to free the uninitialized RSA context,
potentially resulting in a segmentation fault. Fixes one aspect of #1023.
If we didn't walk the whole chain, then there may be any kind of errors in the
part of the chain we didn't check, so setting all flags looks like the safe
thing to do.
Inspired by test code provided by Nicholas Wilson in PR #351.
The test will fail if someone sets MAX_INTERMEDIATE_CA to a value larger than
18 (default is 8), which is hopefully unlikely and can easily be fixed by
running long.sh again with a larger value if it ever happens.
Current behaviour is suboptimal as flags are not set, but currently the goal
is only to document/test existing behaviour.
By default, keep allowing SHA-1 in key exchange signatures. Disabling
it causes compatibility issues, especially with clients that use
TLS1.2 but don't send the signature_algorithms extension.
SHA-1 is forbidden in certificates by default, since it's vulnerable
to offline collision-based attacks.
There is now one test case to validate that SHA-1 is rejected in
certificates by default, and one test case to validate that SHA-1 is
supported if MBEDTLS_TLS_DEFAULT_ALLOW_SHA1 is #defined.
SHA-1 is now disabled by default in the X.509 layer. Explicitly enable
it in our tests for now. Updating all the test data to SHA-256 should
be done over time.
The ECJPAKE test suite uses a size zero array for the empty password
used in the tests, which is not valid C. This commit fixes this.
This originally showed up as a compilation failure on Visual Studio
2015, documented in IOTSSL-1242, but can also be observed with GCC
when using the -Wpedantic compilation option.
The test case was generated by modifying our signature code so that it
produces a 7-byte long padding (which also means garbage at the end, so it is
essential in to check that the error that is detected first is indeed the
padding rather than the final length check).
The modular inversion function hangs when provided with the modulus 1. This commit refuses this modulus with a BAD_INPUT error code. It also adds a test for this case.
Fix a buffer overflow when writting a string representation of an MPI
number to a buffer in hexadecimal. The problem occurs because hex
digits are written in pairs and this is not accounted for in the
calculation of the required buffer size when the number of digits is
odd.
The first three test cases from test_suites_pkparse.data failed because
the key file they read requires DES to be read. However, MBEDTLS_DES_C
was missing from the dependency list.
This curve has special arithmetic on 64 bit platforms and an untested
path lead to trying to free a buffer on the stack.
For the sake of completeness, a test case for a point with non-affine
coordinates has been added as well.
Fixes a regression introduced by an earlier commit that modified
x509_crt_verify_top() to ensure that valid certificates that are after past or
future valid in the chain are processed. However the change introduced a change
in behaviour that caused the verification flags MBEDTLS_X509_BADCERT_EXPIRED and
MBEDTLS_BADCERT_FUTURE to always be set whenever there is a failure in the
verification regardless of the cause.
The fix maintains both behaviours:
* Ensure that valid certificates after future and past are verified
* Ensure that the correct verification flags are set.
Modifies the function mbedtls_x509_crl_parse() to ensure that a CRL in PEM
format with trailing characters after the footer does not result in the
execution of an infinite loop.
Fix potential integer overflows in the following functions:
* mbedtls_md2_update() to be bypassed and cause
* mbedtls_cipher_update()
* mbedtls_ctr_drbg_reseed()
This overflows would mainly be exploitable in 32-bit systems and could
cause buffer bound checks to be bypassed.
The tests load certificate chains from files. The CA chains contain a
past or future certificate and an invalid certificate. The test then
checks that the flags set are MBEDTLS_X509_BADCERT_EXPIRED or
MBEDTLS_X509_BADCERT_FUTURE.
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
