| Age | Commit message (Collapse) | Author |
|---|
|
A context allocated via crypto_mac_alloc_ctx() has to be freed using
crypto_mac_free_ctx(). While the default implementation just ends up
calling free(), other implementations may not.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reported-by: Summer Qin <summer.qin@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
|
|
To ease integration with other crypto libraries change the mac context
interface in crypto.h to manage the memory used for the mac context.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
|
|
The text 'All rights reserved' is useless [1]. The Free Software
Foundation's REUSE Initiative best practices document [2] does not
contain these words. Therefore, we can safely remove the text from the
files that are owned by Linaro.
Generated by:
spdxify.py --linaro-only --strip-arr optee_os/
Link: [1] https://en.wikipedia.org/wiki/All_rights_reserved
Link: [2] https://reuse.software/practices/
Link: [3] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>
|
|
Now that we have added SPDX identifiers, we can safely remove the
verbose license text from the files that are owned by Linaro.
Generated by [1]:
spdxify.py --linaro-only --strip-license-text optee_os/
Link: [1] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>
|
|
Adds one SPDX-License-Identifier line [1] to each source files that
contains license text.
Generated by [2]:
spdxify.py --add-spdx optee_os/
The scancode tool [3] was used to double check the license matching
code in the Python script. All the licenses detected by scancode are
either detected by spdxify.py, or have no SPDX identifier, or are false
matches.
Link: [1] https://spdx.org/licenses/
Link: [2] https://github.com/jforissier/misc/blob/f7b56c8/spdxify.py
Link: [3] https://github.com/nexB/scancode-toolkit
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Joakim Bech <joakim.bech@linaro.org>
|
|
Renames core/include/tee/tee_cryp_provider.h to
core/include/crypto/crypto.h
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
|
|
Adds mac_cipher_get_ctx_size(), mac_cipher_init(), mac_cipher_update()
and mac_cipher_final() replacing struct mac_ops in crypto_ops.
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
|
|
Optimize size of unpaged data by making crypto_ops const.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
|
|
HKDF (http://tools.ietf.org/html/rfc5869) is a key derivation algorithm.
As per the RFC:
A key derivation function (KDF) is a basic and essential component of
cryptographic systems. Its goal is to take some source of initial
keying material and derive from it one or more cryptographically
strong secret keys.
[...]
HKDF follows the "extract-then-expand" paradigm, where the KDF
logically consists of two modules.
[...]
The goal of the "extract" stage is to "concentrate" the possibly
dispersed entropy of the input keying material into a short, but
cryptographically strong, pseudorandom key.
[...]
The second stage "expands" the pseudorandom key to the desired
length; the number and lengths of the output keys depend on the
specific cryptographic algorithms for which the keys are needed.
Since HKDF is not covered by the GlobalPlatform Internal API specification
v1.0/v1.1, this commit introduces extensions to the specification.
More specifically: it defines new algorithms, a new object type and new
object attributes. This implementation supports all the usual hash
functions (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) and may
produce output keys of length up to 4096 bits (currently limited only by
the maximum size allowed for an object of type TEE_TYPE_GENERIC_SECRET).
Aside from minor updates to object manipulation functions to support
the new data, the function TEE_DeriveKey() is mostly impacted.
The file documentation/extensions/crypto_hkdf.md contains the modifications
to the GP Internal API v1.0 spec in order to support HKDF.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Xiaoqiang Du <xiaoqiang.du@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
|
