Open tpazderka opened 5 years ago
Should be easy. The only thing not provided by cryptography is SIV (https://www.rfc-editor.org/info/rfc5297) which is kind of nice but not essential.
OK, this turned out not to be that easy... We heavily depend on jwkest
which in turn depends on pycryptodome
.
So either we build a layer inbetween to pass pycryptodome-like objects to jwkest or we drop the dependency on jwkest and using something new.
Didn't @rohe mention a jwkest rewrite on top of cryptography?
I guess it is https://github.com/openid/JWTConnect-Python-CryptoJWT, but I am not sure how finished it is.
No idea. Alternative would be pyjwt, which is also based on cryptography and seems to be in quite wide spread usage. https://github.com/jpadilla/pyjwt
Hm, looks good. I am inclined to use more widespread packages since they tend to be better maintained. I will have a look and then maybe give it a go in another issue.
@tpazderka What's the progress on this? It will be good if we only use maintained dependencies. Is there a branch on this I can contribute to complete this enhancement?
Pycryptodomex is actually maintained, so "unmaintained" isn't the major issue. But jwkest is kind of an issue.
But we support quite some features from JWT, like encrypted jwt, and things are pretty intermingled with jkwest API. So It might be necessary to break some APIs, rewrite the keyjar API a bit to switch the code to something like jwcrypto (https://github.com/latchset/jwcrypto), as pyjwt does not support encryption.
There is a branch use_pyjwt
which is still very much WIP...
pycryptodome
is not considered a secure alternative topycrypto
.pyca/cryptography
is more widely used and probably more secure.