Code Monkey home page Code Monkey logo

rhonabwy's Introduction

What?

Main projects

Project Descripion License Last release
Glewlwyd Experimental Single Sign On server, OAuth2, Openid Connect, MFA GitHub GitHub release (latest by date)
Ulfius Web Framework in C GitHub GitHub release (latest by date)
Rhonabwy JWK, JWKS, JWS, JWE and JWT C library GitHub GitHub release (latest by date)
Iddawc OAuth2 and OIDC client library GitHub GitHub release (latest by date)
Hoel C Database abstraction library with json based language GitHub GitHub release (latest by date)
Taliesin Lightweight audio streaming server GitHub GitHub release (latest by date)
Angharad House automation system with a REST/Json interface GitHub GitHub release (latest by date)
Hutch Online password and secret locker GitHub GitHub release (latest by date)
Yder Logging library for C applications GitHub GitHub release (latest by date)
Orcania Potluck library GitHub GitHub release (latest by date)

Other projects

Project Descripion License
Taulas Arduino source files for Angharad system devices GitHub
Huddersfield Project packages builder and publisher GitHub

Why?

C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

Coding backend in C and front-end in HTML/Javascript is the true meaning of life.

Who?

Nicolas Mora

My GPG key: 8405 B02F CC28 EF97 44C8 F253 FE82 1394 40BD 22B9

avatar I don't look like that

Where?

Québec City, Canada

How?

(Debian || Ubuntu) && GNU && Geany

rhonabwy's People

Contributors

babelouest avatar drok avatar ergonjona avatar faustocarva avatar ksivask avatar mkauf avatar sjoerdsimons avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

rhonabwy's Issues

Flawed check that the "kty" member is present in JWKs

JWKs must have a "kty" member. From RFC 7517:

The "kty" value is a case-sensitive string. This member MUST be present in a JWK.

In the function r_jwk_is_valid() in jwk.c, there are some checks:

  • "kty" and "alg" must not be missing at the same time
  • the public key parameters may be missing if "kty" is missing

I don't understand the reasoning behind this. "kty" should always be present, and this should be checked.

Current code:

// Validate if required parameters are present and consistent
if (ret == RHN_OK) {
  if (!has_kty) {
    if (!has_alg) {
      y_log_message(Y_LOG_LEVEL_ERROR, "r_jwk_is_valid - Invalid data");
      ret = RHN_ERROR_PARAM;
    }
  } else {
    if (has_kty && !has_pubkey_parameters) {
      y_log_message(Y_LOG_LEVEL_ERROR, "r_jwk_is_valid - public key parameters missing");
      ret = RHN_ERROR_PARAM;
    }
  }
}

validating array values

Hello,

I have a audience claim, which is a list (generated by Keycloak):

"aud": [
    "ldaps://school.dev/",
    "account"
  ],

r_jwt_validate_claims(jwt, R_JWT_CLAIM_AUD, "ldaps://school.dev/", R_JWT_CLAIM_NOP) doesn't return RHN_OK.
and r_jwt_get_claim_str_value(jwt, "aud") returns NULL.

What can I do, to validate this correctly?

Disable the support for embedded JWKs or allow to disable it

Hello @babelouest,
thanks for creating rhonabwy!
I noticed that rhonabwy seems to support embedded JWKs in JWE and JWS:

I'm not sure yet whether this could lead to a vulnerability in this context or not, but I think it would be good if this feature was disabled by default or if it were possible to disable that feature (e.g. like it's possible to disable remote certificates with R_FLAG_IGNORE_REMOTE).

In an OIDC context it makes sense to disable these features anyway, as the OpenID Connect Core 1.0 spec says:

ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields. Instead, references to keys used are communicated in advance using Discovery and Registration parameters

