latchset / jose Goto Github PK
View Code? Open in Web Editor NEWC-language implementation of Javascript Object Signing and Encryption
License: Apache License 2.0
C-language implementation of Javascript Object Signing and Encryption
License: Apache License 2.0
make check is failing on Travis, see https://travis-ci.org/tiran/pyjose/builds/164060691 . OpenSSLs test suite is passing.
==============================
jose 4: ./test-suite.log
==============================
# TOTAL: 6
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 5
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tests/rfc7515_A
=====================
+trap exit ERR
trap: ERR: bad trap
+prfx=./tests/vectors/rfc7515_A
+cmd/jose ver -i ./tests/vectors/rfc7515_A.1.jwsc -k ./tests/vectors/rfc7515_A.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.2.jwsc -k ./tests/vectors/rfc7515_A.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.3.jwsc -k ./tests/vectors/rfc7515_A.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.4.jwsc -k ./tests/vectors/rfc7515_A.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk ./tests/vectors/rfc7515_A.6.2.jwk
No signatures validated!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.jwkset -k ./tests/vectors/rfc7515_A.1.jwk
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk -k ./tests/vectors/rfc7515_A.6.2.jwk
Signature validation failed!
+cmd/jose ver -a -i ./tests/vectors/rfc7515_A.6.jwsg -k ./tests/vectors/rfc7515_A.6.1.jwk -k ./tests/vectors/rfc7515_A.6.2.jwk -k ./tests/vectors/rfc7515_A.1.jwk
Signature validation failed!
+cmd/jose ver -i ./tests/vectors/rfc7515_A.7.jwsf -k ./tests/vectors/rfc7515_A.7.jwk
No signatures validated!
FAIL tests/rfc7515_A (exit status: 1)
FAIL: tests/rfc7520_4
=====================
+trap exit ERR
trap: ERR: bad trap
+prfx=./tests/vectors/rfc7520_4
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsc -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsf -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.1.jwsg -k ./tests/vectors/rfc7520_4.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsc -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsf -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.2.jwsg -k ./tests/vectors/rfc7520_4.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsc -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsf -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.3.jwsg -k ./tests/vectors/rfc7520_4.3.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsc -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsf -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.4.jwsg -k ./tests/vectors/rfc7520_4.4.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsc -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsf -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.5.jwsg -d ./tests/vectors/rfc7520_4.5.payl -k ./tests/vectors/rfc7520_4.5.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsc -k ./tests/vectors/rfc7520_4.6.jwk
Invalid JWS!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsf -k ./tests/vectors/rfc7520_4.6.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.6.jwsg -k ./tests/vectors/rfc7520_4.6.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsc -k ./tests/vectors/rfc7520_4.7.jwk
Invalid JWS!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsf -k ./tests/vectors/rfc7520_4.7.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.7.jwsg -k ./tests/vectors/rfc7520_4.7.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.jwkset
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.1.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.2.jwk
No signatures validated!
+cmd/jose ver -i ./tests/vectors/rfc7520_4.8.jwsg -k ./tests/vectors/rfc7520_4.8.3.jwk
No signatures validated!
FAIL tests/rfc7520_4 (exit status: 1)
FAIL: tests/rfc7520_5
=====================
+prfx=tests/vectors/rfc7520_5
+cmd/jose dec -i tests/vectors/rfc7520_5.1.jwec -k tests/vectors/rfc7520_5.1.jwk
Decryption failed!
+cat tests/vectors/rfc7520_5.1.pt
+test == You can trust us to stick with you through thick and thin–to the bitter end. And you can trust us to keep any secret of yours–closer than you keep it yourself. But you cannot trust us to let you face trouble alone, and go off without a word. We are your friends, Frodo.
./tests/rfc7520_5: 5: test: unexpected operator
FAIL tests/rfc7520_5 (exit status: 2)
FAIL: tests/rfc7638
===================
+trap exit ERR
trap: ERR: bad trap
+cmd/jose thp -i tests/vectors/rfc7638_3.1.jwk -H sha256
Unsupported hash function!
jose pub -i JWK(Set) [-o JWK(Set)]
Calculates the JWK thumbprint.
-i FILE, --jwk=FILE JWK or JWKSet input (file)
-i -, --jwk=- JWK or JWKSet input (stdin)
-H sha1, --hash=sha1 Use SHA1 as the hash function
-H sha224, --hash=sha224 Use SHA224 as the hash function
-H sha256, --hash=sha256 Use SHA256 as the hash function
-H sha384, --hash=sha384 Use SHA384 as the hash function
-H sha512, --hash=sha512 Use SHA512 as the hash function
-o FILE, --output=FILE JWK or JWKSet output (file)
-o -, --output=- JWK or JWKSet output (stdout; default)
+cat tests/vectors/rfc7638_3.1.thp
+test == NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
./tests/rfc7638: 5: test: unexpected operator
FAIL tests/rfc7638 (exit status: 2)
FAIL: tests/jose
================
+ASIGN=RS256 RS384 RS512 ES256 ES384 ES512 PS256 PS384 PS512
+SSIGN=HS256 HS384 HS512
+AWRAP=ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW RSA1_5
+SWRAP=A128KW A192KW A256KW A128GCMKW A192GCMKW A256GCMKW
+SENCR=A128CBC-HS256 A192CBC-HS384 A256CBC-HS512 A128GCM A192GCM A256GCM
+tests/rsa_oaep
+AWRAP=ECDH-ES ECDH-ES+A128KW ECDH-ES+A192KW ECDH-ES+A256KW RSA1_5 RSA-OAEP RSA-OAEP-256
+mktemp -d
+tmpdir=/tmp/tmp.9p01yZzbya
./tests/jose: 15: ./tests/jose: Syntax error: "(" unexpected
FAIL tests/jose (exit status: 2)
I know that calling jose jwe enc -c -I pt.txt -k rsa_pub.jwk
from command line gives a compact serialized output. Is it possible to obtain a similar output from the function jose_jwe_enc
in jwe.h
? How to achieve it if the purpose is not command line execution but simple function calls from a program?
The Jose RFCs use Key Wrap and Key unwrap to refer to key wrapping like operations, the API should reflect that language so that a user can directly relate the two concepts
Hello,
fetching a value from a nested hash requires a lot of --get
:
echo '{"level1":{"level2":{"level3":{"key":"value"}}}}' | \
jose fmt --json=- --object --get level1 --get level2 --get level3 --get key --unquote=-
It was nice if the keys could be concatenated so this can be written in a shorter form like:
echo '{"level1":{"level2":{"level3":{"key":"value"}}}}' | \
jose fmt --json=- --object --get level1.level2.level3.key --unquote=-
Bonus: Make the separator (currently: dot) configurable.
Related, it was nice if -U/--unwind
could understand an optional repetition value, so (taken from clevis-encrypt-tang):
jwe="$(jose fmt -j "$jwe" -g protected -g clevis -g tang -q "$url" -s url -UUUUo-)"
could be written as
jwe="$(jose fmt -j "$jwe" -g protected -g clevis -g tang -q "$url" -s url -U4 -o-)"
PS: To make sure: This is not at all about short/long parameter names.
./jose alg
returns nothing. I guess this is the main reason why I can't generate any keys, load from file, encrypt nor decrypt.
Do I need to load the supported algos somehow or what am I doing wrong?
I have a runtime problem with Jose-9 ...
When statically linked, the following trivial program detects a runtime error on jose_jwk_gen(). The same program detects no error when dynamically linked.
$ cat test_jose_jwk_gen.c
#include <jose/jose.h>
int main()
{
json_auto_t* jwk = json_pack("{s:s}", "alg", "ES256");
if (jwk == NULL)
printf("Error: json_pack()\n");
if (jose_jwk_gen(NULL, jwk) == false)
printf("Error: jose_jwk_gen()\n");
return 0;
}
$ gcc -o test_jose_jwk_gen test_jose_jwk_gen.c -I$THIRD_PARTY/jose/linux64-x86/include -I$THIRD_PARTY/jansson/linux64-x86/include -L$THIRD_PARTY/jose/linux64-x86/lib -ljose -L$THIRD_PARTY/jansson/linux64-x86/lib -ljansson -L$THIRD_PARTY/openssl/linux64-x86/lib -lcrypto
$ ldd test_jose_jwk_gen
linux-vdso.so.1 => (0x00007ffc10584000)
libjose.so.0 => $THIRD_PARTY/jose/linux64-x86/lib/libjose.so.0 (0x00007f300eb4f000)
libjansson.so.4 => $THIRD_PARTY/jansson/linux64-x86/lib/libjansson.so.4 (0x00007f300e941000)
libcrypto.so.1.0.0 => $THIRD_PARTY/openssl/linux64-x86/lib/libcrypto.so.1.0.0 (0x00007f300e50e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f300e126000)
libz.so.1 => /lib64/libz.so.1 (0x00007f300df0f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f300dcf3000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f300daef000)
/lib64/ld-linux-x86-64.so.2 (0x00007f300ed6c000)
$ ./test_jose_jwk_gen
<no error>
$ gcc -o test_jose_jwk_gen test_jose_jwk_gen.c -I$THIRD_PARTY/jose/linux64-x86/include -I$THIRD_PARTY/jansson/linux64-x86/include -Wl,-Bstatic -L$THIRD_PARTY/jose/linux64-x86/lib -ljose -L$THIRD_PARTY/jansson/linux64-x86/lib -ljansson -Wl,-Bdynamic -L$THIRD_PARTY/openssl/linux64-x86/lib -lcrypto
$ ldd test_jose_jwk_gen
linux-vdso.so.1 => (0x00007ffeb117d000)
libcrypto.so.1.0.0 => $THIRD_PARTY/openssl/linux64-x86/lib/libcrypto.so.1.0.0 (0x00007f5a60334000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5a5ff4b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f5a5fd47000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5a60768000)
$ ./test_jose_jwk_gen
Error: jose_jwk_gen()
The makefile to build the Jose git-submodule looks like:
$(TARGET_NAME) :
@$(ECHO) "Creating $@."
@$(CD) repo; \
autoreconf --install; \
export jansson_CFLAGS="-I../../../jansson/$(PLATFORM)-$(PROCESSOR)/include"; \
export jansson_LIBS="-L../../../jansson/$(PLATFORM)-$(PROCESSOR)/lib -ljansson"; \
export libcrypto_CFLAGS="-I../../../openssl/$(PLATFORM)-$(PROCESSOR)/include"; \
export libcrypto_LIBS="-L../../../openssl/$(PLATFORM)-$(PROCESSOR)/lib -lcrypto"; \
./configure --enable-static --prefix=$(THIRD_PARTY)/jose/linux64-x86; \
$(MKDIR) $(THIRD_PARTY)/jose/linux64-x86; \
$(MAKE) CFLAGS="-g -O2 -m$(BUS)"; \
$(MAKE) install
and the Jansson git-submodule's makefile looks like:
$(TARGET_NAME) :
@$(ECHO) "Creating $@."
@$(CD) repo; \
autoreconf --install; \
./configure --prefix=$(THIRD_PARTY)/jansson/linux64-x86; \
$(MAKE) CFLAGS="-g -O2 -m$(BUS)" -fPIC; \
$(MKDIR) $(THIRD_PARTY)/jansson/linux64-x86; \
$(MAKE) install
Platform info:
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
o o o
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
We'd like to be able to change API in the future if we need. This requires symbol versioning.
Currently, jose_jwk_allowed() returns true if the JWK contains none of the appropriate attributes. A strict mode would fail in this case.
Homebrew is a very popular package manager for macOS and I think it would be great if josé
was distributed through it!
This is not yet implemented.
In commit 285327a you rewrote the calculation on length of a b64 encoded/decoded string. In the jose_b64_decode the test to handle the "0" return from the jose_b64_dlen is not taken into account when decoding. So when an illegal padded string is presented, the program coredumps on the fact that the buffer is 0-size but the decoding is done in jose_b64_decode_buf based on the zero terminated string not on the length of the buffer.
I have been trying to build jose using Oracle (Sun) Studio CC and IBM xlc. configure.ac
specifiesa lot of warning flags which are GCC specific. (I guess Clang accepts these too.) The primary issue I run into though is that jose depends on the json_auto_t which depends on a compiler extension in Clang & GCC.
Using json_auto_t was adopted in change 803f0b4. I am also not sure if there would be a similar extension on Visual Studio that support this.
Is support for other compilers something that would be considered, or is this project purely targeted at GCC?
Hi there!
I'm needing to integrate Jose functionality into my iOS project. I found this library and would like to try it out. However, when I pull all the source files into my project and attempt to compile, I get an error around #include <jansson.h>
.
Is there a step I'm missing for getting this project organized to integrate into iOS? I cannot find a jansson.h
file within the project. Google indicates that it is part of a separate library, but I am unsure of how to integrate it with this library.
Any help with fixing these issues would be appreciated! Thanks!
The wrong salt length value is being used for RSASSA PSS signatures.
RFC 7518 (JWA) says the following:
3.5. Digital Signature with RSASSA-PSS
This section defines the use of the RSASSA-PSS digital signature
algorithm as defined in Section 8.1 of RFC 3447 [RFC3447] with the
MGF1 mask generation function and SHA-2 hash functions, always using
the same hash function for both the RSASSA-PSS hash function and the
MGF1 hash function. The size of the salt value is the same size as
the hash function output. All other algorithm parameters use the
defaults specified in Appendix A.2.3 of RFC 3447.
The code in rsassa.c that generates signatures (sign()) fails to call EVP_PKEY_CTX_set_rsa_pss_saltlen() and therefore uses the default salt length value which is the maximum salt length. This goes against the JWA specification which says that the salt length must be the same as the hash length. Passing a value of -1 to EVP_PKEY_CTX_set_rsa_pss_saltlen() rectifies this issue.
OK technically this is not an issue, feel free to close it. But thank you so much for writing this software! I have been trying to make keys and sign messages thus far with javascript and python libraries and they just didn't work right. This program did RSA256 signing perfectly on the first shot and was so easy to use with just regular files. You guys are the best.
🎆
When trying to build on OSX I'm running into bash syntax error:
$ autoreconf -if && ./configure
glibtoolize: putting auxiliary files in '.'.
glibtoolize: copying file './ltmain.sh'
glibtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
glibtoolize: and rerunning glibtoolize and aclocal.
glibtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:4: installing './compile'
configure.ac:6: installing './missing'
cmd/Makefile.am: installing './depcomp'
checking build system type... x86_64-apple-darwin15.6.0
checking host system type... x86_64-apple-darwin15.6.0
checking target system type... x86_64-apple-darwin15.6.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin15.6.0 file names to x86_64-apple-darwin15.6.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin15.6.0 file names to toolchain format... func_convert_file_noop
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin15.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
./configure: line 12097: syntax error near unexpected token `0.25'
./configure: line 12097: `PKG_PROG_PKG_CONFIG(0.25)'
I may just be going about building this the wrong way, in which case which is the right way?
configure does not detect and fail if jansson is < v2.9
Port Jose code to use contemporary OpenSSL API, allowing to use external engines and algorithms provided by them.
Discovered in latchset/clevis#102
Clevis is failing to create a TPM PCR Policy to enforce platform integrity state through Jose when the number of selected pcrs_ids
is more than one, and an array is passed to the configuration.
From @martinezjavier comment:
$ jose fmt -j- -Og pcr_ids -u- <<< '{"pcr_bank":"sha1","pcr_ids":"16"}'
16
$ echo $?
0
$ jose fmt -j- -Og pcr_ids -u- <<< '{"pcr_bank":"sha1","pcr_ids":["16"]}'
$ echo $?
4
Apparently, Jose is not happy with the array notation in pcrs_ids
.
Due to this, on Clevis, when using more than one PCR to declare the policy, it silently fails to parse the config, and create the LUKS key slot without any PCR policy silently
Jose Version: jose-10-3.fc29.x86_64
in 803f0b4 there was a dependency on a gcc specific cleanup feature that was introduced. This seems to have broken an otherwise portable C library.
But moreover akheron/jansson library which introduced this json_auto_t
type did so within a ifdef check for GCC where as in this library it wasnt. Can we please introduce preprocessor guards to stop this feature from breaking the portability of the library?
It would be useful to create a RSA/EC JWK from a X.509 cert or a PKey.
In lib/openssl/aesgcm.c:
o o o
301 static jose_io_t *
302 alg_encr_dec(const jose_hook_alg_t *alg, jose_cfg_t *cfg, const json_t *jwe,
303 const json_t *cek, jose_io_t *next)
304 {
305 const EVP_CIPHER *cph = NULL;
306 jose_io_auto_t *io = NULL;
307 io_t *i = NULL;
308
309 switch (str2enum(alg->name, NAMES, NULL)) {
310 case 0: cph = EVP_aes_128_gcm(); break;
311 case 1: cph = EVP_aes_192_gcm(); break;
312 case 2: cph = EVP_aes_256_gcm(); break;
313 default: return NULL;
314 }
315
316 uint8_t iv[EVP_CIPHER_iv_length(cph)];
317
318 if (jose_b64_dec(json_object_get(jwe, "iv"), NULL, 0) != sizeof(iv))
319 return NULL;
320
o o o
the condition evaluated at LINE=318 always fails for IV lengths not equal to 12.
I believe the condition must test a range of values -- not just 12.
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,
While the main README says it's supported, I'm getting
jws.c:306:JOSE_CFG_ERR_ALG_NOTSUP:Signing algorithm (PS256) is not supported
Using the command:
jose jws ver -k private.jwk -i message.jws
message.jws being:
eyJhbGciOiJQUzI1NiJ9.SGVsbG8gd29ybGQh.LyJBXPHYt3B4AJQ_aFfrbkTfEflpooS2gb5zDa4WCfD528udcJ-OBngebtphsG7Z-6bQmcUzz5AEtDJ_qTsrEB8pcIfl0OTNcqUGokkpeBIpukHgYEhVEaJ6TKPIlXbbwdV9Bv7k9vacMphNKJ3E-B9e0Y5iBuGu30pxJlBiQykybh2FAUGAJqYPG1pJxqzWqBSnirnUWe7tOOdNq5H6R0NJEEuwsnlCV27DfEQIM0ILHvJjpSEhAc6TCStcV3V0swvYmxVe8NIhajsYtva1J1M5ZiHKCaGsznktz28rGcJZ0Cf-lJIfr3FC9_eYOeNbEk-APgkWzcdN45VS05uVSA
and private.jwk
being
{"alg":"PS256","d":"AnwLtzR4gOIIfraMxK58U-R7ecLqtGIeMoengJ4sNcm36krYZP0cN57LsaXiRvkciASTwXD5TFVAvBEW-39kpvJOmCYE8a1TGNO7nUDVrc9JhSoivilTpER2n9Pmr3S2NPY0jTBebNEYAJIgcM9QDPbLDQ86R7CB0nlMJcogAgjpdceZJBrqaziJuM0MdyuY7pvkwliKKsgAsj8IpYW3kniBg1jVweHeDfXrtovdecVudOG8p6RUMFSZnxd3FYNQJgRaNy7iGh6S1q81Dx9VsFEK2njfjHSdcVF6qj-tT6cgpQ_56JyrzQhd8xsN2uArazNzdZHCejHD9_MrOUOJAQ","dp":"pZe217GZQXg3NIqh1gLmNCo37fko2CCO2kBN5JxHH9fB8aCeT9XyNy4iAvyyWSHkAjsloyJEwBuF2NXxeagb04P4KGX8zVXdANFk6MAsaGDVYs8FT1DhMsH_aRl01tRGEb9ss4MQpq5MkKNAb0Ib7h8mmIevQ7N2ZAE8IRwb8Tk","dq":"kyK-2lqqanoFhBFKP3UVneBbwfHfcdKwX1ivjTJTRettDYzh3aH9Cii44ZaFCS3Ck2MvqgIc8Bz-04kgkMVjqhuCWE7T27a0Lfx3V0PZAkXd_XV9eEZvvh5DZ4St982POvwRBqWOxPpOcSajdPK4ic9QoRnomtMlv6ST2QQ9inE","e":"AQAB","ext":true,"key_ops":["sign"],"kty":"RSA","n":"ofdkpbwFcAJjVKMto8ymSua25Ruet-QjIsNnSL6u2BaAronZ7mNymukTzicGq02f3PjP9lbvsjhLB-8fC88lmo6m_ceT9FrZgLh5HwLIpvObRt9h27BU8nIjC4H_fyrdHaS22TB0FD-zA0If-9zopLaqvgioznXcFzPveG4fncdnoxyfaRThSJwlZmSagvE_j56hIFmTV7TbYe-AHcfCEPE5apHXBXS13XfauCnpuxR1RAHgIvWRUEngaXPOPxGfQxlYXtnV0zmWpgD1x6OEmI-hjouz3sbxLluW8OmL_B_iB7XoS15YjcpOXh6HTaMz4QZDToY1Hof42lrHArzy_Q","p":"0utor0vGesVMZri6pBU3W1X18M99IhLaC-1F9DL8mjZeyd2FI64TOHzUQbqPT5zgIhFDl6e3NiijktGGtRVG-3x8-_c1nd5EtDOX_BWy1YVnlNTjfNG00dbN7YunlA8XBXcojyveeXHUKUuG82FM1iMj040RIJZtWNWLowAwd5k","q":"xJV7LEkXGDfdFe8qUbRUsA5UTvtPaPQsxLKGLbpRqtyW2om8SsFoS9na2mZIxX_s9537r1hcnd94T16cE9JDbR0PvUl70-HFcmx07IodokMDQMu4rTTA1SxeeOnBD9z3IXB6mM2yWvDMpIch28AF_n8FaLSVqZf_7lno0Ld9pQU","qi":"Uq0Z6aOiQHXPfYyAU6gJGpZFBMK8kL175jY69r7Ib4rMCrVqrKQrX_l2ZJmaGwtFMjGdOgBjBt_Rtjuh3e4CRXNj7UzyUDqD2Hn-5_P7PSTGjZYRhSb2mJhVAN8x9Q8G3nuW621_giSTxquTr2AlMvuBSDxke-4kncnnVyYYLiY"}
Use jose_jwe_enc() to encrypt with alg=ECDH-ES+A256KW and enc=A256GCM.
I want to use that data for Compact Serialization (Compact Serialization is currently implemented independently).
The result of Encrypting with jose_jwe_enc() is as follows.
"protected":"~",
"header":{
"epk":{
"kty":"EC",
"crv":"P-256",
"x":"~",
"y":"~"
}
},
"encrypted_key":"~",
"iv":"~",
"tag":"~",
"ciphertext":"~"
CompactSerialization cannot use the header object,The epk object must be inserted protected.
Is there a way to insert an epk object into protected and not create a header object?
(The pattern of alg=RSA-OAEP-256, enc=A256GCM works with the original implementation of Compact Serialization.)
The clevis unlockers use the idiom
read -r -d . hdr
to read the heaader of the jwe on stdin, and the header only.
Now I'd like to move that logic to jose since the above way
As a solution I propose a new subcommand that does the same. The above statement would be rewritten as
hdr="$(jose jwe hdr --input=- --output=-)"
and I consider that an improvement.
¹ Since all solutions that are around slurp the entire input, something I want to avoid at any cost.
² I managed to replace all the other bashsims, you'll find that as an clevis issue soon.
Release 3 had no configure script and release 4 was not published as a tar ball at all. Please run autoreconf and ship the configure script in source releases.
This way a user can set the allowed algorithms globally and not risk unvalidated input to cause the use of algorithms not deemed acceptable for an application.
Hi, first thank you for developer this library, is very helpfull.
I've added all dependences, Jannson(libjannson.a), openssl (libcrypto.a and libssl.a)
I'm having problems with compile my iOS project with this error:
Undefined symbols for architecture x86_64:
"_jose_openssl_jwk_from_RSA", referenced from:
+[JweManager rsaToJwk:] in JweManager.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Anyone could help me?
Thank you
An Empty CEK would cause internal generation and allows to detect that the ECDH-DS function should fail (as it cannot deal with a pre-generated CEK anyway.
I was curious if you guys considered having a conversion build in for JWK <-> PEM formats? Perhaps even extension based so that if -o whatever.pem
ended in PEM then you would use that format.
I tried to generate a key using the following command:
./jose jwk gen -i '{"alg": "RS256"}' -o mykey.jwk
And various variations on that theme. But the only response I seem to be able to get is JWK generation failed!
. It would be nice if the tool helped a bit and let you know what you are doing wrong.
Hello,
can you please check man ./doc/ronn/jose-jwe-enc.1
? The last example "Encrypt with two keys and two passwords" is not properly formatted. I guess there's a missing newline in the related .md
I can not do make, owing to this error:
$ make
CC lib/openssl/libjose_openssl_la-jwk.lo
lib/openssl/jwk.c:29:1: error: unused function 'EVP_PKEY_cleanup' [-Werror,-Wunused-function]
declare_cleanup(EVP_PKEY)
^
lib/openssl/misc.h:35:5: note: expanded from macro 'declare_cleanup'
type ## _cleanup(type **p) {
^
:135:1: note: expanded from here
EVP_PKEY_cleanup
^
1 error generated.
make: *** [lib/openssl/libjose_openssl_la-jwk.lo] Error 1
In the README.md the following command is given as an example:
jose jwk gen -t '{"alg": "A128GCM"}' -o oct.jwk
But it seems that -t
is no longer a valid option?
The jose sup
command should have the ability to query specific types of algorithms and get a newline delimited output. For example:
$ jose sup -H
sha1
sha224
sha256
sha384
sha512
This makes it much easier to use for scripting. See for example: https://github.com/latchset/tang/blob/master/tangd-update#L23
I couldn't detect if the project was being actively compiled and used on Windows. Is there a plan ?
It may be useful to have a link to the API docs. Browsing to them in the source archive provides raw HTML output which is not great.
Hello,
perhaps a short example already demonstrates the point:
echo '{"key":"value"}' | jose fmt --json=- --object --get key --unquote=-
value
echo '{"key":"value"}' | jose fmt --json=- --unquote=- --object --get key
In other words, placing the --unquote
output parameter before the --get
operation yields in no output at all.
So I'm asking to to either make parameter order irrelevant for jose's operation, at least where possible - I know in some places like the clevis pins order is significant. Or - easier but less user-friendly - place a warning in each manpage about this.
Hi ,
OSX build for 'AMD64' for below 'env' is failing:
- DISTRO=osx:xcode8.3
- PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig:/usr/local/opt/zlib/lib/pkgconfig
Log Summary:
"==> ./bootstrap --prefix=/usr/local/Cellar/cmake/3.18.2 --no-system-libs --paral
==> make
The job exceeded the maximum time limit for jobs, and has been terminated. "
Full error log can be tracked on the link: https://travis-ci.com/github/sanjay-cpu/jose/jobs/382685852
Please someone look into the issue.
Thanks !!
As an application, I want to be able to on compile-time detect which version of the library is being used, so I can write code that is compatible with different API versions.
JWK Type as an enum will make it impossible to handle uknown key types and require changes in the API if a new key type is created.
Please feel free to close if you disagree.
I have been working around a misbehaving service that produces JWKs with standard base64 encoded data for the 'k' field instead of base64 urlsafe encoded data (minus padding) as the standard suggests.
I have a patch that would let the base64 decoder accept either data formats. I can see arguments for not accepting this upstream (as it doesn't strictly conform to the RFC), but I figured I'd raise it as an issue and see how things shake out.
It might be a nice idea to try and support integration between keys created by gpg
and jose
e.g.
jose jwk fmt -I keyring.gpg -o keyring.JWKset
As far as I can see there are very few tools that interopt with public/private keys formatted in the OpenPGP format, this could be an opportunity to fix that.
The test scripts assume that /bin/sh is a bash compatible shell. Debian (Travis CI) uses a simpler shell that only implements sh
.
trap exit ERR
trap: ERR: bad trap
function onexit() {
rm -rf $tmpdir
}
./tests/jose: 15: ./tests/jose: Syntax error: "(" unexpected
1."pem → jwk" conversion with the following API
jose_openssl_jwk_from_EVP_PKEY()
2."jwk → pem" conversion with the following API(jwk was generated in 1.)
jose_openssl_jwk_to_EVP_PKEY()
3.Generate pem file with OpenSSL
4.Read pem file of 3. by rsa command of OpenSSL
→Read failure
Is there a way to choose what encryption scheme is used for the CEK of a JWE? I noticed it always defaults to AES-CBC and I can't find any option or way (by glancing at the code) to use, say, AES-GCM or direct mode.
Again, reported by Debian's lintian checker:
inferrence -> inference
miscelaneous -> miscellaneous
Found in:
doc/doxygen/man/man3/jose_cfg.3
doc/doxygen/man/man3/jose_jwe.3
jose/cfg.h
jose/jwe.h
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.