cisco / cjose Goto Github PK
View Code? Open in Web Editor NEWC library implementing the Javascript Object Signing and Encryption (JOSE)
License: MIT License
C library implementing the Javascript Object Signing and Encryption (JOSE)
License: MIT License
In header.h, globals variables are called the following way:
extern const char *CJOSE_HDR_ALG;
In Visual C++, there's no way to have that declaration included in a third-party application, even by providing a DEF file. All exported variables have to be declared with
extern __declspec(dllimport)
.
Proposal, compatible with Visual C++ and others:
#ifdef _MSC_VER
# ifdef CJOSE_BUILD
# define EXTERN extern __declspec(dllexport)
# else
# define EXTERN extern __declspec(dllimport)
# endif
#else
# define EXTERN extern
#endif
EXTERN const char *CJOSE_HDR_ALG;
what's up with this line:
https://github.com/cisco/cjose/blob/master/src/jws.c#L827
static bool _cjose_jws_verify_sig_rs256(
cjose_jws_t *jws,
const cjose_jwk_t *jwk,
cjose_err *err)
{
return true;
...
Hi,
Can the project load JWK from RSA PEM format?
Thank you.
Most memory leak detectors redefine the "free" function (and others).
The struct _key_fntable_int contains the following:
void (*free)(cjose_jwk_t *);
This clashes with a redefintion of "free".
Is it possible to rename this field (like "free_func")?
Thanks
Hello.
Is there any plans for X.509 support?
Any proposed structures and names for the corresponding JWK keys?
Thank you
Hello,
plainText = "test"
....
static const char *JWK_RSA
= "{ \"kty\": \"RSA\", "
"\"e\": \"AQAB\", "
"\"n\": "
"\"wsqJbopx18NQFYLYOq4ZeMSE89yGiEankUpf25yV8QqroKUGrASj_OeqTWUjwPGKTN1vGFFuHYxiJeAUQH2qQPmg9Oqk6-"
"ATBEKn9COKYniQ5459UxCwmZA2RL6ufhrNyq0JF3GfXkjLDBfhU9zJJEOhknsA0L_c-X4AI3d_NbFdMqxNe1V_"
"UWAlLcbKdwO6iC9fAvwUmDQxgy6R0DC1CMouQpenMRcALaSHar1cm4K-syoNobv3HEuqgZ3s6-hOOSqauqAO0GUozPpaIA7OeruyRl5sTWT0r-"
"iz39bchID2bIKtcqLiFcSYPLBcxmsaQCqRlGhmv6stjTCLV1yT9w\", "
"\"kid\": \"ff3c5c96-392e-46ef-a839-6ff16027af78\", "
"\"d\": "
"\"b9hXfQ8lOtw8mX1dpqPcoElGhbczz_-xq2znCXQpbBPSZBUddZvchRSH5pSSKPEHlgb3CSGIdpLqsBCv0C_XmCM9ViN8uqsYgDO9uCLIDK5plWttbkqA_"
"EufvW03R9UgIKWmOL3W4g4t-"
"C2mBb8aByaGGVNjLnlb6i186uBsPGkvaeLHbQcRQKAvhOUTeNiyiiCbUGJwCm4avMiZrsz1r81Y1Z5izo0ERxdZymxM3FRZ9vjTB-"
"6DtitvTXXnaAm1JTu6TIpj38u2mnNLkGMbflOpgelMNKBZVxSmfobIbFN8CHVc1UqLK2ElsZ9RCQANgkMHlMkOMj-XT0wHa3VBUQ\", "
"\"p\": "
"\"8mgriveKJAp1S7SHqirQAfZafxVuAK_A2QBYPsAUhikfBOvN0HtZjgurPXSJSdgR8KbWV7ZjdJM_eOivIb_XiuAaUdIOXbLRet7t9a_"
"NJtmX9iybhoa9VOJFMBq_rbnbbte2kq0-FnXmv3cukbC2LaEw3aEcDgyURLCgWFqt7M0\", "
"\"q\": "
"\"zbbTv5421GowOfKVEuVoA35CEWgl8mdasnEZac2LWxMwKExikKU5LLacLQlcOt7A6n1ZGUC2wyH8mstO5tV34Eug3fnNrbnxFUEE_ZB_njs_"
"rtZnwz57AoUXOXVnd194seIZF9PjdzZcuwXwXbrZ2RSVW8if_ZH5OVYEM1EsA9M\", "
"\"dp\": "
"\"1BaIYmIKn1X3InGlcSFcNRtSOnaJdFhRpotCqkRssKUx2qBlxs7ln_5dqLtZkx5VM_UE_GE7yzc6BZOwBxtOftdsr8HVh-14ksSR9rAGEsO2zVBiEuW4qZf_"
"aQM-ScWfU--wcczZ0dT-Ou8P87Bk9K9fjcn0PeaLoz3WTPepzNE\", "
"\"dq\": "
"\"kYw2u4_UmWvcXVOeV_VKJ5aQZkJ6_sxTpodRBMPyQmkMHKcW4eKU1mcJju_"
"deqWadw5jGPPpm5yTXm5UkAwfOeookoWpGa7CvVf4kPNI6Aphn3GBjunJHNpPuU6w-wvomGsxd-NqQDGNYKHuFFMcyXO_zWXglQdP_1o1tJ1M-BM\", "
"\"qi\": "
"\"j94Ens784M8zsfwWoJhYq9prcSZOGgNbtFWQZO8HP8pcNM9ls7YA4snTtAS_"
"B4peWWFAFZ0LSKPCxAvJnrq69ocmEKEk7ss1Jo062f9pLTQ6cnhMjev3IqLocIFt5Vbsg_PWYpFSR7re6FRbF9EYOM7F2-HRv1idxKCWoyQfBqk\" }";
cjose_err err;
cjose_jwk_t *jwk = cjose_jwk_import(JWK_RSA, strlen(JWK_RSA), &err);
// set header for JWE
cjose_header_t *hdr = cjose_header_new(&err);
cjose_header_set(hdr, CJOSE_HDR_ALG, CJOSE_HDR_ALG_RSA_OAEP, &err);
cjose_header_set(hdr, CJOSE_HDR_ENC, CJOSE_HDR_ENC_A256GCM, &err);
// create the JWE
size_t plain1_len = strlen(plainText);
cjose_jwe_t *jwe1 = cjose_jwe_encrypt(jwk, hdr, (const uint8_t *)plainText, plain1_len, &err);
// get the compact serialization of JWE
char *compact = cjose_jwe_export(jwe1, &err);
printf("compact %s", compact);
//cjose_get_dealloc()(plain2);
cjose_header_release(hdr);
cjose_jwe_release(jwe1);
//cjose_jwe_release(jwe2);
cjose_jwk_release(jwk);
//cjose_get_dealloc()(compact);
This code print the result:
eyJhbGciOiAiUlNBLU9BRVAiLCAiZW5jIjogIkEyNTZHQ00ifQ.vKVHv3OdkAoCImJIo9lHHrAiEaUhJurtqeqRv-53OFrUwovqvvpgIWuq-1mhIsxadGgyOqgFHZK9SBNwes8ilCL4QeW3T2UqGdv02SWjBWxopr3qgeR56RvLQNQvncW74hM142WKUmqKxamNREAxG6i19X6oEAVqoYzqdPP3L91jRFPIY-qrm2am3n_yg2RPQxSimj6zNMf-Gr9SLI0WlfR00IwLx1gyVujUDs8KMp8FpqFppsLLBx-j52-q6Wi9uKzEsJW_0hBRWtZSKKmDBvOuB8138AkTfy7Q9AOOQOoXmHwQfzHbNzdNcmxyExy8TCZF2PbNxnJWKyf0BzK8qg.5h6eNxL4t1sH73R9.t8g0zw.JQ8ucCXXJRKeLywlqesDIQ
When i do a base64URl for the header part :
eyJhbGciOiAiUlNBLU9BRVAiLCAiZW5jIjogIkEyNTZHQ00ifQ
I am getting this result:
{"alg": "RSA-OAEP", "enc": "A256GCM"}
Why i am not getting the right header? with the kid part:
{"kid":"ff3c5c96-392e-46ef-a839-6ff16027af78","alg":"RSA-OAEP","enc":"A256GCM"}
Hi,
It's great library!
automake version: 1.14
autoconf version: 2.69
Execute autoreconf --force --install have warning message:
configure.ac:9: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
(See also 8693c22#commitcomment-27669403)
Hi there,
Since
- compile with LibreSSL (8693c22aabf31313a4002838e124e93879bbb50b)
building with newer GCC (and Clang supposedly) produces:
util.c: In function 'cjose_apply_allocs':
util.c:53:36: error: this use of "defined" may not be portable [-Werror=expansion-to-defined]
#if (CJOSE_OPENSSL_11X)
^~~~~~~~~~~~~~~~~
(Probably due to this patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00738.html)
Maybe there is a way to restructure this macros.
Regards,
Moritz
Been trying to use this library to install mod_auth_openidc since this software is a dependency for it, all runnning well untill I tried to run 'make', I got this error
clang: warning: /usr/local/opt/cjose/include: 'linker' input unused
In file included from src/mod_auth_openidc.c:74:
In file included from src/mod_auth_openidc.h:60:
In file included from src/jose.h:64:
In file included from /usr/local/include/cjose/cjose.h:26:
/usr/local/include/cjose/jwk.h:20:10: fatal error: 'openssl/obj_mac.h' file not found
#include <openssl/obj_mac.h>
^
1 error generated.
apxs:Error: Command failed with rc=65536
.
make: *** [src/mod_auth_openidc.la] Error 1
Below is my environment setup
*note that all software is installed using Brew (don't know if it will be matter just put some informations together)
Below is my ./configure setup on mod_auth_openidc
erudianto$ CJOSE_CFLAGS=/usr/local/opt/cjose/include CJOSE_LIBS=/usr/local/opt/cjose/lib ./configure --with-apxs2=/Users/erudianto/Downloads/apache-server/dist/bin/apxs --prefix /Users/erudianto/Downloads/mod_auth_openidc-2.1.3/dist
Attempts to decrypt the JWE:
eyJhbGciOiJBMjU2S1ciLCJraWQiOiIzYmJhNTkxMC04MzZmLTRjOTYtYjE0My0xNWM0MTkzNTRjNDAiLCJlbmMiOiJBMjU2R0NNIn0.-rqxPUoKNyVTBumul_8dLhK2uVhPRd-l55Xw6No8Fo8wN9wreuQg_g.2ZH9Jxx8tEZ7Dzdz.v2ESxQ.wKR8Ms6EI_st6Pzz424O-w
Using JWK:
{
"kty" : "oct",
"k" : "7SOtIzBXT6MJHRG79G7r3FiIOlNa_tuJX00IzLeYRYY"
}
Results in a crash here:
https://github.com/cisco/cjose/blob/master/src/jwe.c#L385
The combined use of alg=A256KW and enc=A256GCM appears to lead to the dereferencing of an invalid pointer (the jwk pointer above has value "1")
The tests test_cjose_concatkdf_derive_*
fail on big endian architectures like s390x, powerpc, ppc64, sparc64, ...:
check_concatkdf.c:159:F:concatkdf:test_cjose_concatkdf_derive_simple:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566eb950
check_concatkdf.c:190:F:concatkdf:test_cjose_concatkdf_derive_ikm:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566ebb80
check_concatkdf.c:224:F:concatkdf:test_cjose_concatkdf_derive_moreinfo:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566ebd50
Maybe this is something similar to #38 where some bad casts were the source of the problem that go unnoticed on little endian, but make it fail on big endian.
However, I did not find something at a quick glance (except from the fact that &err
gets used in both function calls there, is not nulled inbetween and is not checked - maybe that would help debugging).
Lines 149 to 150 in 1250eff
More details and complete build logs can be found on the respective Debian Buildd page:
https://buildd.debian.org/status/package.php?p=cjose
There is also a Debian bug report tracking the issue:
https://bugs.debian.org/890907
Please remove platform/debian/qemu-arm-static from the git archive or the release tar.gz .
A binary file should not be in a source archive.
If someone wants to use the armhf docker file, he/she should supply the qemu binary.
CONTRIBUTING indicates that before submitting, clang-format must be run (specifically 3.9), but many of the files do not appear to be consistent with clang-format currently. Is clang-format still required and does it require specifically 3.9 (the current version is 8)? I believe this will generate a large number of unrelated changes.
As is available here: https://www.npmjs.com/package/jose
because of:
https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-04
I'm trying to build cjose using --with-jansson
, but no matter what value I pass I keep getting:
Invalid configuration /opt/sbox/rcampbell/jansson/install: machine /opt/sbox/rcampbell/jansson/install not recognized
(quotes removed to avoid breaking the markdown).
I'm building inside a CentOS v6.5 container using this command line:
CC=/opt/soldev/toolchains/v1/targets/centos7-i686/bin/i686-target-linux-gnu-gcc ./configure --with-jansson /opt/sbox/rcampbell/jansson/install
Before trying the build, I built jansson with CC=/opt/soldev/toolchains/v1/targets/centos7-i686/bin/i686-target-linux-gnu-gcc ./configure --prefix=/opt/sbox/rcampbell/jansson/install
.
I've tried passing the "install" directory, or the "lib" directory and even the name of files inside the lib directory, but I keep getting the same error. Is it expecting the install directory name to be formatted in a specific way?
As I'm going through the code, I also realized that there can be a problem with the sequence of encryption and serialization.
If there is only one recipient, and both protected and unprotected headers are given, then the compact serialization must join the headers into common headers, and use that as protected header values. However, JSON serialization must maintain the headers separately. Since the protected headers are used as part of the AAD, we can't decide which actual keys to authenticate, if it's not known what serialization is to be used. There are few solutions here, please let me know which one you would rather have:
Thank you.
Hi @linuxwolf ,
I'm having problems with encryption A128GCM.
Is it supported Algorithm A128GCM for this library?
thank you,
Regards!
Steps to reproduce:
call cjose_jwe_import
with a JWE compact serialization that does not include the encrypted key portion (ie, [something]..[something].[something].[something]
)
expected behavior: cjose
creates a _cjose_jwe_int
with an empty _cjose_jwe_part_int
in the second position of the JWE part array
actual behavior: cjose
returns null
and gives a CJOSE_ERR_INVALID_ARG
error.
notes:
alg is ECDH-ES
enc is A256GCM
in jwe.c, on line 1952:
cek = cjose_get_alloc()(cek_len);
memcpy(cek, jwe->cek, cek_len);
Allocation result is not checked. We should add
if (!cek) {
CJOSE_ERROR(err, CJOSE_ERR_NO_MEMORY);
return NULL;
}
In File cjose/src/base64.c
In function
static inline bool _decode(const char *input, size_t inlen, uint8_t **output, size_t *outlen, bool url, cjose_err *err)
Line 78:
uint8_t *buffer = cjose_get_alloc()(sizeof(uint8_t) * rlen);
Fix:
memset(buffer, 0, sizeof(uint8_t) * rlen);
Symptoms:
I am using function
jws = cjose_jws_import(access_token, strlen(access_token), err);
to get the jws object and then to get the plaintext version i am using
cjose_jws_get_plaintext(jws, &plaintext, &plaintext_len, err)
However, when i see the plaintext version, it has extra garbage characters in the end after the termination of the JSON
i am using the JSON parse to get the values, C function is
e = cl_json_parse(a_token, &json_top);
It is throwing error because of the corrupted plaintext field (extra garbage character), as i can't change the source code of cjose, workaround is parse from the end till i get the closing } brace to get the final length.
One weird thing is "first time when i decode the string then the JSON plaintext looks ok, its subsequent time when the garbage characters shows up" not sure if it is due to the alloc function.
Please memset the buffer to 0 before using it.
In jwe.c, _cjose_jwe_set_iv_aes_cbc
creates different sized IVs depending on the key size. This doesn't seem correct; the CBC IV is based on the block size, which is always 16 bytes for AES, not the key size. I can't find a specific example in RFC7516 of AES256 to confirm my understanding; have I misunderstood something about the spec?
Looks like the use of ck_assert_uint_eq
would require at least check-devel 0.10.0: libcheck/check@305371c
RHEL 7 version of check is 0.9.9
Error:
DEBUG util.py:490: BUILDSTDERR: check_cjose-check_concatkdf.o: In function `test_cjose_concatkdf_otherinfo_noextra':
DEBUG util.py:490: BUILDSTDERR: /builddir/build/BUILD/cjose-0.6.1/test/check_concatkdf.c:98: undefined reference to `ck_assert_uint_eq'
DEBUG util.py:490: BUILDSTDERR: check_cjose-check_concatkdf.o: In function `test_cjose_concatkdf_otherinfo_apuapv':
DEBUG util.py:490: BUILDSTDERR: /builddir/build/BUILD/cjose-0.6.1/test/check_concatkdf.c:123: undefined reference to `ck_assert_uint_eq'
DEBUG util.py:490: BUILDSTDERR: collect2: error: ld returned 1 exit status
When setting a custom memory allocator and deallocator using
Line 60 in 9261231
Lines 54 to 65 in 254ab05
json_dumps
allocatos hdr_str
using the custom allocator. However later hdr_str
is freed using free
and not the set deallocator. So this (can) lead to a segfault.
I suggest to replace the calls to free
with cjose_get_dealloc()
cjose-0.6.1 encountered the following error when running “gamke” on solaris 11.3. I would like to ask “Can cjose be installed successfully on solaris 11.3?”and“If solaris 11.3 was supported, can you suggest a solution for the following error?“ Thanks
Error message:
Making check in doc
Making check in platform
Making check in centos
make: Fatal error in reader: Makefile, line 270: Unexpected end of line seen
Current working directory /root/cjose-latest/platform/centos
*** Error code 1
The following command caused the error:
fail=;
if (target_option=k; case ${target_option-} in ?) ;; ) echo "am__make_running_with_option: internal error: invalid" "target option '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; sane_makeflags=$MAKEFLAGS; if { if test -z '1'; then false; elif test -n ''; then true; elif test -n '' && test -n ''; then true; else false; fi; }; then sane_makeflags=$MFLAGS; else case $MAKEFLAGS in \[\ \ ]) bs=\; sane_makeflags=printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs ]*//g"
;; esac; fi; skip_next=no; strip_trailopt () { flg=printf '%s\n' "$flg" | sed "s/$1.*$//"
; }; for flg in $sane_makeflags; do test $skip_next = yes && { skip_next=no; continue; }; case $flg in =|--) continue;; -I) strip_trailopt 'I'; skip_next=yes;; -I?) strip_trailopt 'I';; -O) strip_trailopt 'O'; skip_next=yes;; -O?) strip_trailopt 'O';; -l) strip_trailopt 'l'; skip_next=yes;; -l?) strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; esac; case $flg in $target_option) has_opt=yes; break;; esac; done; test $has_opt = yes); then
failcom='fail=yes';
else
failcom='exit 1';
fi;
dot_seen=no;
target=echo check-recursive | sed s/-recursive//
;
case "check-recursive" in
distclean- | maintainer-clean-) list='centos debian' ;;
) list='centos debian' ;;
esac;
for subdir in $list; do
echo "Making $target in $subdir";
if test "$subdir" = "."; then
dot_seen=yes;
local_target="$target-am";
else
local_target="$target";
fi;
(CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target)
|| eval $failcom;
done;
if test "$dot_seen" = "no"; then
make "$target-am" || exit 1;
fi; test -z "$fail"
make: Fatal error: Command failed for target check-recursive' Current working directory /root/cjose-latest/platform *** Error code 1 The following command caused the error: fail=; \ if (target_option=k; case ${target_option-} in ?) ;; *) echo "am__make_running_with_option: internal error: invalid" "target option '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; sane_makeflags=$MAKEFLAGS; if { if test -z ''; then false; elif test -n ''; then true; elif test -n '' && test -n ''; then true; else false; fi; }; then sane_makeflags=$MFLAGS; else case $MAKEFLAGS in *\\[\ \ ]*) bs=\\; sane_makeflags=
printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs ]//g";; esac; fi; skip_next=no; strip_trailopt () { flg=
printf '%s\n' "$flg" | sed "s/$1.$//"; }; for flg in $sane_makeflags; do test $skip_next = yes && { skip_next=no; continue; }; case $flg in *=*|--*) continue;; -*I) strip_trailopt 'I'; skip_next=yes;; -*I?*) strip_trailopt 'I';; -*O) strip_trailopt 'O'; skip_next=yes;; -*O?*) strip_trailopt 'O';; -*l) strip_trailopt 'l'; skip_next=yes;; -*l?*) strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; esac; case $flg in *$target_option*) has_opt=yes; break;; esac; done; test $has_opt = yes); then \ failcom='fail=yes'; \ else \ failcom='exit 1'; \ fi; \ dot_seen=no; \ target=
echo check-recursive | sed s/-recursive//; \ case "check-recursive" in \ distclean-* | maintainer-clean-*) list='. include src test doc platform' ;; \ *) list='. include src test doc platform' ;; \ esac; \ for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target
check-recursive'
I'd like to request for a new release that includes #40 and #33 .
Since #33 changes the behavior of the API I believe it deserves more than a minor number bump. (I could actually see 1.0.0 coming out...)
I hope this will then propagate to e.g. https://anonscm.debian.org/git/collab-maint/cjose.git/ and http://rpmfind.net/linux/rpm2html/search.php?query=pkgconfig(cjose) so that packages dependent on libcjose (such as https://github.com/pingidentity/mod_auth_openidc) can then refer to it.
as far as I understand:
https://github.com/cisco/cjose/blob/master/src/version.c#L12
should read:
return JOSE_VERSION;
instead of:
return VERSION;
since the former is generated by:
https://github.com/cisco/cjose/blob/master/include/cjose/version.h.in#L25
#define CJOSE_VERSION "@PACKAGE_VERSION@"
which also makes the testing slightly more relevant at:
https://github.com/cisco/cjose/blob/master/test/check_version.c#L21
START_TEST (test_cjose_version_fn)
{
const char *version = cjose_version();
ck_assert_str_eq(version, VERSION);
}
END_TEST
as VERSION
is obtained from the compiler settings if I'm correct; I may misunderstand what the intent of it is though
All the concatkdf unit tests will fail on big endian architectures. The failure occurs because one of the operations requires generating a 32-bit integer in big endian format as a length specifier. The code correctly used htonl() to produce the 32-bit big endian integer but then tried to further manipulate the result with bit shifting and octet indexing which was unnecessary. The bit shifting and octet indexing only worked on little endian architectures.
I will be submitting a pull request momentarily that fixes the issue, the commit comment tries to explain why the mistake occurred.
I am using the cjose library to create a JWT which will be used while exchanging information with a third-party client.
I found that sometimes, the library returns the below error:
JWT library error: invalid argument in file:jwe.c and func:_cjose_jwe_set_cek_aes_cbc
and line:448
This happens on my call to cjose_jwe_encrypt(jwk, header, (uint8_t*)compact_jws, comp_jws_len, &err);
I traced down the problem, and what I found was the value returned from cjose_base64url_decode() sometimes changes i.e. the output string value returned changes randomly, even though the provided input and inlen remains the same.
I cannot find any reason for this return value to vary even though the input remains constant.
Would it be possible to provide a fix for this or a workaround?
Version: 0.4.1
If configured with jansson and/or openssl, there is a '-Lyes/lib' LD_FLAG that is added, that freaks out the libtool.
[vps@phoenix]~/src/cjose$ ./configure --prefix=/opt/soft/cjose --exec-prefix=/opt/soft/cjose
...
[vps@phoenix]~/src/cjose$ make -j
... <all OK> ...
[vps@phoenix]~/src/cjose$ ./configure --prefix=/opt/soft/cjose --exec-prefix=/opt/soft/cjose --with-jansson --with-openssl
...
[vps@phoenix]~/src/cjose$ make -j
...
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 --pedantic -Wall -Werror -g -O2 -I../include -g -O2 -Iyes/include/ -Iyes/include/ -lm -Lyes/lib -Lyes/lib -o libcjose.la -rpath /opt/soft/cjose/lib libcjose_la-version.lo libcjose_la-util.lo libcjose_la-base64.lo libcjose_la-jwk.lo libcjose_la-jwe.lo libcjose_la-jws.lo libcjose_la-header.lo libcjose_la-error.lo -ljansson -lcrypto
../libtool: line 7472: cd: yes/lib: No such file or directory
libtool: error: cannot determine absolute directory name of 'yes/lib'
Makefile:438: recipe for target 'libcjose.la' failed
[vps@phoenix]~/src/cjose$ grep 'yes/lib' * 2>/dev/null
config.log:configure:14829: gcc -o conftest -g -O2 -Iyes/include/ -Iyes/include/ -Lyes/lib conftest.c -lcrypto >&5
config.log:configure:14911: gcc -o conftest -g -O2 -Iyes/include/ -Iyes/include/ -Iyes/include/ -Iyes/include/ -Lyes/lib -Lyes/lib conftest.c -ljansson -lcrypto >&5
config.log:LDFLAGS=' -Lyes/lib -Lyes/lib'
config.status:S["LDFLAGS"]=" -Lyes/lib -Lyes/lib"
Makefile:LDFLAGS = -Lyes/lib -Lyes/lib
The current implementation of cjose_jws_verify
releases the allocated JWS resources when the verification fails for some reason, see e.g.: https://github.com/cisco/cjose/blob/master/src/jws.c#L1169
Firstly I've found this to be counter-intuitive from a developer perspective.
Secondly it makes the calling code having to differentiate between error paths and successful paths wrt. releasing resources.
Thirdly, it makes it impossible to call cjose_jws_verify
in a loop for a number of keys e.g. in scenario's where no kid
is presented in the JWS header but a number of verification keys have been pre-configured.
Hi all,
I would like to know the current status of this project, maintenance-wise.
would you please provide some info in this regard.
Regards,
I noticed that if I call cjose_jws_verify a second time, memory is leaked.
==5109== 32 bytes in 1 blocks are definitely lost in loss record 183 of 280
==5109== at 0x4C29F13: malloc (vg_replace_malloc.c:299)
==5109== by 0x546C0C7: _cjose_jws_build_dig_sha (jws.c:176)
==5109== by 0x546D962: cjose_jws_verify (jws.c:1052)
Is this known / expected? and should the application always discard JWS before a second attempt to verify the JWS?
Guys, can you add documentation section how to compile lib for iOS?
While building cjose for Debian the test on s390x fails:
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_short:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_empty:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_many:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
I don't see a memory problem.
Could you please consider replacement of openssl with libressl? Or fork of the project which would use libressl? Both libraries cannot be installed at the same time and I am kind of stuck with apache httpd built with libre.
Hello.
I see that cjose_jwe_encrypt
copies kid
value from the key into the headers of the JWE object itself. It doesn't seem to be needed. Though JWS RFC says that the kid
must match the one from the key, JWE RFC doesn't have such language.
This pull request is as relevant today as it was in 2016 when the author submitted it. It seems many other current github.com/cisco projects are using CMake now, and it would be preferable for many users. It doesn't look like anyone has even given any response to the author at all to the PR, as is the case for 5 other open PRs. Any response at all would be helpful to community users.
Hi @linuxwolf ,
I'm having problems with encryption A128GCM.
Is it supported Algorithm A128GCM for this library?
thank you,
Regards!
Our project is using the cjose library. When running valgrind for our project, we found a definitely loss issue in cjose. We check our codes and make sure that the memory of cjose_jws_t is released by calling method cjose_jws_release. So I wonder if the memory of jws->dig is leaked in in some cases. Could you please help check this problem?
Valgrind logs
==26157== 32 bytes in 1 blocks are definitely lost in loss record 15 of 61
==26157== at 0x40272B2: malloc (vg_replace_malloc.c:270)
==26157== by 0x88D4C4D: _cjose_jws_build_dig_sha (jws.c:218)
==26157== by 0x88D35BE: cjose_jws_verify (jws.c:1159)
==26157== by 0x88CA701: wbx_ci_self_contained_token_validate::TokenValidateSig::VerifyByKey(std::string const&, _cjose_jws_int*) (token_validate_sig.cpp:87)
Hello,
I think the project is currently only meant for Mac and Linux distros. Is there a plan to include Windows in the mix ?
Following up on #60, I'm trying to understand how to derive an ECDH-ES key. I had thought that it was with cjose_jwk_derive_ecdh_ephemeral_key
, but that seems to be a different HKDF algorithm. If I have a jwe, an apv, a private key and a public key, what can I call to fetch the derived shared secret?
I believe the thing I'm looking for is derived
that's computed by _cjose_jwe_decrypt_ek_ecdh_es
.
Calling cjose_jwe_decrypt_multi
, and not having any keys match, causes a SEGV, as an attempt to decrypt with null
CEK is attempted
otherwise somebody should pick it up in a fork
Hi ,
I'm having problems with the encryption function.
Is it supported input the AAD when call cjose_jwe_encrypt function?
thank you,
Regards!
Hello.
So far, CJose only supports "protected" headers. This is true for both JWS and JWE, but I'd like to focus on JWE only for now.
To support multiple recipients, however, unprotected headers are necessary.
I can't find any clear guidelines on which keys can be in either protected or unprotected headers. There are some examples, but they seem to be non-binding.
So, for using the header values, for building up the keys and such, I believe I need to provide all of the 3 headers:
So, for example, the code that determines the key algorithms, encryption algorithm, and etc., need to get the information it needs. I'm a also a bit puzzled on the order. Looks like "protected" header should be the first choice (because it's protected) before falling back onto the unprotected ones, but that doesn't make sense, because per recipient obviously has higher specificity.
To recap:
Thank you.
I see cjose_jws_sign
does a lot of checks on the input, and returns an error, but if there is no alg
field set in CJOSE
, then the code SIGSEGV
on strcmp
ing the alg with various values...
make give me this error message:
...
/usr/bin/ld: /usr/lib/gcc/x86_64-amazon-linux/4.8.3/../../../../lib64/libjansson.a(dump.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-amazon-linux/4.8.3/../../../../lib64/libjansson.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[1]: *** [libcjose.la] Error 1
Any idea how to fix it?
CJOSE does not currently support any ECDH algroriths, which hinders some use cases.
To start, at least direct key agreement ("ECDH-ES") should be supported.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.