Develop Reference

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.

How to specify value of AlgorithmParameterSpec in java, for encryption and Decryption puropose, in DES

My qustion is about how should I specify the custom value of AlgorithmParameterSpec in the below program? So that I could use the exact same output value for two different programs, one of which is Server and other is Client. Like I have used the fixed value for Key Generation, I want the same for this AlgorithmParameterSpec.
Client Code Snippet
....
String desKey = "0123456789abcdef"; // value from user
byte[] keyBytes = DatatypeConverter.parseHexBinary(desKey);
SecretKeyFactory factory = SecretKeyFactory.getInstance("DES");
SecretKey key = factory.generateSecret(new DESKeySpec(keyBytes));
AlgorithmParameterSpec paramSpec = new IvParameterSpec(iv);
....
Both client and server are on different pcs and are connected on same LAN. However I dont want to send any file from one to another, and neither do I want to write the value of that parameter from client into any file and use it in server. That has already caused too much problems. Is there a way to do this? Or I have to send this generated value from client to server using readUTF and writeUTF?

Original DES aka single-DES has been broken since last century, and should not be used.
In Java, instantiating plain DES like that defaults to DES/ECB/PKCS5Padding (in general Java treats PKCS5 padding as including PKCS7). ECB does not use an IV, and DES has no other parameters, so a java Cipher object for DES/ECB does not need or use any type of parameters object. However, in most applications, ECB mode even with a good cipher (not DES) is insecure and should not be used.
If you change to a more secure mode that does use an IV, like CTR CBC OFB CFB, or better in most applications but only supported in j8+ GCM, then IvParameterSpec is indeed the correct type to use.
However, with modes that use an IV, using a fixed or otherwise duplicated IV is almost always insecure, so you must have a process that provides a unique IV for each encryption and the corresponding decryption(s).
This is often done by choosing a random IV when encrypting and transmitting and/or storing it along with the ciphertext (sometimes simply as the first part of the ciphertext) to be used when decrypting, but other designs that accomplish the same thing are possible. For CTR-based modes including GCM, especially when applied to a stream of traffic between the same parties, using a (scaled) counter provides uniqueness. For CBC the IVs must not only be unique but unpredictable; random is usually easiest for this but it is possible to use an encrypted counter.
Both key and IV (when used) should actually be bits not characters. However it is often convenient to represent them in characters using hex (as you did) or base64. Such character representations can be transmitted and received by a huge variety of methods, of which DataInput/OutputStream or ObjectInput/OutputStream is one among many. There are also many ways to transmit bits (binary) on all networks used in this century (although back in the 1970s and 1980s this was often problematical). Choosing among these may depend on what else your programs are doing and in particular whether they already use things like HTTP, XML, JSON, etc.

Generate a keypair from a password

I would like to use asymmetric encryption based with a private key based on a password. The requirement is the security level provided must be the same of (1) using password-based symmetric encryption, (2) using asymmetric encryption in a "regular" way.
I will have to use it in Java, but the answer can be generic.
I am aware that I can generate a keypair and encrypt the privateKey with a password-based symmetric key, however, in this way I will need a server (or other storage) to store this encrypted key. I would like to avoid that. If I could generate a keypair from a password, it is not needed.
Any suggestions?

If you base the private key solely on a password, it will only be as strong as the password, i.e. whoever can guess the password can get the private key.
This is comparable to generating a private/public key pair, encrypting the private key with a symmetric cipher and then publishing both together.
This of course makes the whole system weaker, since you no longer need to have the secret token - you only need to know the password.

Every time I see this question or a variant of it asked it's usually the result of bad design decisions. Almost always, the correct answer is to generate a random RSA keypair and protect the private key using standard password-based encryption like PBKDF2 or argon2. I've only seen one use case where this made at least a little sense and that was a cryptographic token back in the day with absolutely no nonvolatile storage. You won't find it around because there's no reason to build such a token, nonvolatile storage is not exotic in 2018.
In general you can do this: java's RSA key generation code accepts an instance of SecureRandom which the Oracle providers use to generate the candidate primes for RSA. You can subclass SecureRandom (I think) to provide a class that uses the password to seed a deterministic, repeatable sequence of random numbers such that every time you call KeyPairGenerator. generateKeyPair() the same keypair (including the private key) is generated. The bouncycastle library includes an example, FixedSecureRandom, that can be used as a model. Note that the deterministic RNG still has to be cryptographically secure, apart from the fact that it will not have enough entropy. FixedSecureRandom is not secure, it simply returns the pre-supplied bytes directly as output. Perhaps you can merge FixedSecureRandom with one of the other CSPRNGs in the org.bouncycastle.crypto.prng package.