undefined reference to `o_base64_encode_alloc'

I have checked that the function definition is present in "rhonabwy-1.1.10/build/orcania-src/src/base64.c" and installed liborcania-dev package as well. But still it throws error.

Logs:
vediyappan@vediyappan:/vediyappan/work/rhonabwy-1.1.10/build$ make && sudo make install
[ 11%] Building C object CMakeFiles/rhonabwy.dir/src/misc.c.o
[ 22%] Building C object CMakeFiles/rhonabwy.dir/src/jwk.c.o
[ 33%] Building C object CMakeFiles/rhonabwy.dir/src/jwks.c.o
[ 44%] Building C object CMakeFiles/rhonabwy.dir/src/jws.c.o
[ 55%] Building C object CMakeFiles/rhonabwy.dir/src/jwe.c.o
[ 66%] Building C object CMakeFiles/rhonabwy.dir/src/jwt.c.o
[ 77%] Linking C shared library librhonabwy.so
[ 77%] Built target rhonabwy
[ 88%] Building C object CMakeFiles/rnbyc.dir/tools/rnbyc/rnbyc.c.o
[100%] Linking C executable rnbyc
/usr/bin/ld: librhonabwy.so.1.1.10: undefined reference to o_base64_encode_alloc' /usr/bin/ld: librhonabwy.so.1.1.10: undefined reference to o_strnullempty'
/usr/bin/ld: librhonabwy.so.1.1.10: undefined reference to o_base64url_encode_alloc' /usr/bin/ld: librhonabwy.so.1.1.10: undefined reference to o_base64_decode_alloc'
/usr/bin/ld: librhonabwy.so.1.1.10: undefined reference to `o_base64url_decode_alloc'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/rnbyc.dir/build.make:105: rnbyc] Error 1
make[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/rnbyc.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
vediyappan@vediyappan:
/vediyappan/work/rhonabwy-1.1.10/build$

Build failed on FreeBSD-14 which use clang15 as cc

the failed build log:

===> Building for rhonabwy-1.1.11
[ 25% 1/4] /usr/bin/cc -Drhonabwy_EXPORTS -I/usr/local/include -I/usr/ports/security/rhonabwy/work/rhonabwy-1.1.11/include -I/usr/ports/security/rhonabwy/work/.build -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Werror -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=gnu99 -fPIC -Wextra -Wconversion -MD -MT CMakeFiles/rhonabwy.dir/src/jwe.c.o -MF CMakeFiles/rhonabwy.dir/src/jwe.c.o.d -o CMakeFiles/rhonabwy.dir/src/jwe.c.o -c /usr/ports/security/rhonabwy/work/rhonabwy-1.1.11/src/jwe.c
FAILED: CMakeFiles/rhonabwy.dir/src/jwe.c.o
/usr/bin/cc -Drhonabwy_EXPORTS -I/usr/local/include -I/usr/ports/security/rhonabwy/work/rhonabwy-1.1.11/include -I/usr/ports/security/rhonabwy/work/.build -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Werror -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -std=gnu99 -fPIC -Wextra -Wconversion -MD -MT CMakeFiles/rhonabwy.dir/src/jwe.c.o -MF CMakeFiles/rhonabwy.dir/src/jwe.c.o.d -o CMakeFiles/rhonabwy.dir/src/jwe.c.o -c /usr/ports/security/rhonabwy/work/rhonabwy-1.1.11/src/jwe.c
In file included from /usr/ports/security/rhonabwy/work/rhonabwy-1.1.11/src/jwe.c:47:
In file included from /usr/local/include/nettle/bignum.h:50:
/usr/local/include/gmp.h:1875:30: error: operand of ? changes signedness: 'const int' to 'size_t' (aka 'unsigned long') [-Werror,-Wsign-conversion]
return __GMP_ABS (__gmp_z->_mp_size);

/usr/local/include/gmp.h:446:37: note: expanded from macro '__GMP_ABS'
#define __GMP_ABS(x)   ((x) >= 0 ? (x) : -(x))
                                  ^
/usr/local/include/gmp.h:1875:10: error: operand of ? changes signedness: 'int' to 'size_t' (aka 'unsigned long') [-Werror,-Wsign-conversion]
return __GMP_ABS (__gmp_z->_mp_size);
~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/gmp.h:446:42: note: expanded from macro '__GMP_ABS'
#define __GMP_ABS(x)   ((x) >= 0 ? (x) : -(x))
                                       ^~~~
2 errors generated.
ninja: build stopped: subcommand failed.

Any suggestion ?

specify non-default path to CA cert when importing JWK(S) from remote server

Hi , rhonabwy requires libcurl when importing JWK(S) from remote server , and libcurl uses /etc/ssl/cert as the default path to CA cert (according to the command curl-config --ca).

In my case, I need to specify different CA certs (including Let'sencrypt or self-signed) to different test cases in my project, so would it be good to have an option to let application callers specify CA path in each HTTP request (e.g. made by curl_easy_perform()) ? AFAIK _r_get_http_content(...) loads serialized JWK(S) from remote server then following functions calling _r_get_http_content(...) decodes the response body :

r_jwk_key_type(...)
r_jwk_import_from_x5u(...)
r_jwk_export_to_gnutls_pubkey(...)
r_jwk_export_to_gnutls_crt(...)
r_jwks_import_from_uri(...)

The functions above could probably have extra argument for CA path , but I am not sure if you have better design option and plan to do it in future release ? thanks for reading.

Build of rnbyc failed on Mac

Hello,

I'm trying to compile rnbyc on Mac, bu I get this error: 'gnutls/abstract.h' file not found. I installed gnutls and I tried to add the -I flag to compilation:

CFLAGS+=-Wall -Werror -Wextra -Wconversion -I$(RHONABWY_INCLUDE) -I/opt/homebrew/Cellar/gnutls/3.8.0/include $(ADDITIONALFLAGS) $(CPPFLAGS)

Could you help me in spotting what I am doing wrong?

Thanks in advance.

Question: is my code safe against `alg: null`?

I have a short question and just want to be sure that my assumptions are correct:

The docstring for r_jwt_verify_signature says:

 * Verifies the signature of the JWT
 * The JWT must contain a signature
 * or the JWT must have alg: none

(https://babelouest.github.io/rhonabwy/group__jwt.html#ga2ab2ec575660117efec3e576f189fa67)

and I see no flag to prevent this.

But the use of r_jwt_parse() already ensures that alg: null causes an error, right? but r_jwt_parse_unsecure() would allow this?

my code looks like:

if (r_jwt_parse(jwt, msg, 0) == RHN_OK) {
    if ((error = r_jwt_verify_signature(jwt, jwk, 0)) != RHN_OK)
        return error;
}

Incorrect KDF for AxxxCBC with ECDH-ES

Sample EC256 Key & Data:

root@9ac53b23f309:/tmp/jtests# cat ec256.keys
    {
      "crv": "P-256",
      "d": "oFsqPRb6-_4lsQxpo9SkpI_msq_77wEgIsCiwLaMWgA",
      "kid": "ExUMY91J9atex-1Ai5vbu6qJ4aAGq0RMQxo__QyZV4k",
      "kty": "EC",
      "x": "g2L0jXitI0uUgmsKCUJjMVr20NrU5uHVlTbbXEd5UvY",
      "y": "MCcXesyMUYS3l6PvyQeN6B6Ou1UiWQF-7OeIZBWmgK4"
    }

root@edb8bbbd1def:/j/tests# data='{"sub": "[email protected]","name": "JohnDoe","iat": 1516239022}'

rhonabwy:

Using https://github.com/babelouest/rhonabwy

root@edb8bbbd1def:/j/tests# /j/jwtc/rnbyc -s "$data" -l ECDH-ES  -e A256CBC-HS512 -P ec256.jwks -K o256.jwks -a HS256

jwt: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6IktPTWdUTFdhTDdzN0s5S0JBNldsc0EifQ.eyJzdWIiOiJqZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkpvaG5Eb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.3cr0Mhmthj0_-btt69sRLvbGb7ScD4lpcp-8MMArk90

r_jwe_encrypt_payload: jwe->key
BE CD C2 20 52 27 2E 77  9D 4E CA E3 D6 E1 0F 3B
36 2C 0F B7 F1 23 FF DF  36 C9 A3 13 81 F1 64 D0
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

jwe: eyJ0eXAiOiJKV1QiLCJjdHkiOiJKV1QiLCJhbGciOiJFQ0RILUVTIiwia2lkIjoiRXhVTVk5MUo5YXRleC0xQWk1dmJ1NnFKNGFBR3EwUk1ReG9fX1F5WlY0ayIsImVwayI6eyJrdHkiOiJFQyIsIngiOiJOWjZJSlk4WTNlZVhPLXFXZXJ4NUhNeUNsNkFMeWdQaEdFaDEydFpaTkcwIiwieSI6Inl3Vk5GamVpLURQWEpRZ2FxV0lOalZ1R2JEaW94VUp4MDlUZXprb0xVWmsiLCJjcnYiOiJQLTI1NiJ9LCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..z-JRY8K9BjcP3P86ZojJJw.ngURI13qrpyOIc5AvIwcdS9D151f8YVwmsvjWG0kQg9ASELPw82F7Sh5Azrt5to6slyQ4BDib9PdwI3BTg29Wd-jbUYlrsTYx53-Syy5pGSIOhsilTbWo-eIHUPyV8E0m1RC3une-M7uxgiQL79hYvhgC9eteuobsS8dai9FkPjCr2WiOqvevqYtwmAJ_sUkD83-2b98HeZ_ZcDt4E6OHej02DrMFSIs6bhHAspdn2AlxRyHEyO3Z1su7-xafP7zYnKuiG49UppFYoKI_OKMIw.eZxa077Rgt5ogrosk9GN0JJvl2cpljxZ4wRBOuvuWi4

# save jwt and jwe to files

root@9ac53b23f309:/tmp/jtests# cat jwt.txt
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6IktPTWdUTFdhTDdzN0s5S0JBNldsc0EifQ.eyJzdWIiOiJqZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkpvaG5Eb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.3cr0Mhmthj0_-btt69sRLvbGb7ScD4lpcp-8MMArk90

root@9ac53b23f309:/tmp/jtests# cat jwe.txt
eyJ0eXAiOiJKV1QiLCJjdHkiOiJKV1QiLCJhbGciOiJFQ0RILUVTIiwia2lkIjoiRXhVTVk5MUo5YXRleC0xQWk1dmJ1NnFKNGFBR3EwUk1ReG9fX1F5WlY0ayIsImVwayI6eyJrdHkiOiJFQyIsIngiOiJOWjZJSlk4WTNlZVhPLXFXZXJ4NUhNeUNsNkFMeWdQaEdFaDEydFpaTkcwIiwieSI6Inl3Vk5GamVpLURQWEpRZ2FxV0lOalZ1R2JEaW94VUp4MDlUZXprb0xVWmsiLCJjcnYiOiJQLTI1NiJ9LCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..z-JRY8K9BjcP3P86ZojJJw.ngURI13qrpyOIc5AvIwcdS9D151f8YVwmsvjWG0kQg9ASELPw82F7Sh5Azrt5to6slyQ4BDib9PdwI3BTg29Wd-jbUYlrsTYx53-Syy5pGSIOhsilTbWo-eIHUPyV8E0m1RC3une-M7uxgiQL79hYvhgC9eteuobsS8dai9FkPjCr2WiOqvevqYtwmAJ_sUkD83-2b98HeZ_ZcDt4E6OHej02DrMFSIs6bhHAspdn2AlxRyHEyO3Z1su7-xafP7zYnKuiG49UppFYoKI_OKMIw.eZxa077Rgt5ogrosk9GN0JJvl2cpljxZ4wRBOuvuWi4


root@edb8bbbd1def:/j/tests# /j/jwtc/rnbyc -t "$ntok" -K ec256.keys -H true -d
2023-06-29T03:33:20Z - rnbyc INFO: Starting rnbyc debug mode

r_jwe_decrypt_payload: jwe->key
BE CD C2 20 52 27 2E 77  9D 4E CA E3 D6 E1 0F 3B
36 2C 0F B7 F1 23 FF DF  36 C9 A3 13 81 F1 64 D0
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
Token payload decrypted
{
  "alg": "ECDH-ES",
  "cty": "JWT",
  "enc": "A256CBC-HS512",
  "epk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "NZ6IJY8Y3eeXO-qWerx5HMyCl6ALygPhGEh12tZZNG0",
    "y": "ywVNFjei-DPXJQgaqWINjVuGbDioxUJx09TezkoLUZk"
  },
  "kid": "ExUMY91J9atex-1Ai5vbu6qJ4aAGq0RMQxo__QyZV4k",
  "typ": "JWT"
}
{
  "alg": "HS256",
  "kid": "KOMgTLWaL7s7K9KBA6WlsA",
  "typ": "JWT"
}
{
  "iat": 1516239022,
  "name": "JohnDoe",
  "sub": "[email protected]"
}

NOTE: both encrypt and decrypt use {0} as key (last 32 bytes)

go-jose:

Cross verify with go-jose/jose-util: https://github.com/go-jose/go-jose

$git diff
diff --git a/cipher/ecdh_es.go b/cipher/ecdh_es.go
index 093c646..c54f174 100644
--- a/cipher/ecdh_es.go
+++ b/cipher/ecdh_es.go
@@ -22,6 +22,8 @@ import (
        "crypto/ecdsa"
        "crypto/elliptic"
        "encoding/binary"
+       "encoding/hex"
+       "fmt"
 )

 // DeriveECDHES derives a shared encryption key using ECDH/ConcatKDF as described in JWE/JWA.
@@ -64,6 +66,8 @@ func DeriveECDHES(alg string, apuData, apvData []byte, priv *ecdsa.PrivateKey, p
        // Read on the KDF will never fail
        _, _ = reader.Read(key)

+       fmt.Printf("DeriveECDHES: key\n%s", hex.Dump(key))
+
        return key
 }

root@9ac53b23f309:/tmp/jtests# ./jose-util decrypt --key ec256.keys --in jwe.txt

DeriveECDHES: key
00000000  be cd c2 20 52 27 2e 77  9d 4e ca e3 d6 e1 0f 3b  |... R'.w.N.....;|
00000010  36 2c 0f b7 f1 23 ff df  36 c9 a3 13 81 f1 64 d0  |6,...#..6.....d.|
00000020  b7 34 92 35 ac 93 d5 87  cc b1 45 b4 e7 9b 43 9c  |.4.5......E...C.|
00000030  ed 8d b6 de 21 27 34 fa  e7 49 f2 46 dd 30 c9 c7  |....!'4..I.F.0..|
jose-util: error: unable to decrypt message: go-jose/go-jose: error in cryptographic primitive

Using another JWE tool

(gdb) x /64xb jwe.dcek_.data()
0x248ad60:      0xbe    0xcd    0xc2    0x20    0x52    0x27    0x2e    0x77
0x248ad68:      0x9d    0x4e    0xca    0xe3    0xd6    0xe1    0x0f    0x3b
0x248ad70:      0x36    0x2c    0x0f    0xb7    0xf1    0x23    0xff    0xdf
0x248ad78:      0x36    0xc9    0xa3    0x13    0x81    0xf1    0x64    0xd0
0x248ad80:      0xb7    0x34    0x92    0x35    0xac    0x93    0xd5    0x87
0x248ad88:      0xcc    0xb1    0x45    0xb4    0xe7    0x9b    0x43    0x9c
0x248ad90:      0xed    0x8d    0xb6    0xde    0x21    0x27    0x34    0xfa
0x248ad98:      0xe7    0x49    0xf2    0x46    0xdd    0x30    0xc9    0xc7

Patched rnbyc:

root@edb8bbbd1def:/j/tests# /j/jwtc/rnbyc.new -s "$data" -l ECDH-ES  -e A256CBC-HS512 -P ec256.jwks -K o256.jwks -a HS256

jwt: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImlpMXdBTHhXbWxBRHJEUnRuN0cwTlEifQ.eyJzdWIiOiJqZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkpvaG5Eb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.J96TAtD8CQo3tATeUGtKEdb1Pcz_p1Q1a0kFuoghQdg

r_jwe_encrypt_payload: jwe->key
14 FB 29 D7 C7 F7 7F 12  D9 9F D4 63 F6 98 F0 70
6E AD 6C B2 FE 7D EE F0  41 83 BB F9 87 E6 38 06
6A 83 2A 1A C9 6E DC 88  41 3D 20 BD 89 AA E7 2F
41 75 D9 E7 D7 19 BA 01  54 8F F7 0F A0 D5 A4 79

jwe:
eyJ0eXAiOiJKV1QiLCJjdHkiOiJKV1QiLCJhbGciOiJFQ0RILUVTIiwia2lkIjoiRXhVTVk5MUo5YXRleC0xQWk1dmJ1NnFKNGFBR3EwUk1ReG9fX1F5WlY0ayIsImVwayI6eyJrdHkiOiJFQyIsIngiOiJ4YTU5WnpveFlseG10eFRVeW5EaVNpUHpSYkYzdm5RS2Y2ZjcxZkNfSXFjIiwieSI6ImhzRk9lb0RvcmFJUHo3OXVDSERXTmhsbm5XZ3VIZk9sOEw3RnROUlM5cVUiLCJjcnYiOiJQLTI1NiJ9LCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..fbX7a7yaM3FprfHN5juiow.d6Ynb8fL2fcHMEOCcmj9DrJE1T02lU8FFLbLsOHLbKtJ6h26HxHBOnkJWPLWn9P8G9T4Sz49IboSiUpCRRbvYyb-NNLzEYIp4LzBdNQmFfgoUasE6ECtYZJk7NDBe1zwXGFAtmEVCdiGJlAsFsq9DiINKNvGpTQze7ks2d1DwToMjhQjVeNPGW5iBz0fpz_s8Q_CTs1RtnWjuUCjgriMV1sNrd-Ea6xVb5rW3FS99NvH6Xnu81Mu0wLMQFxkq4UFo_kc7XYQ8ToR0i902Ck6NQ.HkJMezu9E-_hbYbkGClfgLtdDobuqWLYFAxVAz1XDeQ

root@edb8bbbd1def:/j/tests# ntok="eyJ0eXAiOiJKV1QiLCJjdHkiOiJKV1QiLCJhbGciOiJFQ0RILUVTIiwia2lkIjoiRXhVTVk5MUo5YXRleC0xQWk1dmJ1NnFKNGFBR3EwUk1ReG9fX1F5WlY0ayIsImVwayI6eyJrdHkiOiJFQyIsIngiOiJ4YTU5WnpveFlseG10eFRVeW5EaVNpUHpSYkYzdm5RS2Y2ZjcxZkNfSXFjIiwieSI6ImhzRk9lb0RvcmFJUHo3OXVDSERXTmhsbm5XZ3VIZk9sOEw3RnROUlM5cVUiLCJjcnYiOiJQLTI1NiJ9LCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..fbX7a7yaM3FprfHN5juiow.d6Ynb8fL2fcHMEOCcmj9DrJE1T02lU8FFLbLsOHLbKtJ6h26HxHBOnkJWPLWn9P8G9T4Sz49IboSiUpCRRbvYyb-NNLzEYIp4LzBdNQmFfgoUasE6ECtYZJk7NDBe1zwXGFAtmEVCdiGJlAsFsq9DiINKNvGpTQze7ks2d1DwToMjhQjVeNPGW5iBz0fpz_s8Q_CTs1RtnWjuUCjgriMV1sNrd-Ea6xVb5rW3FS99NvH6Xnu81Mu0wLMQFxkq4UFo_kc7XYQ8ToR0i902Ck6NQ.HkJMezu9E-_hbYbkGClfgLtdDobuqWLYFAxVAz1XDeQ"

root@edb8bbbd1def:/j/tests# /j/jwtc/rnbyc.new -t "$ntok" -K ec256.keys -P o256.jwks -H true -d
2023-06-29T05:25:19Z - rnbyc INFO: Starting rnbyc debug mode

r_jwe_decrypt_payload: jwe->key
14 FB 29 D7 C7 F7 7F 12  D9 9F D4 63 F6 98 F0 70
6E AD 6C B2 FE 7D EE F0  41 83 BB F9 87 E6 38 06
6A 83 2A 1A C9 6E DC 88  41 3D 20 BD 89 AA E7 2F
41 75 D9 E7 D7 19 BA 01  54 8F F7 0F A0 D5 A4 79
Token payload decrypted
Token signature verified
{
  "alg": "ECDH-ES",
  "cty": "JWT",
  "enc": "A256CBC-HS512",
  "epk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "xa59ZzoxYlxmtxTUynDiSiPzRbF3vnQKf6f71fC_Iqc",
    "y": "hsFOeoDoraIPz79uCHDWNhlnnWguHfOl8L7FtNRS9qU"
  },
  "kid": "ExUMY91J9atex-1Ai5vbu6qJ4aAGq0RMQxo__QyZV4k",
  "typ": "JWT"
}
{
  "alg": "HS256",
  "kid": "ii1wALxWmlADrDRtn7G0NQ",
  "typ": "JWT"
}
{
  "iat": 1516239022,
  "name": "JohnDoe",
  "sub": "[email protected]"
}

NOTE: the key is now correct

Cross verify with go-jose/jose-util:

root@9ac53b23f309:/tmp/jtests# ./jose-util decrypt --key ec256.keys --in jwe.new
DeriveECDHES:
00000000  14 fb 29 d7 c7 f7 7f 12  d9 9f d4 63 f6 98 f0 70  |..)........c...p|
00000010  6e ad 6c b2 fe 7d ee f0  41 83 bb f9 87 e6 38 06  |n.l..}..A.....8.|
00000020  6a 83 2a 1a c9 6e dc 88  41 3d 20 bd 89 aa e7 2f  |j.*..n..A= ..../|
00000030  41 75 d9 e7 d7 19 ba 01  54 8f f7 0f a0 d5 a4 79  |Au......T......y|

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImlpMXdBTHhXbWxBRHJEUnRuN0cwTlEifQ.eyJzdWIiOiJqZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkpvaG5Eb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.J96TAtD8CQo3tATeUGtKEdb1Pcz_p1Q1a0kFuoghQdg

