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