diff options
author | Vadim Bendebury <vbendeb@chromium.org> | 2017-01-22 21:25:42 -0800 |
---|---|---|
committer | chrome-bot <chrome-bot@chromium.org> | 2017-01-25 22:12:28 -0800 |
commit | 7d2e4fbf5ba0c27f5d84bfa321bd857dbd7c33ff (patch) | |
tree | 6a8626fd1f271cf2bfaffc4d9e81a20ad20254e5 /include/crypto_api.h | |
parent | 09fca7bddbc4785c5f0d5f4590cdf9d09b3d5471 (diff) | |
download | chrome-ec-7d2e4fbf5ba0c27f5d84bfa321bd857dbd7c33ff.tar.gz |
g: common: introduce generic crypto API
On boards based on the g chip cryptographic functions come from
hardware, they should be implemented in chip/g as opposed to a
particular board.
The common modules (like nvmem) should be using some generic API,
which hopefully will be implemented by other chips, or could be
replaced by a purely software implementation where crypto hardware
support is not available.
Crypto API definition is being added in include/ and the g chip
implementation (a wrapper around dcrypto functions) is being added in
chip/g.
test/nvmem_vars.h needed to be edited to avoid conflict with
<string.h>.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall -j still passes. Booting reef with the new image
works fine too.
Change-Id: Ifef281215f89239966882ecbe3e90c8351b9b91a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431313
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Diffstat (limited to 'include/crypto_api.h')
-rw-r--r-- | include/crypto_api.h | 55 |
1 files changed, 55 insertions, 0 deletions
diff --git a/include/crypto_api.h b/include/crypto_api.h new file mode 100644 index 0000000000..2628e2bd7b --- /dev/null +++ b/include/crypto_api.h @@ -0,0 +1,55 @@ +/* + * Copyright 2017 The Chromium OS Authors. All rights reserved. + * Use of this source code is governed by a BSD-style license that can be + * found in the LICENSE file. + */ + +#ifndef __INCLUDE_CRYPTO_API_H +#define __INCLUDE_CRYPTO_API_H + +#include "util.h" + +/** + * Calculate hash of an arbitrary data + * + * Up to SHA_DIGEST_SIZE byte hash can be generated, if hash_len is + * longer - it is padded with zeros. + * + * @param p_buf: pointer to beginning of data + * @param num_bytes: length of data in bytes + * @param p_hash: pointer to where computed hash will be stored + * @param hash_len: length in bytes to use from sha computation. If this + * value exceeds SHA1 size (20 bytes), the rest of the + * hash is filled up with zeros. + */ +void app_compute_hash(uint8_t *p_buf, size_t num_bytes, + uint8_t *p_hash, size_t hash_len); + +#define CIPHER_SALT_SIZE 16 + +/* + * Encrypt/decrypt a flat blob. + * + * Encrypt or decrypt the input buffer, and write the correspondingly + * ciphered output to out. The number of bytes produced is equal to + * the number of input bytes. + * + * This API is expected to be applied to a single contiguous region. WARNING: + * Presently calling this function more than once with "in" pointing to + * logically different buffers will result in using the same IV value + * internally and as such reduce encryption efficiency. + * + * @param salt pointer to a unique value to be associated with this blob, + * used for derivation of the proper IV, the size of this value + * is as defined by CIPHER_SALT_SIZE above. + * WARNING: a given salt/"in" pair must be unique (it is an ERROR + * to use a given salt with more than one unique buffer). For an + * example, a good salt would be a digest of the plaintext input. + * @param out Destination pointer where to write plaintext / ciphertext. + * @param in Source pointer where to read ciphertext / plaintext. + * @param len Number of bytes to read from in / write to out. + * @return non-zero on success, and zero otherwise. + */ +int app_cipher(const void *salt, void *out, const void *in, size_t size); + +#endif /* __INCLUDE_CRYPTO_API_H */ |