Encryption in Java and decryption in PHP - java

I have to decrypt string in PHP, which is being generated from Java class. And I am not able to understand what exactly is being done in that class. Java class used for encryption-decryption
Can someone suggest me the equivalent code or process to decrypt the encrypted string.

that Java class seems to do a DES encryption.
In PHP you can do:
$result=mcrypt_decrypt ( "MCRYPT_DES" , $key , $data , $mode);
The $key and $mode variables are information you should know, $data is the input encrypted string. You may want to try MCRYPT_3DES if the other one doesn't work.

Well, if even you don't seem to know, which encryption algorithm is used, it's hard for us to help you. I'm not familiar with the code and the classes which are used there but it seems that DES is used (no shit) in a weird combination with Base64. Search for DES decryption with PHP, also PHP has functions for handling Base64-String.
You can also search for what SecretKeyFactory.getInstance("PBEWithMD5AndDES").generateSecret(keySpec); does.

The code you linked generates an encryption key using a salt, passphrase and the number of md5 iterations.
With the encryption key you can encrypt / decrypt.
A couple of years ago I implemented a php version of the used algorithm PBEWithMD5AndDES: https://github.com/kevinsandow/PBEWithMD5AndDES

Related

jBCrypt Encrypt and Decrypt

I came to know about jBCrypt for hashing a password and storing in DB. But I didnt find any option to get back the actual value from the hashed value. Only BCrypt.checkpw(password, hashedPassword) is available which is returning boolean.http://www.mindrot.org/projects/jBCrypt/
How can I get the actual value out of hashed value.
If it is not possible in jBCrypt, is there any other way to encrypt and decrypt values in java? Thanks in advance...
Instead of using a hash function, you can use a symmetrical encryption algorithm, like offered by Spring Security, from their Crypto Module, more specifically their Encryptors class.
Here is a basic encryption/decryption example:
public static void main(String[] args) {
final String salt = UUID.randomUUID().toString().replace("-", "");
TextEncryptor textEncryptor = Encryptors.delux("my-super-secure-password-for-the-encryptor", salt);
final String passwordToBeEncrypted = "my-secure-password-to-be-encrypted";
final String encrypted = textEncryptor.encrypt(passwordToBeEncrypted);
textEncryptor.decrypt(encrypted);
System.out.println(passwordToBeEncrypted.equalsIgnoreCase(textEncryptor.decrypt(encrypted)));
}
Here, I am using the delux. As per their documentation:
Creates a text encryptor that uses "stronger" password-based
encryption.
Keep in mind that this is a very naive approach of encrypting and decrypting.
I would not recommend you copy paste this solution in your production code.
In order for this functionality to be production ready, you want the password provided to the Encryptors.delux() to be stored somewhere safe.
Also, you also want to use a different way of generating a salt for your password (potentially a salt for each new password encryption) and storing it for later where you want to decrypt your password.
Also, you might want to not keep the password in plain text (String), but keeping it as char[] or byte[], but this should give a start from where you can start.
There is also a different library that does the same, from Apache, Apache Commons Crypto, which does utilize the same algorithms as Spring Crypto.
Keep in mind, you are more safe in using a library instead of implementing yourself, since using package javax.crypto will require you to know what you are doing and not do more harm than needed.
Side note: You might bump into the situation that your jdk is limited to 128 bits. To benefit from the 256bits, make sure you add the Java Cryptography Extension
The definition of a hash function has resistance to preimages: given h(x), it should be impossible to recover x. A hash function being "reversible" is the exact opposite of that property. Therefore, you cannot reverse hash function hence it is not possible to get actual value from hashed value.You cannot get x from h(x),only thing you can do is for the coming new password y compute h(y) and see if it is equal to h(x).
Not just jBcrypt any secured hash function won't provide this functionality of recovery
But I didnt find any option to get back the actual value from the hashed value
Well - that's the primary purpose of the cryptographic hash functions.
is there any other way to encrypt and decrypt values in java? Thanks in advance...
There are a lot of examples to encrypt / decrypt values in Java, just search for it, even here on SO. You may as well have a look into my blog about encryption in Java - it's about basic low level crypto API.
I hope you don't mean to use encryption for user passwords - even remote possibity to make the passwords reversible would make your system potentially dangerous for leaks.

ccrypt will not decrypt ccrypt-j encrypted files

