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.
|
|
Rand plugin for cached strong crypto bytes
OTP-13370
|
|
Testcases for ECDSA and DSA encrypt/decrypt and some other adaptions
|
|
|
|
|
|
|
|
|
|
Same comment as previous commit applies.
|
|
The function pkey_verify_nif handles pk signing with a general approach that is enabled by EVP api in OpenSSL 1.0.0
The rejected PR838 introduced that function and lots of other stuff so far neglected. It also made some different rsa padding methods possible (included).
Since the crypto code base has changed significantly, it was an overhelming work to try a git merge. Therefore this commit is a manual move of the source code from the PR into current maint.
This commit concentrates to use the new function compatible with the old functions. This includes some #if:s for different versions, compatibility code for 0.9.8.
Lacking: test cases, exporting the more general erlang api, documentation...
|
|
|
|
|
|
Implement Xoroshiro116+ as 'exrop' with fixes.
Deprecate all old algorithms but reincarnate 'exs1024' as 'exs1024s'
and 'exsplus' as 'exsp' with fixes.
Fixes:
* Avoid skew for uniform integers caused by using a simple 'rem'
operation for range confinement. Correctness requires retry
with new random value for an unfortunate first value.
* Implement a correct algorithm that collects enough random
bits for ranges larger than the generator's precision.
* Fix uniform density for floats by acquiring 53 bits
then multiplying with 2.0^(-53) which produces floats
on the form N * 2.0^(-53).
|
|
* g-andrade/strong-random-numbers/PR-1367/OTP-14317:
Clean up documentation and test cases
Attempt faster approach to strong random floats
Allow for crypto upgrades when using rand plugin
fixup! Support cryptographically strong rand plugin
fixup! Support cryptographically strong rand plugin
fixup! Support cryptographically strong rand plugin
fixup! Support cryptographically strong rand plugin
No longer expose strong_rand_(range|float)
Support cryptographically strong rand plugin
Restyle crypto strong numeric generators for usage in rand
Support generation of strong random numbers
|
|
This is a poor man's solution that allows to build and test the
system with all files compiled to native code simply by setting
the ERL_COMPILER_OPTS environment variable. Better solutions,
like automatically setting the no_native option whenever the
compiler sees an on_load attribute, obviously exist but require
more time to implement.
|
|
|
|
|
|
rand module should be used if not cryptographically strong is required.
If cryptographically strong is required, new cryptographically strong
functions should be added to crypto.
|
|
|
|
|
|
for usage in rand
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/crypto/c_src/crypto.c
lib/crypto/src/crypto.erl
|
|
|
|
|
|
Fix https://bugs.erlang.org/browse/ERL-336.
|
|
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.
|
|
Update compiler documentation and remove superfluous erlc flags.
|
|
|
|
Adapted from commit 675ee6860d2c273bcc6c6a0536634a107e2a3d9f.
|
|
FIPS mode support needs to be enabled at compile time, by configuring
Erlang/OTP with --enable-fips option. In FIPS mode the non-FIPS
algorithms are disabled and raise error notsup.
The supported protocols list is properly updated in FIPS mode to
advertise only the enabled protocols.
FIPS mode is off by default even if Erlang/OTP was built with FIPS
support. It needs to be turned on at runtime.
The official approach is to set the fips_mode application environment
parameter of the crypto application to true. This would turn FIPS mode
on when the NIF is loaded and would prevent loading the module on
error.
Another method is provided via the crypto:enable_fips_mode/1
function, but it is not recommended to be used in production, as it
won't prevent the use of the crypto module in case of an error, and
would risk OpenSSL crashing the emulator. It is very useful for test
suites however that need to check both validated and non-validated
functionality.
This commit is based on commit
00b3a04d17a653b4abddeebd6dd8a2c38df532d0.
|
|
Make all calls to erlang:error/2 specify the actual argument list of
the function. This ensures that the stacktrace contains the correct
arity of the function where the error occurred.
|
|
|
|
|
|
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.
|
|
|
|
This commit enables AES-GCM encryption/decryption to change its tag
length between 1 to 16 bytes.
|
|
|
|
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
|
|
Using the generic EVP_* API makes it possible to unify
algorithm-specific nif functions to a single generic
function. Effectively the same change that took place on the Erlang
API in R16B01 is now applied to the C code.
The old implementation using the low-level API is kept
for compiling against old OpenSSL,
as parts of the EVP API were introduced in OpenSSL 1.0.0.
There are various minor improvements as well:
- supported algorithms are now provided by the nif code (not a mix of
the C and Erlang code)
- remove unnecessary variables and macro definitions
Most of the changes in this commit comes from Dániel Szoboszlay
https://github.com/dszoboszlay/otp/commit/07f7056f955b324df4ace
which is part of his 'fips' branch.
Now also rebased on master branch.
|
|
|
|
|
|
by removing the spec. It's an internal function.
|
|
* 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
|
|
|
|
|
|
|