cert.public_key.verify(
OpenSSL::Digest::SHA256.new,
Base64.strict_decode64(signature),
signature_data
)
I am java developer, may i have java compatible code for above python script?
I have X509Certificate, when i try below code, i am getting invalid length issues. wanted verify if the code is correct? in the below code, key is X509Certificate object getKey()
Signature verifySignature = Signature.getInstance("SHA256withRSA");
verifySignature.initVerify(key);
verifySignature.update(signatureData.getBytes());
boolean verified = verifySignature.verify(signatureData.getBytes());
Update :
The problem was i passed signatureData instead of signature to verify method. solved now
Related
i have create an university project with Java And Symfony when the user register from my java app he can login with both java and symfony , but the contrary it is impossible , it only login from symfony and it display to me this error in java
Caused by: java.lang.IllegalArgumentException: Invalid salt revision
Cryptage Methode : Bcrypt
Security.yml Symf
App\Entity\Utilisateur:
algorithm: bcrypt
encode_as_base64: false
iterations: 1
Utilisateur entity
/**
* Returning a salt is only needed, if you are not using a modern
* hashing algorithm (e.g. bcrypt or sodium) in your security.yaml.
*
* #see UserInterface
*/
public function getSalt(): ?string
{
return null;
}
JAVA
Login Method
if (rs.getString("email").equals(t.getEmail()) && BCrypt.checkpw(t.getMotpasse(), rs.getString("motpasse")) == true) {
if (rs.getString("activated").equals("Active")) {
idUser = rs.getInt("idU");
For more information on this error check BCrypt.checkpw() Invalid salt version exception
I would suggest you start to debug the following piece of your code:
BCrypt.checkpw(t.getMotpasse(), rs.getString("motpasse"))
Check in your database what the value for the hashed password is.
Does it match the expected value of $xy$... where xy should be 2a, 2b, 2y or similar.
Check in your Java code what the values of password t.getMotpasse() and hashed password rs.getString("motpasse") are; log them/debug the code.
Make sure to check the documentation, that you are providing the arguments of checkpw in the correct order (plain, hashed and not hashed, plain).
But I suspect that your PHP library generates a newer salt version (revision) that your current java library does not support. See for example https://github.com/djmdjm/jBCrypt/issues/2
Some code examples that i could find throw this exception when the salt version is not 2a, which would explain why generated salts from Java do work, but from Php don't.
In that case you will either have to:
make sure the PHP code generates salt versions 2a
upgrade/change the Java BCrypt library to a version that supports the newer salt revision
I am trying to read a PKCS#8 private key which looks like following:
key.k8 --> (Sample key. Passphrase - 123456):
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQILbKY9hPxYSoCAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBCvaGt2Hmm2NpHpxbLvHKyOBIIE
0IQ7dVrAGXLZl0exYIvyxLAu6zO00jL6b3sb/agTcCFOz8JU6fBanxY0d5aYO4Dn
mynQG7BoljU470s0zIwW/wk0MmdUFl4nXWBX/4qnG0sZqZ9KZ7I8R/WrBkmpX8C/
4pjdVhu8Ht8dfOYbkbjMBTohDJz8vJ0QwDIXi9yFjjef+QjwrFOl6kAeDJFVMGqc
s7K/wOnhsL1XxfW9uTulPiZh5YTZKcatMkeGDR7c+cg5I+Mutim92diWuCekhNoa
uvhUy1M3cbs7Azp1Mhz+V0CDKklI95EvN4u23WhiJPCjAofC/e45/heOP3Dwm7WZ
zHEY1C/X8PsTl6MEEIF3ZJP+4Vr0corAs1L2FqE6oOng8dFFYmF5eRyBx6bxFd05
iYbfOH24/b3qtFKPC689kGEd0gWp1dwES35SNNK+cJqVRTjgI0oKhOai3rhbGnmp
tx4+JqploQgTorj4w9asbtZ/qZA2mYSSR/Q64SHv7LfoUCI9bgx73MqRQBgvI5yS
b4BoFBnuEgOduZLaGKGjKVW3m5/q8oiDAaspcSLCJMIrdOTYWJB+7mfxX4Xy0vEe
5m2jXpSLQmrfjgpSTpHDKi/3b6OzKOcHjSFBf8IoiHuLc5DVvLECzDUxxaMrTZ71
0YXvEPwl2R9BzEANwwR9ghJvFg1Be/d5W/WA1Efe6cNQNBlmErxD6l+4KDUgGjTr
Aaksp9SZAv8uQAsg7C57NFHpTA5Hznr5JctL+WlO+Gk0cAV6i4Py3kA6EcfatsnS
PqP2KbxT+rb2ATMUZqgWc20QvDt6j0CTA1BuVD1PNhnAUFvb2ocyEEXOra22DPPS
UPu6jirSIyFcjqFjJ9A1FD9L4/UuX2UkDSLqblFlYB1+G55KZp+EKz8SZoN5qXy1
LyMtnacEP5OtRDrOjopzVNiuV1Uv63M9QVi1hZlVLJEomgjWuvuyEuIwDaY2uryW
vx+jJEZyySFkb1JwAbrm+p6sCTFnbQ/URKC2cit/FJyKqNim6VQvGL8Sez34qV3z
D13QJgTZfsy+BaZoaQ6cJTXtJ8cN0IcQciOiDNBKMW66zO6ujS8G+KNviNQypDm6
h4sOgjMqLaZ4ezPEdNj/gaxV7Y15nVRu0re8dVkaa5t9ft/sh6A+yeTD5tS5hHkf
NI7uJPTaTXVoz7xq2PAJUTWujMLMZKtmNOzNqYvxWRy3tCOFobBQkMxqEBEwHd+x
SA+gFcJKJ+aNfCGZJ5fFr8rNlhtOF6uMwOAlfiUlP/pCUDUCKPjZVj4K95yNc8Io
jSZSPb5tGPe0HqXgc6IAfQarlUZt90oVtzL0OfOfTxe1bEzS2ccNadbx/6vjLBc4
q5UuUBppl3rXpbuZ7J1Rp3n2byF4APxFdT2LHKq+MYMfWUToau/TCMT4lFIM9tM8
7TuuyUT2PKzf/xlsl4iScw96z9xxGPQrXn7IA2W5iL+0eCLztJdjNRX1FisdfIBL
PraOVlmF8jHKbFdRZ8Yi8pApbQjvHi24g7dX7u/cq1FH/VE+nJ0O8YVCYVDw13CW
h0p7yD7BuB0R+0WnR0yvkp30vK4/rtCB+Ob8bH/+HvAZrAU5X8jq/wsQbLkrLHZV
6A6GGfX8+hy5AoaXsH1BHnMyXkaF6Mv29z8JcslDJxX/
-----END ENCRYPTED PRIVATE KEY-----
Following code is being used to parse the private key:
InputStream privateKeyInputStream = getPrivateKeyInputStream(); // reads the key file from classpath and share as DataStream
logger.info("InputStreamExists --> {} ", privateKeyInputStream.available());
PEMParser pemParser = new PEMParser(new InputStreamReader(privateKeyInputStream));
Object pemObject = pemParser.readObject();
if (pemObject instanceof PKCS8EncryptedPrivateKeyInfo) {
// Handle the case where the private key is encrypted.
PKCS8EncryptedPrivateKeyInfo encryptedPrivateKeyInfo = (PKCS8EncryptedPrivateKeyInfo) pemObject;
InputDecryptorProvider pkcs8Prov =
new JceOpenSSLPKCS8DecryptorProviderBuilder().build(passphrase.toCharArray());
privateKeyInfo = encryptedPrivateKeyInfo.decryptPrivateKeyInfo(pkcs8Prov); // fails here
}
InputStream resourceAsStream = null;
if ("local".equals(privateKeyMode)) {
resourceAsStream = this.getClass().getResourceAsStream(privateKeyPath);
} else {
File keyFile = new File(privateKeyPath);
logger.info(
"Key file found in {} mode. FileName : {}, Exists : {}",
privateKeyMode,
keyFile.getName(),
keyFile.exists());
try {
resourceAsStream = new DataInputStream(new FileInputStream(keyFile));
} catch (FileNotFoundException e) {
e.printStackTrace();
}
When I am running this code through intelliJ on windows, the code works fine but when I run it through docker container I am getting following exception:
org.bouncycastle.pkcs.PKCSException: unable to read encrypted data: failed to construct sequence from byte[]: Extra data detected in stream
snowflake-report-sync | at org.bouncycastle.pkcs.PKCS8EncryptedPrivateKeyInfo.decryptPrivateKeyInfo(Unknown Source) ~[bcpkix-jdk15on-1.64.jar!/:1.64.00.0]
snowflake-report-sync | at com.optum.snowflakereportsync.configuration.SnowFlakeConfig.getPrivateKey(SnowFlakeConfig.java:103) ~[classes!/:na]
snowflake-report-sync | at com.optum.snowflakereportsync.configuration.SnowFlakeConfig.getConnectionProperties(SnowFlakeConfig.java:67) ~[classes!/:na]
Following is Dockerfile used:
FROM adoptopenjdk/openjdk11-openj9:latest
COPY build/libs/snowflake-report-sync-*.jar snowflake-report-sync.jar
RUN mkdir /encryption-keys
COPY encryption-keys/ /encryption-keys/ #keys are picked from docker filesystem when running in container
EXPOSE 8080
CMD java -Dcom.sun.management.jmxremote -noverify ${JAVA_OPTS} -jar snowflake-report-sync.jar
Options tried:
Ensured that key file is being read while running in container. Logger "InputStreamExists --> {}" gives number of bytes
Ran dos2unix on key.k8 just to make sure there are no Window's "^M" characters which be could be causing issue as container is linux one : FROM adoptopenjdk/openjdk11-openj9:latest
Not sure what I am doing wrong but any help or pointers would be appreciated.
Like #Bragolgirith suspected, BouncyCastle seems to have problems with OpenJ9. I guess it is not a Docker issue, because I can reproduce it on GitHub Actions, too. It is also not limited to BouncyCastle 1.64 or 1.70, it happens in both versions. It also happens on OpenJ9 JDK 11, 14, 17 on Windows, MacOS and Linux, but for the same matrix of Java and OS versions it works on Adopt-Hotspot and Zulu.
Here is an example Maven project and a failed matrix build. So if you select another JVM type, you should be fine. I know that #Bragolgirith already suggested that, but I wanted to make the problem reproducible for everyone and also provide an MCVE, in case someone wants to open a BC or OpenJ9 issue.
P.S.: It is also not a character set issue with the InputStreamReader. This build fails exactly the same as before after I changed the constructor call.
Update: I have created BC-Java issue #1099. Let's see what the maintainers can say about this.
Update 2: The solution to your problem is to explicitly set the security provider to BC for your input decryptor provider. Thanks to David Hook for his helpful comment in #1099.
BouncyCastleProvider securityProvider = new BouncyCastleProvider();
Security.addProvider(securityProvider);
// (...)
InputDecryptorProvider pkcs8Prov = new JceOpenSSLPKCS8DecryptorProviderBuilder()
// Explicitly setting security provider helps to avoid ambiguities
// which otherwise can cause problems, e.g. on OpenJ9 JVMs
.setProvider(securityProvider)
.build(passphrase.toCharArray());
See this commit and the corresponding build, now passing on all platforms, Java versions and JVM types (including OpenJ9).
Because #Bragolgirith mentioned it in his answer: If you want to avoid the explicit new JceOpenSSLPKCS8DecryptorProviderBuilder().setProvider(securityProvider), the call Security.insertProviderAt(securityProvider, 1) instead of simply Security.addProvider(securityProvider) would in this case also solve the problem. But this holds true only as long as no other part of your code or any third-party library sets another provider to position 1 afterwards, as explained in the Javadoc. So maybe it is not a good idea to rely on that.
Edit:
On second thought, when creating the JceOpenSSLPKCS8DecryptorProviderBuilder, you're not explicitly specifying the provider:
new JceOpenSSLPKCS8DecryptorProviderBuilder()
.setProvider(BouncyCastleProvider.PROVIDER_NAME) // add this line
.build(passphrase.toCharArray());
It seems OpenJ9 uses a different provider/algo selection mechanism and selects the SunJCE's AESCipher class as CipherSpi by default, while Hotspot selects BouncyCastleProvider's AES class.
Explicitly specifying the provider should work in all cases.
Alternatively, when adding the BouncyCastleProvider you could insert it at the first preferred position (i.e. Security.insertProviderAt(new BouncyCastleProvider(), 1) instead of Security.addProvider(new BouncyCastleProvider())) so that it gets selected.
(It's still unclear to me why the provider selection mechanism differs between the different JVMs.)
Original post:
I've managed to reproduce the issue and at this point I'd say it's an incompatibility issue with the OpenJ9 JVM.
Starting from a Hotspot base image instead, e.g.
FROM adoptopenjdk:11-jre-hotspot
makes the code work.
(Not yet entirely sure whether the fault lies with the Docker image itself, the OpenJ9 JVM or BouncyCastle)
I am getting the exception SignatureException: Signature length not correct: got 64 but was expecting 66 when verifying a signature.
I signed the data on a JavaCard:
Signature signature = Signature.getInstance(Signature.ALG_RSA_MD5_PKCS1, false);
KeyPair key = new KeyPair(KeyPair.ALG_RSA, (short)512);
key.genKeyPair();
signature.init(key.getPrivate(), Signature.MODE_SIGN);
signature.sign(dataToBeSigned, offsetOfData, lengthOfData, outputArray, outputoffset);
And I get the exception when I try to verify the signature in a separate Java program
Signature signature = Signature.getInstance("MD5withRSA");
signature.initVerify(publicKey);
signature.update(dataToBeVerified);
boolean verified = signature.verify(signatureToBeVerified);
It seems that signature.verify() expects a signature of length 66, but the signature generated in the JavaCard applet is only 64 bytes long - I can't work out why this is.
Any help as to why the signature generated is too short, or why signature.verify() expects a longer signature would be greatly appreciated.
Edit to add extra information:
bigIntExp: 65537
bigIntMod:132308419546647374128240292677530807315542691147982039135818279043817855879255964354323446465801763768751278796804645533108455181966328171561226049067030642228779581871262216901734159959403381829035369468203140058451522951118452394154357893479460331007989274416039890367651223156420250223950749870305488385775751757831611317020777731747216787964833937998955451058221004606237913446120467690829592472183785281175197045866416933142014254513781922812566056256864142790656
According to the Java 12 security specs here the RSASSA-PSS signature scheme should be supported (actually as of Java 11).
However, if I try to use a signature with PS256 algorithm in my JWT using e.g. the nimbus jose+jwt library, then it doesn't work unless I use BouncyCastle.
val signer = RSASSASigner(signKey)
val jwsObject = JWSObject(
JWSHeader.Builder(JWSAlgorithm.PS256) // PS256 gives error; RS256 will work
.keyID(signKeyId)
.build(),
Payload(json)
jwsObject.sign(signer)
This gives an error:
java.security.NoSuchAlgorithmException: SHA256withRSAandMGF1 Signature not available
And indeed JCASupport.isSupported(JWSAlgorithm.PS256) is false
If I include BouncyCastle then it does work:
Security.addProvider(BouncyCastleProviderSingleton.getInstance())
JCASupport.isSupported(JWSAlgorithm.PS256) == true
I would have thought that BouncyCastle is not necessary anymore in Java 12 (I'm actually using Kotlin 1.3 with Java 12 and Spring Boot 2.2 and com.nimbusds 8.4 to be precise).
I would like to be independent from BouncyCastle.
What am I missing?
I have been given some Python code from the backend that decrypts some data. On my side, the Android app, I need to also decrypt it.
Here are some snippets of the Python code which I believe are the most relevant.
cipher = PKCS1_OAEP.new(privkey)
And this is the module that it comes from
from Crypto.Cipher import PKCS1_v1_5
from Crypto.Cipher import PKCS1_OAEP
Looking at the documentation for PKCS1_OAEP.new
https://www.dlitz.net/software/pycrypto/api/2.6/Crypto.Cipher.PKCS1_OAEP-module.html
And then comparing with the JavaDoc for Cipher
https://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html#Cipher
I deduced that this Python algorithm can be expressed as follows using the Java Cipher class (Note the code is in Kotlin)
val cipher = Cipher.getInstance("RSA/NONE/OAEPWithSHA1AndMGF1Padding", "BC")
Note that BC is the provider. I found out that BouncyCastle is popular and is included in the Android framework
So what is the error?
The backend returns me a 404 when the answer to the challenge is wrong.
When I execute the Python code (which hits the same endpoints) it works.
In terms of the POST request, I compared both and I am sending it in the correct way.
What would I like to know
Am I using the correct algorithm? I am trying to systematically cross out potential issues before moving onto another
Note that I also tried
val cipher = Cipher.getInstance("RSA/NONE/OAEPPadding", "BC")