| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
SRP didn't work with smaller primes as user secret was improperly
computed.
Formula is: (B - (k * g^x)) ^ (a + (u * x)) % N
Previously, the code computed a + (u * x) % N instead of a + (u * x).
a typically is a 256 bits random number (RFC 5054 says it should be at
least 256 bits), u and x are SHA1 signatures (160 bits). So a + (u * x)
can differ from a + (u * x) % N for N primes smaller than 320 bits.
|
