Develop Reference

Key wrapping with an ECDH public key?

Preface: I don't know whether it's more appropriate to ask this question here or on the Crypto site. Feel free to move or delete or whatever the appropriate SE action is.
I've been asked to help update some encryption software. Broadly speaking, the software already does the following steps, none of which are particularly unusual. I've left out the error handling and Provider arguments for simplicity of posting:
1) Generates a random symmetric secret key for use with AES-128 (or AES-256, mutatis mutandis):
KeyGenerator keygen = KeyGenerator.getInstance("AES");
keygen.init (128, a_SecureRandom_instance);
SecretKey sessionKey = keygen.generateKey();
2) Wraps the symmetric secret key, depending on whether the user is using...
2a) ...an RSA public key from a keypair:
// OAEP wasn't used in this software for hysterical raisins
Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding");
wrapper.init (Cipher.WRAP_MODE, user_RSA_PublicKey);
2b) ...a passphrase:
SecretKey stretched = ...passphrase stretched through a PBKDF like bcrypt...;
// I don't remember whether it's specified as "AES" or "AESWrap" here
Cipher wrapper = Cipher.getInstance("AES or AESWrap/ECB/NoPadding");
wrapper.init (Cipher.WRAP_MODE, stretched);
2c) Either route, the session key is wrapped:
byte[] wrapped = wrapper.wrap(sessionKey);
3) The session key is used to create a Cipher using Cipher.ENCRYPT_MODE along with a random IV, and then shedloads of data are run through it. That part is pretty standard but I can post it if you really want to see CipherInputStream usage. The wrapped session key is stored along with the encrypted data and a bunch of HMACs of everything under the sun.
Later at decryption time, the user provides either the RSA private key, or the passphrase for stretching; the software unwraps the symmetric key and decrypts the data.
All of that has been working for some time. But of course RSA keypairs are getting big and slow, so they'd like to support an additional possibility for step #2 above, in which the public keys are generated using an elliptic curve algorithm (P384 ECDH is the usual case). And this is where we're getting confused.
There doesn't seem to be a JCE replacement algorithm/transformation for elliptic curves in the Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding") invocation. The only one listed in the Java documentation is "ECIES", which seems(?) to be aimed more towards multiple party key agreement?
All of the APIs that I can find for the Java builtin JCE, or even looking over Bouncy Castle, only mention ECDH keys in the context of key agreement and transport, where they're used to generate a symmetric secret key instead of wrapping an existing one.
I feel we're missing something here, possibly because of poor assumptions. Is Cipher.wrap() genuinely not an option with ECDH keys? Or it is, but we need to do something funky in order to create the ECIES Cipher instance?

RSA is an algorithm (or depending on how you look at it, two very similar but distinct algorithms) for encryption and signature. RSA encryption can encrypt dat which is a (lower-level) key, in which case it is called wrapping.
DH is a key agreement algorithm, in both its classical (aka integer, Zp, modp, or finite-field/FF) form and its elliptic-curve form (ECDH). Note that at least for classic DH the raw agreement value g^a^b mod n = g^b^a mod n has enough mathematical structure people aren't comfortable using it directly as a key, so we run it through a key derivation function, abbreviated KDF. It's not clear to me that ECDH values really need KDF, at least for the commonly used X9/NIST curves including P384 (you might look or ask on crypto.SX if you care), but using a KDF is cheap and well-established so we do so.
I've never heard anyone competent call (EC)DH key transport, because it is specifically NOT. It is included in key exchange, a term created to cover the (useful) union of transport and agreement.
You can create an encryption scheme using (EC)DH by using the agreed (and derived) value as the key for symmetric encryption -- and that is (EC)IES. I don't know what made you think IES is something else. Modern practice is that the symmetric encryption should be authenticated, and the standardized forms of IES as a separate scheme use CBC encryption with HMAC authentication, although you could validly design a scheme that uses e.g. GCM instead.
As you saw, the BouncyCastle provider provides implementations of DH (classic) or EC IES "with{AES,DESEDE}-CBC" (in versions before 1.56 the -CBC was sometimes omitted) which use KDF2 from P1363a with SHA1, the indicated CBC cipher, and HMAC-SHA1. The 'standard' (Sun/Oracle/Open) providers do not, but you can combine the raw agreement operation, the KDF, plus symmetric encryption and MAC to produce the same result.
This is similar (though different in some details) to the operation of CMS-formerly-PKCS7 with classic DH and ECDH and PGP with ECDH. (PGP does not support classic DH; it used ElGamal encryption instead as the alternative to RSA.) Not to mention TLS (sometimes through 1.2, always in 1.3) and SSH which use either classic or EC DH 'exchange' (here interactive, and usually ephemeral-ephemeral instead of having at least the receiver static) to produce a secret which is derived and used as key material for symmetric encryption with authentication of the data.

Encryption using AES 256 and SHA-2

I have a situation where I need to first encrypt a message using a public key and vector, that is already provided. Also as per requirement I need to use SHA-2 as well. For now, I am assuming that I need to hash the encrypted message and then send to the server. I have two questions related to this
1. Is it wise to hash the encrypted message? Also, will sending the encrypted message and hashed value to the server be a good idea?
2. I have done a lot search on internet, but whenever I try to get some example of using AES 256 and SHA-2 together, I actually land up where the difference between the two is explained. Can any help me with some sample code?
Thanks in Advance!!!

