libwebsockets/lib/tls/lws-gencrypto-common.c

/*
 * libwebsockets - small server side websockets and web server implementation
 *
 * Copyright (C) 2010 - 2019 Andy Green <andy@warmcat.com>
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to
 * deal in the Software without restriction, including without limitation the
 * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
 * sell copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 * IN THE SOFTWARE.
 */

#include "private-lib-core.h"

/*
 * These came from RFC7518 (JSON Web Algorithms) Section 3
 *
 * Cryptographic Algorithms for Digital Signatures and MACs
 */

static const struct lws_jose_jwe_alg lws_gencrypto_jws_alg_map[] = {

	/*
	 * JWSs MAY also be created that do not provide integrity protection.
	 * Such a JWS is called an Unsecured JWS.  An Unsecured JWS uses the
	 * "alg" value "none" and is formatted identically to other JWSs, but
	 * MUST use the empty octet sequence as its JWS Signature value.
	 * Recipients MUST verify that the JWS Signature value is the empty
	 * octet sequence.
	 *
	 * Implementations that support Unsecured JWSs MUST NOT accept such
	 * objects as valid unless the application specifies that it is
	 * acceptable for a specific object to not be integrity protected.
	 * Implementations MUST NOT accept Unsecured JWSs by default.  In order
	 * to mitigate downgrade attacks, applications MUST NOT signal
	 * acceptance of Unsecured JWSs at a global level, and SHOULD signal
	 * acceptance on a per-object basis.  See Section 8.5 for security
	 * considerations associated with using this algorithm.
	 */
	{	/* optional */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_NONE,
		"none", NULL, 0, 0, 0
	},

	/*
	 * HMAC with SHA-2 Functions
	 *
	 * The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC
	 * value per RFC 2104, using SHA-256 as the hash algorithm "H", using
	 * the received JWS Signing Input as the "text" value, and using the
	 * shared key.  This computed HMAC value is then compared to the result
	 * of base64url decoding the received encoded JWS Signature value.  The
	 * comparison of the computed HMAC value to the JWS Signature value MUST
	 * be done in a constant-time manner to thwart timing attacks.
	 *
	 * Alternatively, the computed HMAC value can be base64url encoded and
	 * compared to the received encoded JWS Signature value (also in a
	 * constant-time manner), as this comparison produces the same result as
	 * comparing the unencoded values.  In either case, if the values match,
	 * the HMAC has been validated.
	 */

	{	/* required: HMAC using SHA-256 */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA256,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_NONE,
		"HS256", NULL, 0, 0, 0
	},
	{	/* optional: HMAC using SHA-384 */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA384,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_NONE,
		"HS384", NULL, 0, 0, 0
	},
	{	/* optional: HMAC using SHA-512 */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA512,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_NONE,
		"HS512", NULL, 0, 0, 0
	},

	/*
	 * Digital Signature with RSASSA-PKCS1-v1_5
	 *
	 * This section defines the use of the RSASSA-PKCS1-v1_5 digital
	 * signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447]
	 * (commonly known as PKCS #1), using SHA-2 [SHS] hash functions.
	 *
	 * A key of size 2048 bits or larger MUST be used with these algorithms.
	 *
	 * The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as
	 * follows: generate a digital signature of the JWS Signing Input using
	 * RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired
	 * private key.  This is the JWS Signature value.
	 *
	 * The RSASSA-PKCS1-v1_5 SHA-256 digital signature for a JWS is
	 * validated as follows: submit the JWS Signing Input, the JWS
	 * Signature, and the public key corresponding to the private key used
	 * by the signer to the RSASSA-PKCS1-v1_5-VERIFY algorithm using SHA-256
	 * as the hash function.
	 */

	{	/* recommended: RSASSA-PKCS1-v1_5 using SHA-256 */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
		LWS_JOSE_ENCTYPE_NONE,
		"RS256", NULL, 2048, 4096, 0
	},
	{	/* optional: RSASSA-PKCS1-v1_5 using SHA-384 */
		LWS_GENHASH_TYPE_SHA384,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
		LWS_JOSE_ENCTYPE_NONE,
		"RS384", NULL, 2048, 4096, 0
	},
	{	/* optional: RSASSA-PKCS1-v1_5 using SHA-512 */
		LWS_GENHASH_TYPE_SHA512,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
		LWS_JOSE_ENCTYPE_NONE,
		"RS512", NULL, 2048, 4096, 0
	},

	/*
	 * Digital Signature with ECDSA
	 *
	 * The ECDSA P-256 SHA-256 digital signature is generated as follows:
	 *
	 * 1.  Generate a digital signature of the JWS Signing Input using ECDSA
	 *     P-256 SHA-256 with the desired private key.  The output will be
	 *     the pair (R, S), where R and S are 256-bit unsigned integers.
	 * 2.  Turn R and S into octet sequences in big-endian order, with each
	 *     array being be 32 octets long.  The octet sequence
	 *     representations MUST NOT be shortened to omit any leading zero
	 *     octets contained in the values.
	 *
	 * 3.  Concatenate the two octet sequences in the order R and then S.
	 *     (Note that many ECDSA implementations will directly produce this
	 *     concatenation as their output.)
	 *
	 * 4.  The resulting 64-octet sequence is the JWS Signature value.
	 *
	 * The ECDSA P-256 SHA-256 digital signature for a JWS is validated as
	 * follows:
	 *
	 * 1.  The JWS Signature value MUST be a 64-octet sequence.  If it is
	 *     not a 64-octet sequence, the validation has failed.
	 *
	 * 2.  Split the 64-octet sequence into two 32-octet sequences.  The
	 *     first octet sequence represents R and the second S.  The values R
	 *     and S are represented as octet sequences using the Integer-to-
	 *     OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1]
	 *     (in big-endian octet order).
	 * 3.  Submit the JWS Signing Input, R, S, and the public key (x, y) to
	 *     the ECDSA P-256 SHA-256 validator.
	 */

	{	/* Recommended+: ECDSA using P-256 and SHA-256 */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDSA,
		LWS_JOSE_ENCTYPE_NONE,
		"ES256", "P-256", 256, 256, 0
	},
	{	/* optional: ECDSA using P-384 and SHA-384 */
		LWS_GENHASH_TYPE_SHA384,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDSA,
		LWS_JOSE_ENCTYPE_NONE,
		"ES384", "P-384", 384, 384, 0
	},
	{	/* optional: ECDSA using P-521 and SHA-512 */
		LWS_GENHASH_TYPE_SHA512,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDSA,
		LWS_JOSE_ENCTYPE_NONE,
		"ES512", "P-521", 521, 521, 0
	},
#if 0
	Not yet supported

	/*
	 * Digital Signature with RSASSA-PSS
	 *
	 * A key of size 2048 bits or larger MUST be used with this algorithm.
	 *
	 * The RSASSA-PSS SHA-256 digital signature is generated as follows:
	 * generate a digital signature of the JWS Signing Input using RSASSA-
	 * PSS-SIGN, the SHA-256 hash function, and the MGF1 mask generation
	 * function with SHA-256 with the desired private key.  This is the JWS
	 * Signature value.
	 *
	 * The RSASSA-PSS SHA-256 digital signature for a JWS is validated as
	 * follows: submit the JWS Signing Input, the JWS Signature, and the
	 * public key corresponding to the private key used by the signer to the
	 * RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and
	 * using MGF1 as the mask generation function with SHA-256.
	 *
	 */
	{	/* optional: RSASSA-PSS using SHA-256 and MGF1 with SHA-256 */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
		LWS_JOSE_ENCTYPE_NONE,
		"PS256", NULL, 2048, 4096, 0
	},
	{	/* optional: RSASSA-PSS using SHA-384 and MGF1 with SHA-384 */
		LWS_GENHASH_TYPE_SHA384,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
		LWS_JOSE_ENCTYPE_NONE,
		"PS384", NULL, 2048, 4096, 0
	},
	{	/* optional: RSASSA-PSS using SHA-512 and MGF1 with SHA-512*/
		LWS_GENHASH_TYPE_SHA512,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
		LWS_JOSE_ENCTYPE_NONE,
		"PS512", NULL, 2048, 4096, 0
	},
#endif
	/* list terminator */
	{ 0, 0, 0, 0, NULL, NULL, 0, 0, 0}
};