Building with dependencies with non-standard PREFIX does not work

Compiling rhonabwy with dependencies installed in non-standard directories does not work.
The following script makes it possible to do so:

#!/bin/bash

SCRIPT_DIR=$(cd $(dirname $0); pwd)
BUILD_DIR=${SCRIPT_DIR}/build
INST_DIR=${SCRIPT_DIR}/inst
RHONABWY_SRC_DIR=${SCRIPT_DIR}/rhonabwy-0.9.9999

rm -rf "${BUILD_DIR}" "${INST_DIR}"
mkdir "${BUILD_DIR}" "${INST_DIR}"

cd "${BUILD_DIR}"
cmake \
    -DCMAKE_INSTALL_PREFIX="${INST_DIR}" \
    -DCMAKE_BUILD_TYPE=Release \
    -DDOWNLOAD_DEPENDENCIES=OFF \
    -DBUILD_RNBYC=ON\
    -DWITH_ULFIUS=OFF \
    -DPC_ORCANIA_INCLUDEDIR="${SCRIPT_DIR}/orcania-inst/include" \
    -DPC_ORCANIA_LIBDIR="${SCRIPT_DIR}/orcania-inst/lib64" \
    \
    -DPC_YDER_INCLUDEDIR="${SCRIPT_DIR}/yder-inst/include" \
    -DPC_YDER_LIBDIR="${SCRIPT_DIR}/yder-inst/lib64" \
    \
    -DPC_JANSSON_INCLUDEDIR="${SCRIPT_DIR}/jansson-inst/include" \
    -DPC_JANSSON_LIBDIR="${SCRIPT_DIR}/jansson-inst/lib" \
    \
    -DPC_GNUTLS_INCLUDEDIR="${SCRIPT_DIR}/gnutls-inst/include" \
    -DPC_GNUTLS_LIBDIR="${SCRIPT_DIR}/gnutls-inst/lib" \
    \
    -DZLIB_LIBRARY="${SCRIPT_DIR}/zlib-inst/lib/libz.so.1" \
    -DZLIB_INCLUDE_DIR="${SCRIPT_DIR}/zlib-inst/include" \
    \
    "${RHONABWY_SRC_DIR}"