Implementing a Pseudorandom Generator using AES

"A pseudorandom generator (PRG) is a deterministic algorithm that takes a short uniformly distributed string, known as the seed, and outputs a longer string that cannot be efficiently distinguished from a uniformly distributed string of that length." [1]
It is my understanding that we can create pseudorandom generators using stream ciphers. For instance, SCAPI, a Secure Multiparty Computation API, uses RC4 in the following example to create an output of a fixed number of bytes (check out.length):
//Create secret key and out byte array
...
//Create prg using the PrgFactory
PseudorandomGenerator prg = PrgFactory.getInstance().getObject("RC4");
SecretKey secretKey = prg.generateKey(256); //256 is the key size in bits.
//set the key
Prg.setKey(secretKey);
//get PRG bytes. The caller is responsible for allocating the out array.
//The result will be put in the out array.
prg.getPRGBytes(out.length, out);
Indeed, pseudorandom generators are particulary useful in some cryptographic protocols (i.e. this protocol) where we need to create a pseudorandom output of bytes, usually of a very large size, fast.
I have actually implemented this protocol using the SCAPI snippet shown above for the PRG part. Yet the authors, instead of using RC4 for their PRG, they use AES128 in CTR mode. Which makes sense since RC4 is known to be broken and since AES can be easily used as stream cipher.
I want to implement a pseudorandom generator using AES in CTR in the same fashion as the snippet above, but I'm unable to do so. My problem is not using AES in CTR, there are countless examples online. My problem is the out.length part. I don't know how to implement a PRG using AES (or any other cipher for that matter) in a way where I get to choose the exact number of output bytes, like the example above. How can I do this?
Before someone mentions that a hash function can do the same job: Indeed, this is basically a hash function but the problem in this particular protocol is that we need very large outputs (i.e. 32MB) where a hash function usually has a fixed output of (192, 256, 512 bits).
Finally, this question is not a duplicate to this one, because the latter is about implementing any kind of PRG in Python where this is one is about implementing an AES_CTR based PRG in Java.
Some useful links:
SCAPI's API
SCAPI's source code on PRGs

In CTR mode you just cut off the bytes you don't need (from the right hand side) of the block encrypt over the last counter. You can create the key stream by performing AES-CTR over the right number (out.length) of zero valued bytes as well.

Check encryption key correctness in JAVA

I'm using BouncyCastle to encrypt/decrypt some files using AES and PKCS5 padding in CBC mode :
Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding", "BC");
Now two questions:
How can I check that the provided key for decrypting data is correct or not ?
How Can I check encrypted input is untouched (e.g. not changed by user using an HEX editor)?
Thanks

You can use an AEAD mode, like CCM or GCM, in place of CBC. These modes authenticate an encrypted message, so if the wrong key is used, or the cipher text has been altered, you can detect it. You wouldn't be able to distinguish these cases though.
There is support in Java 7's cryptography API for GCM, but the SunJCE provider that ships with Oracle's Java implementation doesn't support it yet. You can get support through third-party providers like BouncyCastle.
You can achieve the same things if you use additional cryptographic services, like a digital signature or message authentication code.

Encryption is not just about the algorithm and the encryption key, it's also a lot about
the system organization.
In general, you can't determine that the key is correct. Any key can be used to decrypt the
data that's supposed to be decrypted, but it's up to some other mechanism to tell you if that
is the "correct" result.
In general, you can't determine if the data to be decrypted is untouched, except through some
external check. It's a property of most encryption systems that changing any of the encrypted
data would change the decrypted output drastically, probably into something you'd interpret
as garbage.