/*
 * These came from RFC7518 (JSON Web Algorithms) Section 4
 *
 * Cryptographic Algorithms for Key Management
 *
 * JWE uses cryptographic algorithms to encrypt or determine the Content
 * Encryption Key (CEK).
 */

static const struct lws_jose_jwe_alg lws_gencrypto_jwe_alg_map[] = {

	/*
	 * This section defines the specifics of encrypting a JWE CEK with
	 * RSAES-PKCS1-v1_5 [RFC3447].  The "alg" (algorithm) Header Parameter
	 * value "RSA1_5" is used for this algorithm.
	 *
	 * A key of size 2048 bits or larger MUST be used with this algorithm.
	 */

	{	/* recommended-: RSAES-PKCS1-v1_5 */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
		LWS_JOSE_ENCTYPE_NONE,
		"RSA1_5", NULL, 2048, 4096, 0
	},
	{	/* recommended+: RSAES OAEP using default parameters */
		LWS_GENHASH_TYPE_SHA1,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_OAEP,
		LWS_JOSE_ENCTYPE_NONE,
		"RSA-OAEP", NULL, 2048, 4096, 0
	},
	{	/* recommended+: RSAES OAEP using SHA-256 and MGF1 SHA-256 */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_RSASSA_PKCS1_OAEP,
		LWS_JOSE_ENCTYPE_NONE,
		"RSA-OAEP-256", NULL, 2048, 4096, 0
	},

	/*
	 * Key Wrapping with AES Key Wrap
	 *
	 * This section defines the specifics of encrypting a JWE CEK with the
	 * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
	 * the default initial value specified in Section 2.2.3.1 of that
	 * document.
	 *
	 *
	 */
	{	/* recommended: AES Key Wrap with AES Key Wrap with defaults
				using 128-bit key  */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A128KW", NULL, 128, 128, 64
	},

	{	/* optional: AES Key Wrap with AES Key Wrap with defaults
				using 192-bit key */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A192KW", NULL, 192, 192, 64
	},

	{	/* recommended: AES Key Wrap with AES Key Wrap with defaults
				using 256-bit key */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A256KW", NULL, 256, 256, 64
	},

	/*
	 * This section defines the specifics of directly performing symmetric
	 * key encryption without performing a key wrapping step.  In this case,
	 * the shared symmetric key is used directly as the Content Encryption
	 * Key (CEK) value for the "enc" algorithm.  An empty octet sequence is
	 * used as the JWE Encrypted Key value.  The "alg" (algorithm) Header
	 * Parameter value "dir" is used in this case.
	 */
	{	/* recommended */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_NONE,
		"dir", NULL, 0, 0, 0
	},

	/*
	 * Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static
	 * (ECDH-ES)
	 *
	 * This section defines the specifics of key agreement with Elliptic
	 * Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with
	 * the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A].  The
	 * key agreement result can be used in one of two ways:
	 *
	 * 1.  directly as the Content Encryption Key (CEK) for the "enc"
	 *     algorithm, in the Direct Key Agreement mode, or
	 *
	 * 2.  as a symmetric key used to wrap the CEK with the "A128KW",
	 *     "A192KW", or "A256KW" algorithms, in the Key Agreement with Key
	 *     Wrapping mode.
	 *
	 * A new ephemeral public key value MUST be generated for each key
	 * agreement operation.
	 *
	 * In Direct Key Agreement mode, the output of the Concat KDF MUST be a
	 * key of the same length as that used by the "enc" algorithm.  In this
	 * case, the empty octet sequence is used as the JWE Encrypted Key
	 * value.  The "alg" (algorithm) Header Parameter value "ECDH-ES" is
	 * used in the Direct Key Agreement mode.
	 *
	 * In Key Agreement with Key Wrapping mode, the output of the Concat KDF
	 * MUST be a key of the length needed for the specified key wrapping
	 * algorithm.  In this case, the JWE Encrypted Key is the CEK wrapped
	 * with the agreed-upon key.
	 */

	{	/* recommended+: ECDH Ephemeral Static Key agreement Concat KDF */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDHES,
		LWS_JOSE_ENCTYPE_NONE,
		"ECDH-ES", NULL, 128, 128, 0
	},
	{	/* recommended: ECDH-ES + Concat KDF + wrapped by AES128KW */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDHES,
		LWS_JOSE_ENCTYPE_AES_ECB,
		"ECDH-ES+A128KW", NULL, 128, 128, 0
	},
	{	/* optional: ECDH-ES + Concat KDF + wrapped by AES192KW */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDHES,
		LWS_JOSE_ENCTYPE_AES_ECB,
		"ECDH-ES+A192KW", NULL, 192, 192, 0
	},
	{	/* recommended: ECDH-ES + Concat KDF + wrapped by AES256KW */
		LWS_GENHASH_TYPE_SHA256,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_ECDHES,
		LWS_JOSE_ENCTYPE_AES_ECB,
		"ECDH-ES+A256KW", NULL, 256, 256, 0
	},

	/*
	 * Key Encryption with AES GCM
	 *
	 *  This section defines the specifics of encrypting a JWE Content
	 *  Encryption Key (CEK) with Advanced Encryption Standard (AES) in
	 *  Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).
	 *
	 * Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with
	 * this algorithm.  The IV is represented in base64url-encoded form as
	 * the "iv" (initialization vector) Header Parameter value.
	 *
	 * The Additional Authenticated Data value used is the empty octet
	 * string.
	 *
	 * The requested size of the Authentication Tag output MUST be 128 bits,
	 * regardless of the key size.
	 *
	 * The JWE Encrypted Key value is the ciphertext output.
	 *
	 * The Authentication Tag output is represented in base64url-encoded
	 * form as the "tag" (authentication tag) Header Parameter value.
	 *
	 *
	 * "iv" (Initialization Vector) Header Parameter
	 *
	 * The "iv" (initialization vector) Header Parameter value is the
	 * base64url-encoded representation of the 96-bit IV value used for the
	 * key encryption operation.  This Header Parameter MUST be present and
	 * MUST be understood and processed by implementations when these
	 * algorithms are used.
	 *
	 * "tag" (Authentication Tag) Header Parameter
	 *
	 * The "tag" (authentication tag) Header Parameter value is the
	 * base64url-encoded representation of the 128-bit Authentication Tag
	 * value resulting from the key encryption operation.  This Header
	 * Parameter MUST be present and MUST be understood and processed by
	 * implementations when these algorithms are used.
	 */
	{	/* optional: Key wrapping with AES GCM using 128-bit key  */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A128GCMKW", NULL, 128, 128, 96
	},

	{	/* optional: Key wrapping with AES GCM using 192-bit key */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A192GCMKW", NULL, 192, 192, 96
	},

	{	/* optional: Key wrapping with AES GCM using 256-bit key */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_AES_ECB,
		LWS_JOSE_ENCTYPE_NONE,
		"A256GCMKW", NULL, 256, 256, 96
	},

	/* list terminator */
	{ 0, 0, 0, 0, NULL, NULL, 0, 0, 0 }
};