# This makes building the library work
cat >> CMakeFiles/rhonabwy.dir/flags.make <<EOF
C_INCLUDES += -I${SCRIPT_DIR}/orcania-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/yder-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/nettle-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/gmp-inst/include
EOF

# This makes building the binary work
cat >> CMakeFiles/rnbyc.dir/flags.make <<EOF
C_INCLUDES += -I${SCRIPT_DIR}/orcania-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/yder-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/nettle-inst/include
C_INCLUDES += -I${SCRIPT_DIR}/gmp-inst/include
EOF

make
make install

All dependencies are compiled and installed in the same directory as the script.

maybe-uninitialized warning in r_jws_serialize

GCC9 raises a warning for an maybe uninitialized variable in r_jws_serialize (src/jws.c:268). The if/else branches are missing a default or adj is missing an initial value.

rhonabwy-src/src/jws.c: In function 'r_jws_serialize':
rhonabwy-src/src/jws.c:301:31: error: 'adj' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  301 |           s_out_padding = adj - s.size;
      |                           ~~~~^~~~~~~~
rhonabwy-src/src/jws.c:268:16: note: 'adj' was declared here
  268 |   unsigned int adj;
      |                ^~~

On a related topic, I'm not sure adjusting CFLAGS in the cmake scripts is idiomatic anymore, even to add -Wall -Werror flags (for example or this), though I don't have an opinion on that myself tbh.