You should add a MAC which first verifies the integrity of the message, and only then you should decrypt it. A common choice of MAC is HMAC with whatever hash function you prefer, such as SHA-2.
Instead of doing this yourself, it's often a good idea to use an authenticated cipher. AES-GCM is a common choice. But you need to be really careful to never reuse an IV in that case.

The JCE ciphers are usually very basic. If you need a full featured protection including integrity and key testing, you need to combine them. And as usual it is better to not device that yourself. So better opt for a more high level format like PKCS7/12 or PGP.
Depending on the Padding used some ciphers will give you a PaddingException when you try to decrypt it with the wrong key. For stronger integrity check I would use a padding consiting of HMAC bytes.
A pretty complete method is included in the JCE, it is the AESWrap algorithm. It requires padded data but will ensure integrity. It is best combined with a length byte as described in RFC 3537. Note, that this is only intended for smaller amounts of secrets (like symmetric keys). The RFC3537 padding is restricted to 255 bytes.
To use this with a password derived key, you can use this:
char[] pass = ... // your password
byte[] codeBytes = ... // up to 255 bytes you want to protect
// generate wrapping key from password
SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
SecureRandom rand = SecureRandom.getInstance("SHA1PRNG");
byte[] salt = new byte[16]; rand.nextBytes(salt);
SecretKey kek = f.generateSecret(new PBEKeySpec(pass, salt, 1000, 128));
kek = new SecretKeySpec(password.getEncoded(), "AES"); // convert into AES
// RFC3537 padding (lengthbyte)
byte[] wrappedCodeBytes = new byte[codeBytes + 1 % 8];
System.arraycopy(codeBytes,0,wrappedCodeBytes,1,wrappedCodeBytes.length);
paddedCodeBytes[0]=(byte)codeBytes.length;
byte[] pad = new byte[paddedCodeBytes.length - codeBytes.length -1]; rand.nextBytes(pad);
System.arraycopy(pad,0,paddedCodeBytes,codeBytes.length+1,pad.length);
// AESWrap is WRAP_MODE:needs a SecretKey
SecretKey paddedCodeKey = new SecretKeySpec(paddedCodeBytes, "RAW");
// now wrap the password with AESWrap kek is 128 bit
Cipher c = Cipher.getInstance("AESWrap"); // default IV
c.init(Cipher.WRAP_MODE, kek);
byte[] result = c.warp(paddedCodeKey);
The unwrapping is left for the reader as an exercise :) The example code uses 128bit keysize, since more entropy cant be expected from the PBKDF2 anyway.
Note that this will detect wrong passwords with high probability, and some critics will see this as a weakness of AESWrap.

Take a look at this tutorial on BC encryption, specifically the InitCiphers methods, and in detail at the second code block which specifies the actual type of cipher.
How can I check that the provided key for decrypting data is correct or not?
According to JCE Javadocs, specifically the constructor of Class SecretKeySpec:
This constructor does not check if the given bytes indeed specify a secret key of the specified algorithm. For example, if the algorithm is DES, this constructor does not check if key is 8 bytes long, and also does not check for weak or semi-weak keys. In order for those checks to be performed, an algorithm-specific key specification class (in this case: DESKeySpec) should be used.
Note that Interface KeySpec lists all implementing classes, basically a list of validation options.
How Can I check encrypted input is untouched (e.g. not changed by user using an HEX editor)?
Indeed. That's a good one. 'Input' is pretty generic. Do you mean the actual content to decrypt? Well, if it's munged I believe it will not decrypt properly. Does that make sense?
IFF you are talking about the case of a key with parity bits being altered, as described in item (6) at the Bouncy Castle FAQ, you will have to do an actual parity check on the key. Only the first 56 bytes of the key are used for the encryption ops, and the last 8 bytes are reserved for parity checking. So, essentially, the last part of the 'key' can be changed and the first part is still useful. To detect whether either the parity or the key have been altered, you would run a parity check. I found this little ditty on doing a parity check. And, for more info on how parity is set in these keys, see comments in the JDK7 Crypto Provider source for Class DESKeyGenerator by Jan Luehe (near bottom) which discuss parity setting.
I recently had some interaction with BC, and I hope this info helps.