/*
 * The "enc" (encryption algorithm) Header Parameter identifies the
 * content encryption algorithm used to perform authenticated encryption
 * on the plaintext to produce the ciphertext and the Authentication
 * Tag.  This algorithm MUST be an AEAD algorithm with a specified key
 * length.  The encrypted content is not usable if the "enc" value does
 * not represent a supported algorithm.  "enc" values should either be
 * registered in the IANA "JSON Web Signature and Encryption Algorithms"
 * registry established by [JWA] or be a value that contains a
 * Collision-Resistant Name.  The "enc" value is a case-sensitive ASCII
 * string containing a StringOrURI value.  This Header Parameter MUST be
 * present and MUST be understood and processed by implementations.
 */

static const struct lws_jose_jwe_alg lws_gencrypto_jwe_enc_map[] = {
	/*
	 * AES_128_CBC_HMAC_SHA_256 / 512
	 *
	 * It uses the HMAC message authentication code [RFC2104] with the
	 * SHA-256 hash function [SHS] to provide message authentication, with
	 * the HMAC output truncated to 128 bits, corresponding to the
	 * HMAC-SHA-256-128 algorithm defined in [RFC4868].  For encryption, it
	 * uses AES in the CBC mode of operation as defined in Section 6.2 of
	 * [NIST.800-38A], with PKCS #7 padding and a 128-bit IV value.
	 *
	 * The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256
	 * are:
	 *
	 * The input key K is 32 octets long.
	 *       ENC_KEY_LEN is 16 octets.
	 *       MAC_KEY_LEN is 16 octets.
	 *       The SHA-256 hash algorithm is used for the HMAC.
	 *       The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
	 *       stripping off the final 16 octets.
	 */
	{	/* required */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA256,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_CBC,
		"A128CBC-HS256", NULL, 256, 256, 128
	},
	/*
	 * AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but
	 * with the following differences:
	 *
	 * The input key K is 48 octets long instead of 32.
	 * ENC_KEY_LEN is 24 octets instead of 16.
	 * MAC_KEY_LEN is 24 octets instead of 16.
	 * SHA-384 is used for the HMAC instead of SHA-256.
	 * The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of 16.
	 */
	{	/* required */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA384,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_CBC,
		"A192CBC-HS384", NULL, 384, 384, 192
	},
	/*
	 * AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but
	 * with the following differences:
	 *
	 * The input key K is 64 octets long instead of 32.
	 * ENC_KEY_LEN is 32 octets instead of 16.
	 * MAC_KEY_LEN is 32 octets instead of 16.
	 * SHA-512 is used for the HMAC instead of SHA-256.
	 * The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of 16.
	 */
	{	/* required */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_SHA512,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_CBC,
		"A256CBC-HS512", NULL, 512, 512, 256
	},

	/*
	 * The CEK is used as the encryption key.
	 *
	 * Use of an IV of size 96 bits is REQUIRED with this algorithm.
	 *
	 * The requested size of the Authentication Tag output MUST be 128 bits,
	 * regardless of the key size.
	 */
	{	/* recommended: AES GCM using 128-bit key  */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_GCM,
		"A128GCM", NULL, 128, 128, 96
	},
	{	/* optional: AES GCM using 192-bit key  */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_GCM,
		"A192GCM", NULL, 192, 192, 96
	},
	{	/* recommended: AES GCM using 256-bit key */
		LWS_GENHASH_TYPE_UNKNOWN,
		LWS_GENHMAC_TYPE_UNKNOWN,
		LWS_JOSE_ENCTYPE_NONE,
		LWS_JOSE_ENCTYPE_AES_GCM,
		"A256GCM", NULL, 256, 256, 96
	},
	{ 0, 0, 0, 0, NULL, NULL, 0, 0, 0 } /* sentinel */
};