[Windows] Compilation errors

  • Windows 10 x64
  • GCC 11.2.0
  • Master branch

C:/src/rhonabwy/src/jws.c: In function 'r_jws_set_properties':
C:/src/rhonabwy/src/jws.c:2138:3: error: unknown type name 'uint'; did you mean 'int'?
2138 | uint ui_value;
| ^~~~
| int

C:/src/rhonabwy/src/jwe.c:4369:3: error: unknown type name 'uint'; did you mean 'int'?
4369 | uint ui_value;
| ^~~~
| int

C:/src/rhonabwy/src/jwt.c:2083:3: error: unknown type name 'uint'; did you mean 'int'?
2083 | uint ui_value;
| ^~~~
| int

We should try, whenever possible, to write portable code!
We should also test as much as we can (on different platforms/architecture).

Thanks for this project anyway.

Pubkey not set but signature verification possible

Hello,
I have a problem (or rather a strange behavior) with the lib rhonabwy.

First, here is my code :

const char token[] = "eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9."                // header
                     "eyJleHBpcmF0aW9uRGF0ZSI6MTIzNDU2Nzg5MCwibXNnQ2hrQSI6MTIsIm1zZ0Noa0IiOjM0LCJ0b2tlblR5cGUiOiJTIn0."   // payload
                     "AOyZC-Jf2rt6BpSjzNHk0hyLBS96DpBWDol58gORVjTMpJNoU_ICE6ePLCBq24kW4CgN_XDV3cjtSl8CjG4HZ3zAAAAOForo1kNG5PjBzItBsf9AS5fq_E8DBi99o8xZvZBTqTunYLNXE048WG5r88AfnNLCnYCioiSIg47774r760Eu"; // signature

