How to use java-deprecated elliptic curves in jdk 17 - jjwt

we're migrating from jdk 8 to 17 and apparently, the curve that our privateKey uses: secp256k1 is deprecated, so we get this error
Unable to calculate signature using Elliptic Curve PrivateKey. Curve not supported: secp256k1 (1.3.132.0.10)
io.jsonwebtoken.security.SignatureException: Unable to calculate signature using Elliptic Curve PrivateKey. Curve not supported: secp256k1 (1.3.132.0.10)
at app//io.jsonwebtoken.impl.crypto.EllipticCurveSigner.sign(EllipticCurveSigner.java:46)
at app//io.jsonwebtoken.impl.crypto.DefaultJwtSigner.sign(DefaultJwtSigner.java:59)
at app//io.jsonwebtoken.impl.DefaultJwtBuilder.compact(DefaultJwtBuilder.java:353)
Is there any way we could still use this privatekey with jjwt? adding BouncyCastleProvider doesn't seem to work for our case..

BouncyCastleProvider actually did work, but I had to put it in front of SunEC provider in order to use bouncycastle's implementation for signing the jwt

Related

nettle curve25519 key exchange

I'm trying to understand how to implement key exchange using nettle's curve25519 functions.
I'm writing an software that establishes encrypted TCP connection with public key based authentication. The client and server programs share the same code base.
This is an hobby project to learn network and crypto programming. :-)
I have working toy app using nettle's rsa_encrypt function, but there is no equivalent to curve25519 from what I see. How do I do key exchange using nettle's curve25519 functions?
And to be clear, I know I could and probably should simply use any production quality TLS library like openssl, but I want to learn how to do encrypted TCP connection from scratch. Using TLS library would defeat that purpose.
I compared many crypto libraries and found nettle as most easily approachable since it is low level.
Elliptic curves, generally, are used for key 'agreement' rather than key 'exchange'.
I don't know how much you know about this so I'll briefly explain:
RSA - we generate a random symmetric key, encrypt it with the public key of the recipient, who themselves later decrypts and uses it.
ECC (Elliptic curve crypto) - we use a process called Elliptic Curve Diffie-Hellman, due to the commutative nature of the multiplication of curve points, we can establish the same point on the curve by multiplying theirPublicKeyPoint * ourPrivateKeyPoint * G, where G is the curves base point.
So, in summary:
I greatly encourage you to use ECDH instead of RSA.
You need to find a function to perform ECDH over curve25519, also known as x25519, nettle's function is this.
After the process of ECDH, we end up with another point on the curve. :) - which we hash the x co-ordinate of to generate the symmetric key. Though this is usually done by the lib.

Does OpenSSL use given hmac key directly or process before use it?

I am implementing the OpenSSL lib to my code by using the EVP interfaces. But I have a question for secure mac operation with OpenSSL. My choice is hmac-sha256 as mac method. My question is that openssl, apply a process on hmac key before use it?
That operation could be insert any random number or apply the algorithm. For example; it can apply the PRNG on hmac key.
By the way, I am using a version of OpenSSL 1.1
How can I be sure that OpenSSL uses the hmac key directly?

how do or what is the best way to generate AES key using openssl programmatically?

how do or what is the best way to generate AES key using openssl programmatically? Saw recommendations using RAND_bytes. I also come across this API — AES_set_encrypt_key(....). But the first parameter seems to be user’s encrypted key. So, I think you I need to generate an AES key first b4 calling this API.
Please advise

Questions about creating a key generator for a license system

I am new at this domain and I have to built a fairly safe license mechanism, but I have some questions about how public key system works.
Imagine an implementation of a key generator that uses a private key to generate a string with the MAC and the expiration date. This string will be decrypted by the software and the MAC will be checked to see if it can execute. MY question is: if someone decrypt my message and saw the MAC then it would be fairly easy to create key, wouldn't it? I say that because I know that there is some mathematics behind the fact that you can encrypt with one private key and decrypt with a public one, therefore with the encrypted message, the real message and the public key I guess that someone can find the private key.
I am a bit lost in the discussion about if it is necessary to hash some message before the encryption or not. And also the usage of elliptic curves for compression. I would appreciate if someone can give me some info about the topic.
P.S. I am using C++, but any comment in any other language is welcome.
create an DSA or ECDSA or <insert favourite sigining algo here> keypair ... YOU keep the private key safe ... the public key is embedded into your binary
create a datastructure holding your relevant licensing information
compress it
sign it
upon license checking:
verify license signature
uncompress structure
make whatever checks are needed based on license data
common well known asymetric ciphers are not prone against known plaintext attacks
to my knowledge elliptic curves are not used in the context of compression
elliptic curves ARE used in the context of cryptography (read encryption and digital signatures)
train your google-fu with: RSA, DSA, ECC (elliptic curve cryptography), ECDSA

Converting coordinates from SVY21 to WGS84

I am trying to transform the SVY21 coordinates I have to the WGS84 coordinate system.
I tried using the GDAL software and pasted the following into command after installing:
ogr2ogr -f GeoJSON –t_srs WGS84 <jsonFileName>.json <shapefile>.shp
It results in the failure:
Unable to open datasource 'WGS84' with the following drivers
And the drivers are listed.
Also I tried to use the python utm package to convert the N48 utm coordinate to WGS48, but I did not manage to convert the SVY21 coordinates to the N48 utm reference point.
I found the proposed solution in this old post confusing in terms of terminology and I would prefer using some existing solution.
Is there a "easy" solution that makes use of my previous approaches or is quickly applicable to my problem? I would also be happy if someone could provide me with a more precise explanation of the approach featured in the older post.
Thanks in advance.
Edit: I tried writing a python script that implements the vicenty direct calculation from the "old post" mentioned before. It would also help, if someone could confirm that substracting the False Coordinates of Projection Origin (28001.642mE,38744.572mN) from the raw svy21 (e,n) and using the Projection Origin (Unmarked point) (103° 50' 00", 1° 22' 00") is correct.
I was compiling gdal by hand and I could use the following command to do what you wanted:
You have to copy the *.shp (and *.shx) files beside the ogr2ogr-command (Source: https://gis.stackexchange.com/questions/56652/how-to-move-and-open-shapefiles-with-ogr2ogr)
gdal does not immediately know "EPSG:3414" - the EPSG name for SCY21, so give it a hint, this is in the [INSTALL LOCATION]/data (i dont know where it is on an installed version, especially not on windows. Search for a file called "gcs.csv", and point GDAL_LOCATION to the containing folder.
define t_srs and s_srs eccordingly
Define the output format ("GEOJson")
Summa summarum:
GDAL_DATA="../data" ./ogr2ogr -f "GEOJson" "LaneMarking_wgs84.json" "LaneMarking.shp" -t_srs WGS84 -s_srs "EPSG:3414"
Have fun :)