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

Source (jump to first uncovered line)
/*
 * 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;
}

Coverage Report

Created: 2025-07-11 06:34