const unsigned char pubKey[] = "-----BEGIN PUBLIC KEY-----\n"
            "MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQBgc4HZz+/fBbC7lmEww0AO3NK9wVZ\n"
            "PDZ0VEnsaUFLEYpTzb90nITtJUcPUbvOsdZIZ1Q8fnbquAYgxXL5UgHMoywAib47\n"
            "6MkyyYgPk0BXZq3mq4zImTRNuaU9slj9TVJ3ScT3L1bXwVuPJDzpr5GOFpaj+WwM\n"
            "Al8G7CqwoJOsW7Kddns=\n"
            "-----END PUBLIC KEY-----\n";

const unsigned char privKey[] = "-----BEGIN PRIVATE KEY-----\n"
            "MIHuAgEAMBAGByqGSM49AgEGBSuBBAAjBIHWMIHTAgEBBEIBiyAa7aRHFDCh2qga\n"
            "9sTUGINE5jHAFnmM8xWeT/uni5I4tNqhV5Xx0pDrmCV9mbroFtfEa0XVfKuMAxxf\n"
            "Z6LM/yKhgYkDgYYABAGBzgdnP798FsLuWYTDDQA7c0r3BVk8NnRUSexpQUsRilPN\n"
            "v3SchO0lRw9Ru86x1khnVDx+duq4BiDFcvlSAcyjLACJvjvoyTLJiA+TQFdmrear\n"
            "jMiZNE25pT2yWP1NUndJxPcvVtfBW48kPOmvkY4WlqP5bAwCXwbsKrCgk6xbsp12\n"
            "ew==\n"
            "-----END PRIVATE KEY-----\n";

