| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Add support to plug in alternative implementations for
some or all of the cryptographic operations supported by
the OpenSSL Engine API.
When configured appropriately, OpenSSL calls the engine's
implementation of these operations instead of its own.
|
|
ECDSA and DSA (DSS) public/private encryption/decryption does not work
|
|
Testcases for ECDSA and DSA encrypt/decrypt and some other adaptions
|
|
|
|
In OpenSSL version >= 1.0.1 the hash algos sha, sha224, sha256, sha384 and sha512 are supported.
In 1.0.0 sha, sha224 and sha256 are supported
In 0.9.8 sha is supported
|
|
|
|
|
|
|
|
|
|
crypto: replace AES test vectors with validation data from NIST CAVP program
OTP-14436
|
|
|
|
It turns out that the excessive memory usage is cause by the
test framework printing all the test vectors into the log output.
A similar proplem was already diagnosed for long_msg/0. The root
cause was not mentioned in the SUITE, but the same fix applies
to the CAPV test vector data.
Switch all CAPV data to lazy evaluation and have the test itself
read the data.
|
|
|
|
|
|
NIST's Cryptographic Algorithm Validation Program provides
validation testing of FIPS-approved and NIST-recommended
cryptographic algorithms.
Instead of hard coding a limited set of test vectors, use
their comprehensive validation set to test AES cipher modes.
|
|
Fix for problem introduced with OTP-14140
|
|
|
|
|
|
for usage in rand
|
|
|
|
If the underlying library is in FIPS mode, it'll refuse to generate
keys shorter than 2048 bits.
|
|
Support RSA key generation using generate_key(rsa, {bits, e}). This depends
on the currently-experimental "dirty scheduler" support because key
generation is a potentially lengthy process.
|
|
This commit reactivates chacha20_poly1305 and fixes the imprementation
for the released OpenSSL 1.1.0 or later.
|
|
|
|
Conflicts:
lib/crypto/c_src/crypto.c
lib/ssl/src/ssl_cipher.erl
|
|
|
|
* RoadRunnr/crypto/no-rc4/PR-1169/OTP-13896:
disable RC4 in SSL when crypto doesn't support it
Fix compilation when OpenSSL doesn't support RC4
Conflicts:
lib/crypto/c_src/crypto.c
|
|
In one of the test cases, the IV is 8 bytes. In FIPS mode, the minimum
allowed IV length is 12 bytes, so let's skip that test case.
|
|
block_crypt_nif does some sanity tests on its arguments before trying
to initialise the cipher. This made some of the tests in crypto_SUITE
fail, since they were expecting notsup, not badarg. Fix this by
passing the same test data as for the positive tests.
|
|
Even if Erlang/OTP has been built with --enable-fips, it's possible
that the OpenSSL library we're linked to doesn't support FIPS mode.
In that case, it will fail to enable it at run time. Let's handle
that in crypto_SUITE, by skipping the tests instead of failing.
|
|
Every algorithm is now tested in both FIPS and non-FIPS modes (when
crypto is compiled with FIPS support). In FIPS mode non-FIPS
algorithms are disabled and the tests verify that they crash with
notsup error as expected.
In FIPS mode RSA and EC algorithms don't work if the key sizes are
below a minimum required value - which happened to be the case with
most keys used in the tests. These tests were changed to use longer
keys (even in non-FIPS mode for simplicity).
Conflicts:
lib/crypto/test/crypto_SUITE.erl
|
|
When OpenSSL has been configured with the "no-rc4" option, the header
file rc4.h doesn't exist, and neither does the rc4 functions.
Let's handle those by checking whether OPENSSL_NO_RC4 is defined.
|
|
When OpenSSL has been configured with the "no-rc2" option, the header
file rc2.h doesn't exist, and neither does the function EVP_rc2_cbc.
Let's handle those by checking whether OPENSSL_NO_RC2 is defined.
Also update pbe_SUITE, which uses RC2-CBC in one of the tests.
|
|
|
|
|
|
Also correct algo_cipher[] size since it was one to small.
|
|
|
|
The ERL-82 issue requests a way to calculate a CMAC in Erlang. The
AES128 CMAC is standartized in RFC 4493 and used e.g. for message
authentication in the LoRaWAN networks.
The CMAC is implemented by OpenSSL since v1.0.1, but as @IngelaAndin
stated in response to the ERL-82, the current crypto implementation
does not include functions that call those OpenSSL cryptolib functions.
This commit introduces a new function `crypto:cmac` that calls
the corresponding OpenSSL functions and calculates the CMAC.
Only the cmac_nif is implemented. The incremental functions (init,
update, final) are not provided because the current OpenSSL does
not allow custom memory allocators like `enif_alloc_resource`.
The Erlang user guide states that at least OpenSSL 0.9.8 is required,
so I added few #ifdefs so the code is compatible with all versions.
However, the OpenSSL pages say that the pre-1.0.1 versions (0.9.8 and
1.0.0) are no longer maintained. Even the 1.0.1 will be retired by
Dec 2016. Hence I believe that adding a 1.0.1-only function like CMAC
should be OK.
|
|
OpenSSL has deprecated the function RAND_pseudo_bytes used by
crypto:rand_bytes/1, so this function is now deprecated in OTP too.
rand_bytes/3 also used this function, but was not documented
so we can remove it right away.
This commit also removes the fallback in generate_key to use
rand_bytes/1 if strong_rand_bytes/1 throws low entropy.
This is a potential incompatibility but we think it is desirable
as crypto should provide cryptographically secure functions.
|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
|
|
|
|
|
|
Since no test suites includede test_server.hrl, there is no need
to have test_server in the include path or code path.
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
|
|
Avoid hardcoding EC curve names in tests where it basically doesn't
matter which curve is used. Take one of the supported curbes instead.
Also, when testing ECDH key generation, skip unsupported curves.
These changes are to simplify dealing with exotic libcrypto builds
that don't support certain curves (for example RHEL disallows < 256
bit curves). The crypto application is only able to detect the
supported curves on a very coarse level (ECC support in general and
GF2m curves), so it may be necessary to edit the list of curves in the
crypto_ec_curves modules. But that should be the only necessary
modification to make the crypto tests pass.
|
