lib/tls/lws-gencrypto-common.c

   1 /*
   2  * libwebsockets - generic crypto hiding the backend - common parts
   3  *
   4  * Copyright (C) 2017 - 2018 Andy Green <andy@warmcat.com>
   5  *
   6  *  This library is free software; you can redistribute it and/or
   7  *  modify it under the terms of the GNU Lesser General Public
   8  *  License as published by the Free Software Foundation:
   9  *  version 2.1 of the License.
  10  *
  11  *  This library is distributed in the hope that it will be useful,
  12  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  13  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  14  *  Lesser General Public License for more details.
  15  *
  16  *  You should have received a copy of the GNU Lesser General Public
  17  *  License along with this library; if not, write to the Free Software
  18  *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
  19  *  MA  02110-1301  USA
  20  */
  21
  22 #include "private-lib-core.h"
  23
  24 /*
  25  * These came from RFC7518 (JSON Web Algorithms) Section 3
  26  *
  27  * Cryptographic Algorithms for Digital Signatures and MACs
  28  */
  29
  30 static const struct lws_jose_jwe_alg lws_gencrypto_jws_alg_map[] = {
  31
  32         /*
  33          * JWSs MAY also be created that do not provide integrity protection.
  34          * Such a JWS is called an Unsecured JWS.  An Unsecured JWS uses the
  35          * "alg" value "none" and is formatted identically to other JWSs, but
  36          * MUST use the empty octet sequence as its JWS Signature value.
  37          * Recipients MUST verify that the JWS Signature value is the empty
  38          * octet sequence.
  39          *
  40          * Implementations that support Unsecured JWSs MUST NOT accept such
  41          * objects as valid unless the application specifies that it is
  42          * acceptable for a specific object to not be integrity protected.
  43          * Implementations MUST NOT accept Unsecured JWSs by default.  In order
  44          * to mitigate downgrade attacks, applications MUST NOT signal
  45          * acceptance of Unsecured JWSs at a global level, and SHOULD signal
  46          * acceptance on a per-object basis.  See Section 8.5 for security
  47          * considerations associated with using this algorithm.
  48          */
  49         {       /* optional */
  50                 LWS_GENHASH_TYPE_UNKNOWN,
  51                 LWS_GENHMAC_TYPE_UNKNOWN,
  52                 LWS_JOSE_ENCTYPE_NONE,
  53                 LWS_JOSE_ENCTYPE_NONE,
  54                 "none", NULL, 0, 0, 0
  55         },
  56
  57         /*
  58          * HMAC with SHA-2 Functions
  59          *
  60          * The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC
  61          * value per RFC 2104, using SHA-256 as the hash algorithm "H", using
  62          * the received JWS Signing Input as the "text" value, and using the
  63          * shared key.  This computed HMAC value is then compared to the result
  64          * of base64url decoding the received encoded JWS Signature value.  The
  65          * comparison of the computed HMAC value to the JWS Signature value MUST
  66          * be done in a constant-time manner to thwart timing attacks.
  67          *
  68          * Alternatively, the computed HMAC value can be base64url encoded and
  69          * compared to the received encoded JWS Signature value (also in a
  70          * constant-time manner), as this comparison produces the same result as
  71          * comparing the unencoded values.  In either case, if the values match,
  72          * the HMAC has been validated.
  73          */
  74
  75         {       /* required: HMAC using SHA-256 */
  76                 LWS_GENHASH_TYPE_UNKNOWN,
  77                 LWS_GENHMAC_TYPE_SHA256,
  78                 LWS_JOSE_ENCTYPE_NONE,
  79                 LWS_JOSE_ENCTYPE_NONE,
  80                 "HS256", NULL, 0, 0, 0
  81         },
  82         {       /* optional: HMAC using SHA-384 */
  83                 LWS_GENHASH_TYPE_UNKNOWN,
  84                 LWS_GENHMAC_TYPE_SHA384,
  85                 LWS_JOSE_ENCTYPE_NONE,
  86                 LWS_JOSE_ENCTYPE_NONE,
  87                 "HS384", NULL, 0, 0, 0
  88         },
  89         {       /* optional: HMAC using SHA-512 */
  90                 LWS_GENHASH_TYPE_UNKNOWN,
  91                 LWS_GENHMAC_TYPE_SHA512,
  92                 LWS_JOSE_ENCTYPE_NONE,
  93                 LWS_JOSE_ENCTYPE_NONE,
  94                 "HS512", NULL, 0, 0, 0
  95         },
  96
  97         /*
  98          * Digital Signature with RSASSA-PKCS1-v1_5
  99          *
 100          * This section defines the use of the RSASSA-PKCS1-v1_5 digital
 101          * signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447]
 102          * (commonly known as PKCS #1), using SHA-2 [SHS] hash functions.
 103          *
 104          * A key of size 2048 bits or larger MUST be used with these algorithms.
 105          *
 106          * The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as
 107          * follows: generate a digital signature of the JWS Signing Input using
 108          * RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired
 109          * private key.  This is the JWS Signature value.
 110          *
 111          * The RSASSA-PKCS1-v1_5 SHA-256 digital signature for a JWS is
 112          * validated as follows: submit the JWS Signing Input, the JWS
 113          * Signature, and the public key corresponding to the private key used
 114          * by the signer to the RSASSA-PKCS1-v1_5-VERIFY algorithm using SHA-256
 115          * as the hash function.
 116          */
 117
 118         {       /* recommended: RSASSA-PKCS1-v1_5 using SHA-256 */
 119                 LWS_GENHASH_TYPE_SHA256,
 120                 LWS_GENHMAC_TYPE_UNKNOWN,
 121                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
 122                 LWS_JOSE_ENCTYPE_NONE,
 123                 "RS256", NULL, 2048, 4096, 0
 124         },
 125         {       /* optional: RSASSA-PKCS1-v1_5 using SHA-384 */
 126                 LWS_GENHASH_TYPE_SHA384,
 127                 LWS_GENHMAC_TYPE_UNKNOWN,
 128                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
 129                 LWS_JOSE_ENCTYPE_NONE,
 130                 "RS384", NULL, 2048, 4096, 0
 131         },
 132         {       /* optional: RSASSA-PKCS1-v1_5 using SHA-512 */
 133                 LWS_GENHASH_TYPE_SHA512,
 134                 LWS_GENHMAC_TYPE_UNKNOWN,
 135                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
 136                 LWS_JOSE_ENCTYPE_NONE,
 137                 "RS512", NULL, 2048, 4096, 0
 138         },
 139
 140         /*
 141          * Digital Signature with ECDSA
 142          *
 143          * The ECDSA P-256 SHA-256 digital signature is generated as follows:
 144          *
 145          * 1.  Generate a digital signature of the JWS Signing Input using ECDSA
 146          *     P-256 SHA-256 with the desired private key.  The output will be
 147          *     the pair (R, S), where R and S are 256-bit unsigned integers.
 148          * 2.  Turn R and S into octet sequences in big-endian order, with each
 149          *     array being be 32 octets long.  The octet sequence
 150          *     representations MUST NOT be shortened to omit any leading zero
 151          *     octets contained in the values.
 152          *
 153          * 3.  Concatenate the two octet sequences in the order R and then S.
 154          *     (Note that many ECDSA implementations will directly produce this
 155          *     concatenation as their output.)
 156          *
 157          * 4.  The resulting 64-octet sequence is the JWS Signature value.
 158          *
 159          * The ECDSA P-256 SHA-256 digital signature for a JWS is validated as
 160          * follows:
 161          *
 162          * 1.  The JWS Signature value MUST be a 64-octet sequence.  If it is
 163          *     not a 64-octet sequence, the validation has failed.
 164          *
 165          * 2.  Split the 64-octet sequence into two 32-octet sequences.  The
 166          *     first octet sequence represents R and the second S.  The values R
 167          *     and S are represented as octet sequences using the Integer-to-
 168          *     OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1]
 169          *     (in big-endian octet order).
 170          * 3.  Submit the JWS Signing Input, R, S, and the public key (x, y) to
 171          *     the ECDSA P-256 SHA-256 validator.
 172          */
 173
 174         {       /* Recommended+: ECDSA using P-256 and SHA-256 */
 175                 LWS_GENHASH_TYPE_SHA256,
 176                 LWS_GENHMAC_TYPE_UNKNOWN,
 177                 LWS_JOSE_ENCTYPE_ECDSA,
 178                 LWS_JOSE_ENCTYPE_NONE,
 179                 "ES256", "P-256", 256, 256, 0
 180         },
 181         {       /* optional: ECDSA using P-384 and SHA-384 */
 182                 LWS_GENHASH_TYPE_SHA384,
 183                 LWS_GENHMAC_TYPE_UNKNOWN,
 184                 LWS_JOSE_ENCTYPE_ECDSA,
 185                 LWS_JOSE_ENCTYPE_NONE,
 186                 "ES384", "P-384", 384, 384, 0
 187         },
 188         {       /* optional: ECDSA using P-521 and SHA-512 */
 189                 LWS_GENHASH_TYPE_SHA512,
 190                 LWS_GENHMAC_TYPE_UNKNOWN,
 191                 LWS_JOSE_ENCTYPE_ECDSA,
 192                 LWS_JOSE_ENCTYPE_NONE,
 193                 "ES512", "P-521", 521, 521, 0
 194         },
 195 #if 0
 196         Not yet supported
 197
 198         /*
 199          * Digital Signature with RSASSA-PSS
 200          *
 201          * A key of size 2048 bits or larger MUST be used with this algorithm.
 202          *
 203          * The RSASSA-PSS SHA-256 digital signature is generated as follows:
 204          * generate a digital signature of the JWS Signing Input using RSASSA-
 205          * PSS-SIGN, the SHA-256 hash function, and the MGF1 mask generation
 206          * function with SHA-256 with the desired private key.  This is the JWS
 207          * Signature value.
 208          *
 209          * The RSASSA-PSS SHA-256 digital signature for a JWS is validated as
 210          * follows: submit the JWS Signing Input, the JWS Signature, and the
 211          * public key corresponding to the private key used by the signer to the
 212          * RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and
 213          * using MGF1 as the mask generation function with SHA-256.
 214          *
 215          */
 216         {       /* optional: RSASSA-PSS using SHA-256 and MGF1 with SHA-256 */
 217                 LWS_GENHASH_TYPE_SHA256,
 218                 LWS_GENHMAC_TYPE_UNKNOWN,
 219                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
 220                 LWS_JOSE_ENCTYPE_NONE,
 221                 "PS256", NULL, 2048, 4096, 0
 222         },
 223         {       /* optional: RSASSA-PSS using SHA-384 and MGF1 with SHA-384 */
 224                 LWS_GENHASH_TYPE_SHA384,
 225                 LWS_GENHMAC_TYPE_UNKNOWN,
 226                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
 227                 LWS_JOSE_ENCTYPE_NONE,
 228                 "PS384", NULL, 2048, 4096, 0
 229         },
 230         {       /* optional: RSASSA-PSS using SHA-512 and MGF1 with SHA-512*/
 231                 LWS_GENHASH_TYPE_SHA512,
 232                 LWS_GENHMAC_TYPE_UNKNOWN,
 233                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_PSS,
 234                 LWS_JOSE_ENCTYPE_NONE,
 235                 "PS512", NULL, 2048, 4096, 0
 236         },
 237 #endif
 238 };
 239
 240 /*
 241  * These came from RFC7518 (JSON Web Algorithms) Section 4
 242  *
 243  * Cryptographic Algorithms for Key Management
 244  *
 245  * JWE uses cryptographic algorithms to encrypt or determine the Content
 246  * Encryption Key (CEK).
 247  */
 248
 249 static const struct lws_jose_jwe_alg lws_gencrypto_jwe_alg_map[] = {
 250
 251         /*
 252          * This section defines the specifics of encrypting a JWE CEK with
 253          * RSAES-PKCS1-v1_5 [RFC3447].  The "alg" (algorithm) Header Parameter
 254          * value "RSA1_5" is used for this algorithm.
 255          *
 256          * A key of size 2048 bits or larger MUST be used with this algorithm.
 257          */
 258
 259         {       /* recommended-: RSAES-PKCS1-v1_5 */
 260                 LWS_GENHASH_TYPE_SHA256,
 261                 LWS_GENHMAC_TYPE_UNKNOWN,
 262                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_1_5,
 263                 LWS_JOSE_ENCTYPE_NONE,
 264                 "RSA1_5", NULL, 2048, 4096, 0
 265         },
 266         {       /* recommended+: RSAES OAEP using default parameters */
 267                 LWS_GENHASH_TYPE_SHA1,
 268                 LWS_GENHMAC_TYPE_UNKNOWN,
 269                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_OAEP,
 270                 LWS_JOSE_ENCTYPE_NONE,
 271                 "RSA-OAEP", NULL, 2048, 4096, 0
 272         },
 273         {       /* recommended+: RSAES OAEP using SHA-256 and MGF1 SHA-256 */
 274                 LWS_GENHASH_TYPE_SHA256,
 275                 LWS_GENHMAC_TYPE_UNKNOWN,
 276                 LWS_JOSE_ENCTYPE_RSASSA_PKCS1_OAEP,
 277                 LWS_JOSE_ENCTYPE_NONE,
 278                 "RSA-OAEP-256", NULL, 2048, 4096, 0
 279         },
 280
 281         /*
 282          * Key Wrapping with AES Key Wrap
 283          *
 284          * This section defines the specifics of encrypting a JWE CEK with the
 285          * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
 286          * the default initial value specified in Section 2.2.3.1 of that
 287          * document.
 288          *
 289          *
 290          */
 291         {       /* recommended: AES Key Wrap with AES Key Wrap with defaults
 292                                 using 128-bit key  */
 293                 LWS_GENHASH_TYPE_UNKNOWN,
 294                 LWS_GENHMAC_TYPE_UNKNOWN,
 295                 LWS_JOSE_ENCTYPE_AES_ECB,
 296                 LWS_JOSE_ENCTYPE_NONE,
 297                 "A128KW", NULL, 128, 128, 64
 298         },
 299
 300         {       /* optional: AES Key Wrap with AES Key Wrap with defaults
 301                                 using 192-bit key */
 302                 LWS_GENHASH_TYPE_UNKNOWN,
 303                 LWS_GENHMAC_TYPE_UNKNOWN,
 304                 LWS_JOSE_ENCTYPE_AES_ECB,
 305                 LWS_JOSE_ENCTYPE_NONE,
 306                 "A192KW", NULL, 192, 192, 64
 307         },
 308
 309         {       /* recommended: AES Key Wrap with AES Key Wrap with defaults
 310                                 using 256-bit key */
 311                 LWS_GENHASH_TYPE_UNKNOWN,
 312                 LWS_GENHMAC_TYPE_UNKNOWN,
 313                 LWS_JOSE_ENCTYPE_AES_ECB,
 314                 LWS_JOSE_ENCTYPE_NONE,
 315                 "A256KW", NULL, 256, 256, 64
 316         },
 317
 318         /*
 319          * This section defines the specifics of directly performing symmetric
 320          * key encryption without performing a key wrapping step.  In this case,
 321          * the shared symmetric key is used directly as the Content Encryption
 322          * Key (CEK) value for the "enc" algorithm.  An empty octet sequence is
 323          * used as the JWE Encrypted Key value.  The "alg" (algorithm) Header
 324          * Parameter value "dir" is used in this case.
 325          */
 326         {       /* recommended */
 327                 LWS_GENHASH_TYPE_UNKNOWN,
 328                 LWS_GENHMAC_TYPE_UNKNOWN,
 329                 LWS_JOSE_ENCTYPE_NONE,
 330                 LWS_JOSE_ENCTYPE_NONE,
 331                 "dir", NULL, 0, 0, 0
 332         },
 333
 334         /*
 335          * Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static
 336          * (ECDH-ES)
 337          *
 338          * This section defines the specifics of key agreement with Elliptic
 339          * Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with
 340          * the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A].  The
 341          * key agreement result can be used in one of two ways:
 342          *
 343          * 1.  directly as the Content Encryption Key (CEK) for the "enc"
 344          *     algorithm, in the Direct Key Agreement mode, or
 345          *
 346          * 2.  as a symmetric key used to wrap the CEK with the "A128KW",
 347          *     "A192KW", or "A256KW" algorithms, in the Key Agreement with Key
 348          *     Wrapping mode.
 349          *
 350          * A new ephemeral public key value MUST be generated for each key
 351          * agreement operation.
 352          *
 353          * In Direct Key Agreement mode, the output of the Concat KDF MUST be a
 354          * key of the same length as that used by the "enc" algorithm.  In this
 355          * case, the empty octet sequence is used as the JWE Encrypted Key
 356          * value.  The "alg" (algorithm) Header Parameter value "ECDH-ES" is
 357          * used in the Direct Key Agreement mode.
 358          *
 359          * In Key Agreement with Key Wrapping mode, the output of the Concat KDF
 360          * MUST be a key of the length needed for the specified key wrapping
 361          * algorithm.  In this case, the JWE Encrypted Key is the CEK wrapped
 362          * with the agreed-upon key.
 363          */
 364
 365         {       /* recommended+: ECDH Ephemeral Static Key agreement Concat KDF */
 366                 LWS_GENHASH_TYPE_SHA256,
 367                 LWS_GENHMAC_TYPE_UNKNOWN,
 368                 LWS_JOSE_ENCTYPE_ECDHES,
 369                 LWS_JOSE_ENCTYPE_NONE,
 370                 "ECDH-ES", NULL, 128, 128, 0
 371         },
 372         {       /* recommended: ECDH-ES + Concat KDF + wrapped by AES128KW */
 373                 LWS_GENHASH_TYPE_SHA256,
 374                 LWS_GENHMAC_TYPE_UNKNOWN,
 375                 LWS_JOSE_ENCTYPE_ECDHES,
 376                 LWS_JOSE_ENCTYPE_AES_ECB,
 377                 "ECDH-ES+A128KW", NULL, 128, 128, 0
 378         },
 379         {       /* optional: ECDH-ES + Concat KDF + wrapped by AES192KW */
 380                 LWS_GENHASH_TYPE_SHA256,
 381                 LWS_GENHMAC_TYPE_UNKNOWN,
 382                 LWS_JOSE_ENCTYPE_ECDHES,
 383                 LWS_JOSE_ENCTYPE_AES_ECB,
 384                 "ECDH-ES+A192KW", NULL, 192, 192, 0
 385         },
 386         {       /* recommended: ECDH-ES + Concat KDF + wrapped by AES256KW */
 387                 LWS_GENHASH_TYPE_SHA256,
 388                 LWS_GENHMAC_TYPE_UNKNOWN,
 389                 LWS_JOSE_ENCTYPE_ECDHES,
 390                 LWS_JOSE_ENCTYPE_AES_ECB,
 391                 "ECDH-ES+A256KW", NULL, 256, 256, 0
 392         },
 393
 394         /*
 395          * Key Encryption with AES GCM
 396          *
 397          *  This section defines the specifics of encrypting a JWE Content
 398          *  Encryption Key (CEK) with Advanced Encryption Standard (AES) in
 399          *  Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).
 400          *
 401          * Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with
 402          * this algorithm.  The IV is represented in base64url-encoded form as
 403          * the "iv" (initialization vector) Header Parameter value.
 404          *
 405          * The Additional Authenticated Data value used is the empty octet
 406          * string.
 407          *
 408          * The requested size of the Authentication Tag output MUST be 128 bits,
 409          * regardless of the key size.
 410          *
 411          * The JWE Encrypted Key value is the ciphertext output.
 412          *
 413          * The Authentication Tag output is represented in base64url-encoded
 414          * form as the "tag" (authentication tag) Header Parameter value.
 415          *
 416          *
 417          * "iv" (Initialization Vector) Header Parameter
 418          *
 419          * The "iv" (initialization vector) Header Parameter value is the
 420          * base64url-encoded representation of the 96-bit IV value used for the
 421          * key encryption operation.  This Header Parameter MUST be present and
 422          * MUST be understood and processed by implementations when these
 423          * algorithms are used.
 424          *
 425          * "tag" (Authentication Tag) Header Parameter
 426          *
 427          * The "tag" (authentication tag) Header Parameter value is the
 428          * base64url-encoded representation of the 128-bit Authentication Tag
 429          * value resulting from the key encryption operation.  This Header
 430          * Parameter MUST be present and MUST be understood and processed by
 431          * implementations when these algorithms are used.
 432          */
 433         {       /* optional: Key wrapping with AES GCM using 128-bit key  */
 434                 LWS_GENHASH_TYPE_UNKNOWN,
 435                 LWS_GENHMAC_TYPE_UNKNOWN,
 436                 LWS_JOSE_ENCTYPE_AES_ECB,
 437                 LWS_JOSE_ENCTYPE_NONE,
 438                 "A128GCMKW", NULL, 128, 128, 96
 439         },
 440
 441         {       /* optional: Key wrapping with AES GCM using 192-bit key */
 442                 LWS_GENHASH_TYPE_UNKNOWN,
 443                 LWS_GENHMAC_TYPE_UNKNOWN,
 444                 LWS_JOSE_ENCTYPE_AES_ECB,
 445                 LWS_JOSE_ENCTYPE_NONE,
 446                 "A192GCMKW", NULL, 192, 192, 96
 447         },
 448
 449         {       /* optional: Key wrapping with AES GCM using 256-bit key */
 450                 LWS_GENHASH_TYPE_UNKNOWN,
 451                 LWS_GENHMAC_TYPE_UNKNOWN,
 452                 LWS_JOSE_ENCTYPE_AES_ECB,
 453                 LWS_JOSE_ENCTYPE_NONE,
 454                 "A256GCMKW", NULL, 256, 256, 96
 455         },
 456
 457         /* list terminator */
 458         { 0, 0, 0, 0, NULL, NULL }
 459 };
 460
 461 /*
 462  * The "enc" (encryption algorithm) Header Parameter identifies the
 463  * content encryption algorithm used to perform authenticated encryption
 464  * on the plaintext to produce the ciphertext and the Authentication
 465  * Tag.  This algorithm MUST be an AEAD algorithm with a specified key
 466  * length.  The encrypted content is not usable if the "enc" value does
 467  * not represent a supported algorithm.  "enc" values should either be
 468  * registered in the IANA "JSON Web Signature and Encryption Algorithms"
 469  * registry established by [JWA] or be a value that contains a
 470  * Collision-Resistant Name.  The "enc" value is a case-sensitive ASCII
 471  * string containing a StringOrURI value.  This Header Parameter MUST be
 472  * present and MUST be understood and processed by implementations.
 473  */
 474
 475 static const struct lws_jose_jwe_alg lws_gencrypto_jwe_enc_map[] = {
 476         /*
 477          * AES_128_CBC_HMAC_SHA_256 / 512
 478          *
 479          * It uses the HMAC message authentication code [RFC2104] with the
 480          * SHA-256 hash function [SHS] to provide message authentication, with
 481          * the HMAC output truncated to 128 bits, corresponding to the
 482          * HMAC-SHA-256-128 algorithm defined in [RFC4868].  For encryption, it
 483          * uses AES in the CBC mode of operation as defined in Section 6.2 of
 484          * [NIST.800-38A], with PKCS #7 padding and a 128-bit IV value.
 485          *
 486          * The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256
 487          * are:
 488          *
 489          * The input key K is 32 octets long.
 490          *       ENC_KEY_LEN is 16 octets.
 491          *       MAC_KEY_LEN is 16 octets.
 492          *       The SHA-256 hash algorithm is used for the HMAC.
 493          *       The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
 494          *       stripping off the final 16 octets.
 495          */
 496         {       /* required */
 497                 LWS_GENHASH_TYPE_UNKNOWN,
 498                 LWS_GENHMAC_TYPE_SHA256,
 499                 LWS_JOSE_ENCTYPE_NONE,
 500                 LWS_JOSE_ENCTYPE_AES_CBC,
 501                 "A128CBC-HS256", NULL, 256, 256, 128
 502         },
 503         /*
 504          * AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but
 505          * with the following differences:
 506          *
 507          * The input key K is 48 octets long instead of 32.
 508          * ENC_KEY_LEN is 24 octets instead of 16.
 509          * MAC_KEY_LEN is 24 octets instead of 16.
 510          * SHA-384 is used for the HMAC instead of SHA-256.
 511          * The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of 16.
 512          */
 513         {       /* required */
 514                 LWS_GENHASH_TYPE_UNKNOWN,
 515                 LWS_GENHMAC_TYPE_SHA384,
 516                 LWS_JOSE_ENCTYPE_NONE,
 517                 LWS_JOSE_ENCTYPE_AES_CBC,
 518                 "A192CBC-HS384", NULL, 384, 384, 192
 519         },
 520         /*
 521          * AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but
 522          * with the following differences:
 523          *
 524          * The input key K is 64 octets long instead of 32.
 525          * ENC_KEY_LEN is 32 octets instead of 16.
 526          * MAC_KEY_LEN is 32 octets instead of 16.
 527          * SHA-512 is used for the HMAC instead of SHA-256.
 528          * The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of 16.
 529          */
 530         {       /* required */
 531                 LWS_GENHASH_TYPE_UNKNOWN,
 532                 LWS_GENHMAC_TYPE_SHA512,
 533                 LWS_JOSE_ENCTYPE_NONE,
 534                 LWS_JOSE_ENCTYPE_AES_CBC,
 535                 "A256CBC-HS512", NULL, 512, 512, 256
 536         },
 537
 538         /*
 539          * The CEK is used as the encryption key.
 540          *
 541          * Use of an IV of size 96 bits is REQUIRED with this algorithm.
 542          *
 543          * The requested size of the Authentication Tag output MUST be 128 bits,
 544          * regardless of the key size.
 545          */
 546         {       /* recommended: AES GCM using 128-bit key  */
 547                 LWS_GENHASH_TYPE_UNKNOWN,
 548                 LWS_GENHMAC_TYPE_UNKNOWN,
 549                 LWS_JOSE_ENCTYPE_NONE,
 550                 LWS_JOSE_ENCTYPE_AES_GCM,
 551                 "A128GCM", NULL, 128, 128, 96
 552         },
 553         {       /* optional: AES GCM using 192-bit key  */
 554                 LWS_GENHASH_TYPE_UNKNOWN,
 555                 LWS_GENHMAC_TYPE_UNKNOWN,
 556                 LWS_JOSE_ENCTYPE_NONE,
 557                 LWS_JOSE_ENCTYPE_AES_GCM,
 558                 "A192GCM", NULL, 192, 192, 96
 559         },
 560         {       /* recommended: AES GCM using 256-bit key */
 561                 LWS_GENHASH_TYPE_UNKNOWN,
 562                 LWS_GENHMAC_TYPE_UNKNOWN,
 563                 LWS_JOSE_ENCTYPE_NONE,
 564                 LWS_JOSE_ENCTYPE_AES_GCM,
 565                 "A256GCM", NULL, 256, 256, 96
 566         },
 567         { 0, 0, 0, 0, NULL, NULL, 0, 0, 0 } /* sentinel */
 568 };
 569
 570 LWS_VISIBLE int
 571 lws_gencrypto_jws_alg_to_definition(const char *alg,
 572                                     const struct lws_jose_jwe_alg **jose)
 573 {
 574         const struct lws_jose_jwe_alg *a = lws_gencrypto_jws_alg_map;
 575
 576         while (a->alg) {
 577                 if (!strcmp(alg, a->alg)) {
 578                         *jose = a;
 579
 580                         return 0;
 581                 }
 582                 a++;
 583         }
 584
 585         return 1;
 586 }
 587
 588 LWS_VISIBLE int
 589 lws_gencrypto_jwe_alg_to_definition(const char *alg,
 590                                     const struct lws_jose_jwe_alg **jose)
 591 {
 592         const struct lws_jose_jwe_alg *a = lws_gencrypto_jwe_alg_map;
 593
 594         while (a->alg) {
 595                 if (!strcmp(alg, a->alg)) {
 596                         *jose = a;
 597
 598                         return 0;
 599                 }
 600                 a++;
 601         }
 602
 603         return 1;
 604 }
 605
 606 LWS_VISIBLE int
 607 lws_gencrypto_jwe_enc_to_definition(const char *enc,
 608                                     const struct lws_jose_jwe_alg **jose)
 609 {
 610         const struct lws_jose_jwe_alg *e = lws_gencrypto_jwe_enc_map;
 611
 612         while (e->alg) {
 613                 if (!strcmp(enc, e->alg)) {
 614                         *jose = e;
 615
 616                         return 0;
 617                 }
 618                 e++;
 619         }
 620
 621         return 1;
 622 }
 623
 624 size_t
 625 lws_genhash_size(enum lws_genhash_types type)
 626 {
 627         switch(type) {
 628         case LWS_GENHASH_TYPE_UNKNOWN:
 629                 return 0;
 630         case LWS_GENHASH_TYPE_MD5:
 631                 return 16;
 632         case LWS_GENHASH_TYPE_SHA1:
 633                 return 20;
 634         case LWS_GENHASH_TYPE_SHA256:
 635                 return 32;
 636         case LWS_GENHASH_TYPE_SHA384:
 637                 return 48;
 638         case LWS_GENHASH_TYPE_SHA512:
 639                 return 64;
 640         }
 641
 642         return 0;
 643 }
 644
 645 size_t
 646 lws_genhmac_size(enum lws_genhmac_types type)
 647 {
 648         switch(type) {
 649         case LWS_GENHMAC_TYPE_UNKNOWN:
 650                 return 0;
 651         case LWS_GENHMAC_TYPE_SHA256:
 652                 return 32;
 653         case LWS_GENHMAC_TYPE_SHA384:
 654                 return 48;
 655         case LWS_GENHMAC_TYPE_SHA512:
 656                 return 64;
 657         }
 658
 659         return 0;
 660 }
 661
 662 int
 663 lws_gencrypto_bits_to_bytes(int bits)
 664 {
 665         if (bits & 7)
 666                 return (bits / 8) + 1;
 667
 668         return bits / 8;
 669 }
 670
 671 int
 672 lws_base64_size(int bytes)
 673 {
 674         return ((bytes * 4) / 3) + 6;
 675 }
 676
 677 void
 678 lws_gencrypto_destroy_elements(struct lws_gencrypto_keyelem *el, int m)
 679 {
 680         int n;
 681
 682         for (n = 0; n < m; n++)
 683                 if (el[n].buf)
 684                         lws_free_set_NULL(el[n].buf);
 685 }