jwt_t * jwt;

r_global_init();
r_jwt_init(&jwt);

r_jwt_add_sign_keys_pem_der(jwt, R_FORMAT_PEM, privKey, sizeof(privKey), pubKey, sizeof(pubKey));
r_jwt_advanced_parse(jwt, token,R_PARSE_NONE, R_FLAG_IGNORE_SERVER_CERTIFICATE);
r_jwt_set_sign_alg(jwt, R_JWA_ALG_ES512);
printf("PRIV : %s\n", r_jwks_export_to_json_str(jwt->jwks_privkey_sign, 0));
printf("PUB : %s\n", r_jwks_export_to_json_str(jwt->jwks_pubkey_sign, 0));

r_jwt_parse(jwt, token, 0);
r_jwt_verify_signature(jwt, NULL, 0);

printf("CLAIM = %s\n", r_jwt_get_full_claims_str(jwt));

And here is an execution result :

PRIV : {"keys":[{"kty":"EC","x":"AYHOB2c_v3wWwu5ZhMMNADtzSvcFWTw2dFRJ7GlBSxGKU82_dJyE7SVHD1G7zrHWSGdUPH526rgGIMVy-VIBzKMs","y":"ib476MkyyYgPk0BXZq3mq4zImTRNuaU9slj9TVJ3ScT3L1bXwVuPJDzpr5GOFpaj-WwMAl8G7CqwoJOsW7Kddns","d":"AYsgGu2kRxQwodqoGvbE1BiDROYxwBZ5jPMVnk_7p4uSOLTaoVeV8dKQ65glfZm66BbXxGtF1XyrjAMcX2eizP8i","crv":"P-521","kid":"CatmrLCuBa_kI3VMfembQnugtVauN35XuHIRRGZuXzY"}]}
PUB : {"keys":[]}
CLAIM = {"expirationDate":1234567890,"msgChkA":12,"msgChkB":34,"tokenType":"S"}

As you can see, apparently my public key was not set correctly but my token signature was verifiy.

Do you have an explanation please?

Thanks in advance

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.