int
lws_gencrypto_jws_alg_to_definition(const char *alg,
				    const struct lws_jose_jwe_alg **jose)
{
	const struct lws_jose_jwe_alg *a = lws_gencrypto_jws_alg_map;

	while (a->alg) {
		if (!strcmp(alg, a->alg)) {
			*jose = a;

			return 0;
		}
		a++;
	}

	return 1;
}

int
lws_gencrypto_jwe_alg_to_definition(const char *alg,
				    const struct lws_jose_jwe_alg **jose)
{
	const struct lws_jose_jwe_alg *a = lws_gencrypto_jwe_alg_map;

	while (a->alg) {
		if (!strcmp(alg, a->alg)) {
			*jose = a;

			return 0;
		}
		a++;
	}

	return 1;
}

int
lws_gencrypto_jwe_enc_to_definition(const char *enc,
				    const struct lws_jose_jwe_alg **jose)
{
	const struct lws_jose_jwe_alg *e = lws_gencrypto_jwe_enc_map;

	while (e->alg) {
		if (!strcmp(enc, e->alg)) {
			*jose = e;

			return 0;
		}
		e++;
	}

	return 1;
}

size_t
lws_genhash_size(enum lws_genhash_types type)
{
	switch(type) {
	case LWS_GENHASH_TYPE_UNKNOWN:
		return 0;
	case LWS_GENHASH_TYPE_MD5:
		return 16;
	case LWS_GENHASH_TYPE_SHA1:
		return 20;
	case LWS_GENHASH_TYPE_SHA256:
		return 32;
	case LWS_GENHASH_TYPE_SHA384:
		return 48;
	case LWS_GENHASH_TYPE_SHA512:
		return 64;
	}

	return 0;
}

size_t
lws_genhmac_size(enum lws_genhmac_types type)
{
	switch(type) {
	case LWS_GENHMAC_TYPE_UNKNOWN:
		return 0;
	case LWS_GENHMAC_TYPE_SHA256:
		return 32;
	case LWS_GENHMAC_TYPE_SHA384:
		return 48;
	case LWS_GENHMAC_TYPE_SHA512:
		return 64;
	}

	return 0;
}

int
lws_gencrypto_bits_to_bytes(int bits)
{
	if (bits & 7)
		return (bits / 8) + 1;

	return bits / 8;
}

int
lws_base64_size(int bytes)
{
	return ((bytes * 4) / 3) + 6;
}

void
lws_gencrypto_destroy_elements(struct lws_gencrypto_keyelem *el, int m)
{
	int n;

	for (n = 0; n < m; n++)
		if (el[n].buf)
			lws_free_set_NULL(el[n].buf);
}

size_t lws_gencrypto_padded_length(size_t pad_block_size, size_t len)
{
	return (len / pad_block_size + 1) * pad_block_size;
}