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 encrypt a string using Jasypt 1.9.3 and my JDK version is 1.8.0_281.
This is the code I am have written:
Security.setProperty("crypto.policy", "unlimited");
if (pooledPBEStringEncryptor == null) {
pooledPBEStringEncryptor = new PooledPBEStringEncryptor();
pooledPBEStringEncryptor.setPassword(encryptionKey);
pooledPBEStringEncryptor.setAlgorithm("PBEWITHHMACSHA512ANDAES256");
pooledPBEStringEncryptor.setPoolSize(4);
pooledPBEStringEncryptor.setSaltGenerator(new RandomSaltGenerator());
}
encrypted = pooledPBEStringEncryptor.encrypt(cValue);
But when I run it, I get the error
Exception in thread "main" java.lang.RuntimeException: Security Error in doEncrypt: org.jasypt.exceptions.EncryptionInitializationException: java.security.NoSuchAlgorithmException: PBEWITHHMACSHA512ANDAES256 SecretKeyFactory not available
I ran the AlgorithmRegistry.getAllPBEAlgorithms() and my output is:
PBEWITHHMACSHA1ANDAES_128, PBEWITHHMACSHA1ANDAES_256, PBEWITHHMACSHA224ANDAES_128, PBEWITHHMACSHA224ANDAES_256, PBEWITHHMACSHA256ANDAES_128, PBEWITHHMACSHA256ANDAES_256, PBEWITHHMACSHA384ANDAES_128, PBEWITHHMACSHA384ANDAES_256, PBEWITHHMACSHA512ANDAES_128, PBEWITHHMACSHA512ANDAES_256, PBEWITHMD5ANDDES, PBEWITHMD5ANDTRIPLEDES, PBEWITHSHA1ANDDESEDE, PBEWITHSHA1ANDRC2_128, PBEWITHSHA1ANDRC2_40, PBEWITHSHA1ANDRC4_128, PBEWITHSHA1ANDRC4_40
When I use the algorithm PBEWITHHMACSHA256ANDAES_256 I get a different error.
Exception in thread "main" java.lang.RuntimeException: Security Error in doEncrypt: org.jasypt.exceptions.EncryptionOperationNotPossibleException
I am a little lost as to what to do.
I have downloaded the unlimited policy jars from Oracle and saved them in JAVA_HOME\jre\lib\security\ folder. And I am on Windows.
The code lacks the specification of the IV generator with setIvGenerator(), e.g.:
pooledPBEStringEncryptor.setIvGenerator(new RandomIvGenerator());
By default, NoIvGenerator is used, which causes the exception because the algorithm applies the CBC mode, which requires an IV.
The default salt generator, by the way, is RandomSaltGenerator, so this would not necessarily need to be specified with setSaltGenerator().
The PooledPBEStringEncryptor#encrypt() method returns the Base64 encoded concatenation of salt (16 bytes), IV (16 bytes) and ciphertext.
The exception org.jasypt.exceptions.EncryptionOperationNotPossibleException is a general exception that is generated in many error situations and is therefore not very meaningful, see here. This includes e.g. the missing of the JCE Unlimited Strength Jurisdiction Policy (which however seems to be installed on your system).
For completeness: The algorithm is called PBEWITHHMACSHA512ANDAES_256 (which you have already figured out yourself).
PBEWITHHMACSHA512ANDAES_256 derives a 32 bytes key for AES-256 from password and salt using PBKDF2. HMAC/SHA512 is applied. Since not explicitly specified, the default iteration count of 1000 is used. The algorithm applies the CBC mode for encryption (which is why the IV is needed).
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")
MessageDigest.getInstance("SHA") seems to work and gives me a MessageDigest, but I can't tell what algorithm it's giving me.
Is it SHA-1 or SHA-0 or ..?
I'm not interested in what happens on my machine. I want to know whether it will return sha0 or sha1 for all valid implementations of Java (or it's undefined).
The JCE Specification lists standard names that an implementation is expected to support. "SHA-1" is specified, as are SHA-256, SHA-384, and SHA-512. "SHA", "SHA-0" and SHA-2" are not standard names and therefore may not be supported at all. You cannot guarantee what "SHA" will return, if anything at all, because it is not in the standard.
SHA-0 is obsolete. For use with the Java JCE MessageDigest, SHA == SHA-1 for some JCE providers. By the way, SHA-1 is not considered to be secure with today's computers and technology. SHA-512 is still secure for pretty much anything. SHA-256 is ok for most things, still.
You can list the protocols available in the Java version you are using with this code. (I got it here ):
import java.security.Provider;
import java.security.Security;
public class JceLook {
public static void main(String[] args) {
System.out.println("Algorithms Supported in this JCE.");
System.out.println("====================");
// heading
System.out.println("Provider: type.algorithm -> className" + "\n aliases:" + "\n attributes:\n");
// discover providers
Provider[] providers = Security.getProviders();
for (Provider provider : providers) {
System.out.println("<><><>" + provider + "<><><>\n");
// discover services of each provider
for (Provider.Service service : provider.getServices()) {
System.out.println(service);
}
System.out.println();
}
}
}
It will show information like this for all the various algorithms available. (Note that this is actual output from the program above for some update level of Oracle/Sun Java 6 and it shows that SHA is equivalent to SHA-1 and SHA1. You can pass any of the three strings to MessageDigest and get the same result. But this depends on the Cryptography Provider (the JCE) and might not be the same.)
SUN: MessageDigest.SHA -> sun.security.provider.SHA
aliases: [SHA-1, SHA1]
attributes: {ImplementedIn=Software}
If you load additional providers (e.g. BouncyCastle) it will show those too.
I'm playing around with BouncyCastle 1.46 To my surprise, the catch-block in the snippet below is tripped quite often.
Security.addProvider(new BouncyCastleProvider());
final Set<String> found = new HashSet<String>();
final Set<String> missing = new HashSet<String>();
final DefaultSignatureAlgorithmIdentifierFinder finder = new DefaultSignatureAlgorithmIdentifierFinder();
for (Service service : new BouncyCastleProvider().getServices()) {
if ("Signature".equals(service.getType())) {
final String algorithm = service.getAlgorithm();
try {
finder.find(algorithm);
found.add(algorithm);
} catch (IllegalArgumentException ex) {
missing.add(algorithm);
}
}
}
System.out.println("Found: " + found);
System.out.println("Missing: " + missing);
I appear to be unable to use most of the algorithms through the Finder, even though Services exist that provide those algorithms. What am I doing wrong?
Update I've changed the code a little to illustrate the issue better. What might be of interest is that I am using the JDK1.5 version of BouncyCastle. The code above gives this output:
Found: [RIPEMD256WithRSAEncryption, MD5WithRSAEncryption, MD2WithRSAEncryption, SHA384WithRSAEncryption, SHA224WITHECDSA, SHA384WITHDSA, SHA256WITHDSA, SHA512WithRSAEncryption, SHA512WITHDSA, RIPEMD160WithRSAEncryption, SHA224WithRSAEncryption, SHA256WITHECDSA, RIPEMD128WithRSAEncryption, SHA384WITHECDSA, SHA256WithRSAEncryption, SHA512WITHECDSA, SHA1WithRSAEncryption, SHA224WITHDSA]
Missing: [SHA1WITHECNR, NONEwithECDSA, ECDSA, SHA512withRSA/PSS, RIPEMD160WITHECDSA, RSA, GOST3410, SHA256WITHECNR, MD5withRSA/ISO9796-2, SHA1WITHCVC-ECDSA, SHA384withRSA/PSS, SHA1withRSA/PSS, MD4WithRSAEncryption, RSASSA-PSS, SHA512WITHECNR, SHA256WITHCVC-ECDSA, SHA1withRSA/ISO9796-2, SHA224withRSA/PSS, SHA224WITHCVC-ECDSA, RAWRSASSA-PSS, SHA256withRSA/PSS, NONEWITHDSA, SHA384WITHECNR, RIPEMD160withRSA/ISO9796-2, DSA, ECGOST3410, SHA224WITHECNR, 1.2.840.113549.1.1.10]
I think that DefaultSignatureAlgorithmIdentifierFinder is part of the bcmail API. It returns algorithm identifiers recognized by this API. (Check Cryptographic Message Syntax) On the other hand the bouncy castle provider provides more algorithms. You may check the source of DefaultSignatureAlgorithmIdentifierFinder where the recognized algorithms are hardcoded:
algorithms.put("MD2WITHRSAENCRYPTION", PKCSObjectIdentifiers.md2WithRSAEncryption);
algorithms.put("MD2WITHRSA", PKCSObjectIdentifiers.md2WithRSAEncryption);
algorithms.put("MD5WITHRSAENCRYPTION", PKCSObjectIdentifiers.md5WithRSAEncryption);
algorithms.put("MD5WITHRSA", PKCSObjectIdentifiers.md5WithRSAEncryption);
algorithms.put("SHA1WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha1WithRSAEncryption);
algorithms.put("SHA1WITHRSA", PKCSObjectIdentifiers.sha1WithRSAEncryption);
algorithms.put("SHA224WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha224WithRSAEncryption);
algorithms.put("SHA224WITHRSA", PKCSObjectIdentifiers.sha224WithRSAEncryption);
algorithms.put("SHA256WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha256WithRSAEncryption);
algorithms.put("SHA256WITHRSA", PKCSObjectIdentifiers.sha256WithRSAEncryption);
algorithms.put("SHA384WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha384WithRSAEncryption);
algorithms.put("SHA384WITHRSA", PKCSObjectIdentifiers.sha384WithRSAEncryption);
algorithms.put("SHA512WITHRSAENCRYPTION", PKCSObjectIdentifiers.sha512WithRSAEncryption);
algorithms.put("SHA512WITHRSA", PKCSObjectIdentifiers.sha512WithRSAEncryption);
algorithms.put("SHA1WITHRSAANDMGF1", PKCSObjectIdentifiers.id_RSASSA_PSS);
algorithms.put("SHA224WITHRSAANDMGF1", PKCSObjectIdentifiers.id_RSASSA_PSS);
algorithms.put("SHA256WITHRSAANDMGF1", PKCSObjectIdentifiers.id_RSASSA_PSS);
algorithms.put("SHA384WITHRSAANDMGF1", PKCSObjectIdentifiers.id_RSASSA_PSS);
algorithms.put("SHA512WITHRSAANDMGF1", PKCSObjectIdentifiers.id_RSASSA_PSS);
algorithms.put("RIPEMD160WITHRSAENCRYPTION", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd160);
algorithms.put("RIPEMD160WITHRSA", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd160);
algorithms.put("RIPEMD128WITHRSAENCRYPTION", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd128);
algorithms.put("RIPEMD128WITHRSA", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd128);
algorithms.put("RIPEMD256WITHRSAENCRYPTION", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd256);
algorithms.put("RIPEMD256WITHRSA", TeleTrusTObjectIdentifiers.rsaSignatureWithripemd256);
algorithms.put("SHA1WITHDSA", X9ObjectIdentifiers.id_dsa_with_sha1);
algorithms.put("DSAWITHSHA1", X9ObjectIdentifiers.id_dsa_with_sha1);
algorithms.put("SHA224WITHDSA", NISTObjectIdentifiers.dsa_with_sha224);
algorithms.put("SHA256WITHDSA", NISTObjectIdentifiers.dsa_with_sha256);
algorithms.put("SHA384WITHDSA", NISTObjectIdentifiers.dsa_with_sha384);
algorithms.put("SHA512WITHDSA", NISTObjectIdentifiers.dsa_with_sha512);
algorithms.put("SHA1WITHECDSA", X9ObjectIdentifiers.ecdsa_with_SHA1);
algorithms.put("ECDSAWITHSHA1", X9ObjectIdentifiers.ecdsa_with_SHA1);
algorithms.put("SHA224WITHECDSA", X9ObjectIdentifiers.ecdsa_with_SHA224);
algorithms.put("SHA256WITHECDSA", X9ObjectIdentifiers.ecdsa_with_SHA256);
algorithms.put("SHA384WITHECDSA", X9ObjectIdentifiers.ecdsa_with_SHA384);
algorithms.put("SHA512WITHECDSA", X9ObjectIdentifiers.ecdsa_with_SHA512);
algorithms.put("GOST3411WITHGOST3410", CryptoProObjectIdentifiers.gostR3411_94_with_gostR3410_94);
algorithms.put("GOST3411WITHGOST3410-94", CryptoProObjectIdentifiers.gostR3411_94_with_gostR3410_94);
algorithms.put("GOST3411WITHECGOST3410", CryptoProObjectIdentifiers.gostR3411_94_with_gostR3410_2001);
algorithms.put("GOST3411WITHECGOST3410-2001", CryptoProObjectIdentifiers.gostR3411_94_with_gostR3410_2001);
algorithms.put("GOST3411WITHGOST3410-2001", CryptoProObjectIdentifiers.gostR3411_94_with_gostR3410_2001);
Cheers!
Did you add BouncyCastle to the security providers? You can do that with this line:
Security.addProvider(new BouncyCastleProvider());
This answer is not directly related to BouncyCastle. But, I thought this would be useful for others:
In my case, I was using SpongyCastle. I got a similar problem:
org.e.h.p: cannot create signer: Provider SC does not provide SHA256WITHRSA
at org.e.h.a.a.a(SourceFile:101)
It turned out that proguard was removing some of the required classes. After adding the following in proguard config file:
-keep class org.spongycastle.** { *; }
the problem was resolved.
You can add Bouncy Castle to security providers on Your java platform in two steps:
1. Copy BC librarys (currently bcpkix-jdk15on-149.jar, bcprov-jdk15on-149.jar) to directory $JAVA_HOME/jre/lib/ext/
2. Register BC provider: edit file $JAVA_HOME/jre/lib/security/java.security and under line
security.provider.1=sun.security.provider.Sun
add Your BC provider
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
Change numbers of rest providers. The whole block of providers should be similar to:
security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=sun.security.ec.SunEC
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.6=com.sun.crypto.provider.SunJCE
security.provider.7=sun.security.jgss.SunProvider
security.provider.8=com.sun.security.sasl.Provider
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.10=sun.security.smartcardio.SunPCSC