I've been trying to fix ccrypt-j, a pure-java implementation of the linux ccrypt command. I found there is some problem with the initialization vector (IV) which makes ccrypt not decrypt anything but its own output.
I modified both libraries so that the same nonce is always fed to both implementations of the Rijndael engine, however, the output IV is always different between implementations, i.e. both libraries always have the same result (because Rijndael is deterministic), but those results are always different.
I know the problem is only the way ccrypt generates the IV since:
ccrypt-j-encrypted can be decrypted from ccrypt-j
If I substitute the IV (first 32 bytes of the encrypted files) with that of a ccrypt-encrypted file, ccrypt will decrypt it just fine.
Ccrypt uses its own implementation of Rijndael coded in C, while ccrypt-j uses Bouncy Castle's implementation.
EDIT: 04/01/2016
Because the IV is constructed before any data is encrypted (actually, any data is even read) I believe the problem has to be in the way Rjindael is initialized in both Bouncy Castle and ccrypt's own implementation. I'll try to do the same sequence in both implementations and see what I get.
One half-answer
if you look at the old ccrypt, there are some explanations about IV. if I resume, 4 bytes are fixed - magic number -, it si c051 for a while. Issues about securities are also discussed:
magic number : see that
http://ccrypt.sourceforge.net/faq.html
ccrypt comes from emacs / jka-compr:
http://www.opensource.apple.com/source/emacs/emacs-51/emacs/lisp/jka-compr.el
In ccrypt, the seed is constructed as follows: first, a nonce is
contructed by hashing a combination of the host name, current time,
process id, and an internal counter into a 28-byte value, using a
cryptographic hash function. The nonce is combined with a fixed
four-byte "magic number", and the resulting 32-byte value is encrypted
by one round of the Rijndael block cipher with the given key. This
encrypted block is used as the seed and appended to the beginning of
the ciphertext. The use of the magic number allows ccrypt to detect
non-matching keys before decryption.
magic number there: http://ccrypt.sourcearchive.com/documentation/1.7-7/ccryptlib_8c-source.html
It seems magic number doesnt change (same from 1.1 to 1.10, before, I dont know).
So what ?
ccrypt is designed to be compatible with precedent versions (emacs , ...). It can crypt and decrypt, and is widely used.
Then problem come from ccrypt-j.
what one can see on sourceforge is 2 important things :
1 compatibility
Encrypting a file using ccrypt-j
TODO
Decrypting a file using ccrypt-j
TODO
so what works really ?
2 in fact, it uses bouncy castle, which is well used, and surely implements standards well.
So conclusion ?
you cant hope ccrypt will change.
then: you can decrypt ccrypt by ccrypt-j
but if you want to decrypt by ccrypt, you have to limit ccrypt-j
I doubt about your assertion, because it would be magical !
If I substitute the IV (first 32 bytes of the encrypted files) with
that of a ccrypt-encrypted file, ccrypt will decrypt it just fine.
But if it works, why not use that ? (ccrypt-j can also decrypt ?)
last advice: contact ccrypt-j support
hope it helps

RSA_PKCS1_OAEP_PADDING equivalent for Java

Currently i use the encryption instance in Java like this:
Cipher cipher = Cipher.getInstance("RSA");
But i cannot decrypt my encrypted message in OpenSSL where i want to use RSA_PKCS1_OAEP_PADDING.
What do i need to add to the "RSA" to be able to use the RSA_PKCS1_OAEP_PADDING?
Please help
Have you tried using "RSA/NONE/OAEPPadding" in getInstance()?
Otherwise, take a look at Java Cryptography Architecture Standard Algorithm Name Documentation to find a list of possible parameters.

Java Crypto API equivalent to Ruby's OpenSSL (via encrypted_strings library)

I am trying to decrypt an encrypted message that is encrypted in a Ruby web app using the encrypted_strings RubyGem library.
The encryption client code looks like this:
cipher = EncryptedStrings::SymmetricCipher.new(:passphrase => "abcdefgh"*2)
cipher.encrypt("howdy")
=> "jEUQrH58Ulk=\n"
The default symmetric cipher algorithm appears to be DES-EDE3-CBC (although the documentation for the RubyGem disagrees, but I will go with what the code says). So on the Java side I tried the following which I found online as an example of DES-EDE3-CBC usage of the Java Cryptography API:
import javax.crypto.spec.DESedeKeySpec
import javax.crypto.spec.IvParameterSpec
import javax.crypto.Cipher
import javax.crypto.SecretKeyFactory
...
DESedeKeySpec k;
Cipher c;
...
k = new DESedeKeySpec("abcdefghabcdefgh".getBytes());
c = Cipher.getInstance("DESede/CBC/PKCS5Padding");
c.init(Cipher.DECRYPT_MODE, k);
decrypted = c.doFinal("jEUQrH58Ulk=\n".getBytes());
When I do this on the Java side I get the following:
Wrong key size
I also tried using the Java Crypto API with an initialization vector but didn't know what I should set the bytes to since I am not doing this on the Ruby side via the encrypted_strings library and it appears to be set in the C code interfacing with OpenSSL.
Any pointers would be much appreciated.
I am using the bouncy castle JCA provider. I also tried DES/ECB/PKCS5Padding (which corresponds with the documented default algorithm in the RubyGems documentation eventhough the code appeared to be referencing the previously mentioned algorithm, DES-EDE3-CBC).
I have tried reading around the Java crypto API, but the documents all seem to have the same code samples and not very many new clues. My sources include:
http://www.angelfire.com/tx4/cus/notes/javaxcrypto.html
http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html
I'll post it as an answer. With DESede you can use either 192 bit DES ABC keys or 128 bit ABA keys. Many versions of Java only accept 192 bit (24 byte) DES ABC keys. DES ABA keys is where the first and last key of the encrypt, decrypt, encrypt (EDE) operation is the same; in other words, it's the same as DESede with ABC, where C=A.
So to create such a key, you can copy the first 8 bytes (in your case 8 ASCII characters - using characters directly as key is wrong) of your key and concatenate them at the end. This would result in "abcdefghabcdefghabcdefgh".getBytes("ASCII"). Note that you should always indicate the character encoding, as the platform might as well use UTF-16 as default character encoding, resulting in a key of double the size.

PBE Parameters for Compatibility with Java's OpenSSL.encrypt() Function

I am attempting to write C code using the openssl libraries to decrypt data that has been encrypted by the Java function OpenSSL.encrypt(). I know the password, but I have not been able to figure out the parameters for PBE.
I am attempting to use the EVP_BytesToKey() function, but I don't know which algorithm to use (MD2, MD5, SHA1?) or how many rounds to properly derive the key and iv from the password. Everywhere I have looked says the Java function is compatible with "openssl enc", but I can't find what parameters it uses either.
I have also looked at PKCS#5, which is what is supposedly implemented, but it doesn't specify a default for algorithm or number of rounds. Please help!
Edit:
Nevermind, finally found parameters that work - MD5 with one round.

Categories

Resources