| 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.
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
OTP-13207
* sverk/crypto/aes-ecb-192-bit:
crypto: Support 192-bit keys for AES ECB
|
|
|
|
and deprecate aes_cbc128 and aes_cbc256 in favor of aes_cbc.
This commit is pr 832 squashed, rebased and made work on master
https://github.com/erlang/otp/pull/832/commits
|
|
The OSE port is no longer supported and this commit removed it
and any changes related to it. The things that were general
improvements have been left in the code.
|
|
|
|
To not fail on openssl built with #define OPENSSL_NO_EC2M
(Why does the test not verify all supported curve types?)
|
|
|
|
Despite the confusion caused by the name, aes_cfb_8_crypt and
aes_cfb_128_crypt can use key lengths of 128, 192, or 256. The integer
in the function name refers to the block size for CFB mode. Change
the aes_cfb_8_crypt and aes_cfb_128_crypt functions to accept and use
keys of length 128, 192, or 256. Also augment the existing testing for
these functions using the NIST test vectors for the additional key
lengths to ensure the changes function properly.
|
|
* andreaTP/added-aes-ecb-to-crypto/OTP-12403:
aligned implementation following last specs
finally fixed docs
fixed incorrect tag
proposal of documentation
fixes and tests
add aes ecb to crypto library
|
|
|
|
|
|
enhance generate_key to calculate ECC public keys from private keys
|