Let's break down the stuff first.
Public Key Cryptography
Allows a given pair (Kpriv, Kpub) to be used on a cipher to encrypt and decrypt data.
Any data encrypted with Kpriv can only be decrypted with Kpub and any data encrypted with Kpub can only be decrypted with Kpriv.
A nice and well known example of a public key cipher is RSA.
Asymmetric cryptography requires extremely large keys in order to be secure, such that it's extremely slow to execute! You should never encrypt large amount of data with Asymetric keys cryptography. You can use it in the beginning of a connecition to exchange a symetric key Ks, though.
Symetric Key Cryptography
Allows a Ks to be used on a cipher to encrypt and decrypt data.
An example of a symetric cipher is AES. AES is in fact so versatile you can change lots of parameters, such as, (as you mention) the Blocksize which can be of 128, 192 or 256 bits. AES256 is the AES cipher configured with a blocksize of 256 bits.
The block size is what's used against the provided Ks to perform the actual encryption. Note that your data can be larger than the block size (the algorithm will still work, It'l simply reuse the same Ks). Simply reusing the key every block is known as ECB mode and can reveal patterns if your data is repetitive. An alternative is to use modes like CBC or CTR which rely on also using previous block data and XORing with the next block data, to eliminate such patterns. What mode should you use depends on your data.
Note that, according to your cipher mode, you eventually will need padding. I'm assuming you are already quite familiar with this terms when you asked that question.
Guarantees By Cryptography
Cryptography does guarantee that the encrypted data is confidential but that's just it. It does not give any other guarantees such as whether the data is authentic or whether it has been tampered with or not.
While tampering data will most likely result in unintelligible text even after decryption, in cryptography, there's no such thing as invalid plaintext. As such, you need some mechanism to know if your data is valid or not.
A secure hash algorithm such as SHA can help you know whether your decrypted data is valid or not.
However, for these purposes, you usually shouldn't directly use a Digest algorithm. Try to instead use a MAC. That MAC can use SHA256 algorithm but MAC's and Hashes are not exactly the same.
How To Do It In Practice
If all you want is confidentiality and tampering detection, you would use the cipher and digest (or hash) algorithm as such:
E ks ( SHA(data) || data )
Where E is a symmetric cipher, ks is the shared symmetric key, SHA(data) is the digest of data using a secure hash algorithm, || means concatenation and data is a byte array.
A more safer approach would be:
E ks ( MAC mk(data) || data )
Where mk is the MAC's secret key.
Now just search how to "java symetric cipher" and "java hash byte array" and use the two as I'm describing above.

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.

Convert a string into a key

Is there a way to convert a string into a key so I can have the same encryption key for encoding/decoding? I do not mean using SecretKey btw.
Key symKey = KeyGenerator.getInstance(algorithm).generateKey();
I am using the DES algorithm btw

You probably mean a key derivation from a password. A popular approach is to use PBKDF2 in Java as discussed for example here. Don't forget to set the iteration count high to complicate brute-force attacks and set a random salt to prevent dictionary attacks.
A random salt is mandatory by now during user authentication, but it may also be used during encryption. It is just another public value that is added to the ciphertext like the IV for CBC mode.
Other alternatives would be bcrypt and scrypt which require additional libraries in Java.

What's happening in the line of code?

What's happening in this line of code ?
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
I specially don't understand getInstance("PBKDF2WithHmacSHA1") part

This funky looking string defines the secret-key algorithm to be used. It is:
PBKDF2WithHmacSHA1
PBKDF2 With Hmac SHA1
the PBKDF2 function (from PKCS#5 version 2.0)
which will be using SHA-1 HMAC for its pseudo-random number generator
References:
We find similar algorithm names in Java Crypto Extension Guide Appending A, somehow PKCS5 version 2 may not have been available/documented then (or indeed as suggested by brianegge, may be a matter of export restriction, a common issue with cryptographic items).
The algorithm name does show up in RFC3962 (AES for Kerberos) which may not be the very application you have in mind, but defined, all the same)

Different distributions of Java contain different crypto. This is due to export restrictions and patents. The line of code is requesting a factory which can create that type of key.
Specifically, PBKDF2WithHmacSHA1 constructs secret keys using the Password-Based Key Derivation Function function found in PKCS5 v2.0.

"PBKDF2" is a function defined in PKCS #5 used to derive key material from a password.
PBKDF2 requires a pseudo-random function, and in this case, a message authentication code based on the SHA-1 hash is used—"HmacSHA1".
So, this line is creating a factory. The factory might produce SecretKey objects that can be used to key a Cipher instance for a symmetric encryption algorithm or a Mac algorithm. Or, it can be used to make a "transparent" specification of an existing SecretKey.
One important thing to note about PBKDF2 is that it doesn't produce secret keys for any particular algorithm. It's a deterministic way to generate key "material" from a seed (a password), in such a way that the seed cannot be recovered from the generated key. Once the required number of bytes are generated, they are usually wrapped in a SecretKeySpec with the correct algorithm name.
You can see other standard names for secret key factories in the Java Crypto Architecture Standard Names documentation.