I'm trying to calculate HMAC with iv (without any additional key).
I need to pass it at the 'init' level. I know that usually there is no need in passing the iv, since there are default ivs for hmac/sha. But if I don't want to use the defaults, and want to supply my own iv how is it possible to implement in java? I've tried using javax, but it's MAC init accepts only the signing key.
For example:
Mac hmac = Mac.getInstance("HmacSHA1");
byte[] hmacKeyBytes = key.getBytes();
SecretKeySpec secretKey = new SecretKeySpec(hmacKeyBytes, "HmacSHA1");
hmac.init(secretKey);
I want to init with some iv value. But don't know how.
I'm referring to initial value used to start the hash/hmac iterated process. Usually it is some arbitrary number, not exposed to the user. I want to be able to change this default initialization vector for hash functions/ find some way to supply my own iv. How can I do it?
Thank you!
The HMAC takes the initial parameter only the key. Effectively - the same content should have the same authentication tag, so IV is not needed/desired by definition.
As far I recall from my cryptography classes having non-static IV would lead to vulnerabilities with MAC/HMAC for some algorithm implementations, but I don't recall details anymore (you could ask in the Cryptography section of the stackoverflow https://crypto.stackexchange.com/).
If you really want having a sort of IV, you can still prepend the IV to the content.
HMAC-SHA1 is called a message authentication code (MAC). This object takes as input a key K, and an arbitrary-length message X, and outputs a tag T. Basically, a MAC is secure if it's hard to find a new input X and a tag T such that HMAC-SHA1(K, M) = T, for an unknown key K.
My guess is that you're wondering what to do with the IV, because you're ushing HMAC-SHA1 with some sort of encryption scheme? AES-CTR encryption, for example, uses an IV. In this case, you must encrypt the ciphertext and IV. So in pseudocode:
(IV, C) := AES-CTR(K1, M) # Maybe the output is a string with the IV prepended
T := HMAC-SHA1(K2, (IV, C))
return (IV, C, T)
By the way, HMAC-SHA1 is no longer considered secure. Consider using something like HMAC-SHA256.
Related
A colleague of mine asked me to check if his code is secure enough. I saw some code snippet like this:
private static byte[] encrypt(String plain, String key) throws Exception {
KeyGenerator kg = KeyGenerator.getInstance("AES");
SecureRandom secureRandom = new SecureRandom();
secureRandom.setSeed(key.getBytes());
kg.init(128, secureRandom);
SecretKey secretKey = kg.generateKey();
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, secretKey);
return cipher.doFinal(plain.getBytes());
}
#Test
public void lcg() throws Throwable {
String plain = "abc";
String key = "helloworld";
byte[] c1 = encrypt(plain, key);
byte[] c2 = encrypt(plain, key);
Assert.assertArrayEquals(c1, c2);
}
This encrypt function is used to encrypt sensitive data, and encrypted data will be stored into database. I thought it won't work firstly because SecureRandom won't generate same random number twice even initialzed by the same seed, but it just works in the test.
I think it is not secure to encrypt something in this way, but I can't tell what is the problem about this code snippet.
My question:
is the encrypt function secure?
if it's not secure, what is the problem to do so?
is the encrypt function secure?
No, it is not secure for any good definition of secure.
First of all, it uses ECB, which is not secure unless the plaintext blocks are not related.
More importantly, new SecureRandom() simply gets the first random number generator from the provider list. Usually this was "SHA1PRNG" but currently - for the Oracle Java 11 SE runtime - it returns a much faster and better defined DRBG. Those are not compatible, so one ciphertext cannot be decrypted with another runtime; the code is not portable at all.
Different runtimes may return completely different random number generators - possibly optimized for the runtime configuration. These random number generators may depend completely on the given seed if it is set before random numbers are extracted from it. It may also mix the seed into the state. That will produce a completely random key which you will never be able to regenerate unless you save it somewhere.
Basically, this method may both be insecure because of ECB and overly secure - not a small feat in itself. You may never be able to decrypt the ciphertext again, ever, but you can still distinguish identical plaintext blocks.
A small other problem is that getBytes uses the platform default encoding. This differs e.g. between Windows (Windows-1252) and Linux (UTF-8) and the Android platform (also UTF-8, of course). So decode the plaintext on another system - if you can - and you may still get surprised afterwards.
The procedure is so bad that it should be archived in the round rubbish receiver and implement something new. For that it is a good idea to use a key and IV consisting of random bytes and a modern cipher such as AES in GCM mode at the very least. If you have a password you should use a password hash (or key-based key derivation function) like PBKDF2 or a more modern one to derive a key from it.
Kudo's for finding a worse way to derive keys from passwords. getRawKey was bad, but this one is worse. Good that you asked, in other words.
I am trying to do AES encryption in Java. I have the following function:
public static String encrypt(String plainText, String key) throws Exception {
if (plainText == null || plainText.length() == 0) {
return plainText;
}
// get aes key
SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
// encrypt
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec);
byte[] bytes = cipher.doFinal(plainText.getBytes("UTF-8"));
//encode
String encoded = Base64.encodeToString(bytes, Base64.NO_PADDING | Base64.NO_WRAP);
return encoded;
}
My aim is to be able to encrypt some text with a given key the same way every time. That is, if I call this function with the same two parameters many times, I want the same string to be returned on every call. I'll say in advance, I know that is not how cryptography is supposed to be done, but I need this functionality for my project.
Unfortunately, that is not the case. The key generated in line 7 seems to encrypt my string differently every time around. I assume there is some kind of extra random automatic salting occurring on the lower levels of this library, preventing me from achieving my goal.
Does anyone know a way in Java how I could go about encrypting a given string with a given key to the same value every time? Thanks.
UPDATE/CLARIFICATION: This is not for security. This is for the encryption of data for it to be obfuscated for certain people that might come in contact with working on the app itself. The information is not highly sensitive, but I do want it encrypted and then decrypted by the same key. I have others working with me on this with libraries in their respective languages, e.g. Ruby, and their libraries allow them to encrypt a value with a given key the same way every time. We all want to use the same parameters of the same encryption algorithm: Key length: 128 bits
Mode of operation: CBC
Initialization Vector: None (all zeros)
Is it perhaps that if one does not set an initialization vector, it is randomly assigned? I've got to check that out.
Yes, Java - or rather the security provider supplying the AES in CBC mode implementation - may default to a random IV (which you then have to retrieve afterwards and include with your ciphertext) if you don't explicitly specify it you get secure, randomized ciphertext.
If you want to use a zero IV you will have to specify it explicitly:
cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, new IvParameterSpec(new byte[cipher.getBlockSize()]);
This is only slightly more secure than ECB mode, as any repetition in different messages in the initial ciphertext blocks will be instantly visible to an attacker.
If you want to have a more secure mode without random IV - which is required for CBC mode to obtain CPA security - then you could check out synthetic IV (SIV) mode or GCM-SIV. For those modes the entire message needs to be identical with a previous one to leak info to an attacker. It's however slowe, not included in the standard VM and the ciphertext could be larger than AES/CBC (inclusion of IV/tag vs padding requirements).
I just want to confirm my understanding of how AES works.
If company#1 is encrypting the data, and sending this data to company#2 to decrypt, and let's presume that one of them uses C# and the other Java.
As long as both are using the same shared secret key, is there anything else setting/configuration wise both parties should agree upon to make sure the data is correctly encryption and decrypted?
There is a lot that both have to agree upon:
shared secret key
How long is it? (Is key padding required?)
Is the actual key derived from another key or password with an additional salt?
Which key derivation function is used and what are their parameters? PBKDF2, bcrypt, scrypt, ...
Is the IV derived together with the key? (usually by requesting key size + IV size output from the key derivation function)
cipher characteristics:
block cipher like AES, Triple DES, Twofish, Rijndael, ...
cipher parameters such as block size in case it is variable
mode of operation like CBC, CTR, CFB, ...
for IV-based modes: How is the IV generated? Is it generated randomly and put into the container format or is it derived together with the key from a password and therefore doesn't need to be put into the ciphertext container?
for nonce-based modes like CTR: How big is the nonce (sometimes referred to as IV)?
for parametrized modes like CFB: How big is a segment?
padding mode like PKCS#7 padding (which is also referred to as PKCS#5 padding), ZeroPadding, ...
authentication (if any):
as mode of operation like GCM, EAX, SIV, ...
as separate encrypt-then-MAC/MAC-then-encrypt/encrypt-and-MAC scheme with a MAC like HMAC-SHA256, CMAC, HKDF, GHASH, ...
encoding of each component like Hex, Base32, Base64 or simply binary (no encoding)
Is everything encoded together into a textual format from the finished binary format or are the components encoded separately and concatenated together?
format:
Where to put IV/nonce/salt (if any)? (usually before the actual ciphertext)
Where to put authentication tag (if any)? (usually after the actual ciphertext)
Is Cryptographic Message Syntax applicable?
Talking about javax.crypto.Cipher
I was trying to encrypt data using Cipher.getInstance("RSA/None/NoPadding", "BC") but I got the exception:
ArrayIndexOutOfBoundsException: too much data for RSA block
Looks like is something related to the "NoPadding", so, reading about padding, looks like CBC is the best approach to use here.
I found at google something about "RSA/CBC/PKCS#7", what is this "PKCS#7"? And why its not listed on sun's standard algorithm names?
Update:
I'm wondering, if is a padding problem, why this example run just fine?
import java.math.BigInteger;
import java.security.KeyFactory;
import java.security.interfaces.RSAPrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.RSAPrivateKeySpec;
import java.security.spec.RSAPublicKeySpec;
import javax.crypto.Cipher;
/**
* Basic RSA example.
*/
public class BaseRSAExample
{
public static void main(
String[] args)
throws Exception
{
byte[] input = new byte[] { (byte)0xbe, (byte)0xef };
Cipher cipher = Cipher.getInstance("RSA/None/NoPadding", "BC");
KeyFactory keyFactory = KeyFactory.getInstance("RSA", "BC");
// create the keys
RSAPublicKeySpec pubKeySpec = new RSAPublicKeySpec(
new BigInteger("d46f473a2d746537de2056ae3092c451", 16),
new BigInteger("11", 16));
RSAPrivateKeySpec privKeySpec = new RSAPrivateKeySpec(
new BigInteger("d46f473a2d746537de2056ae3092c451", 16),
new BigInteger("57791d5430d593164082036ad8b29fb1", 16));
RSAPublicKey pubKey = (RSAPublicKey)keyFactory.generatePublic(pubKeySpec);
RSAPrivateKey privKey = (RSAPrivateKey)keyFactory.generatePrivate(privKeySpec);
// encryption step
cipher.init(Cipher.ENCRYPT_MODE, pubKey);
byte[] cipherText = cipher.doFinal(input);
// decryption step
cipher.init(Cipher.DECRYPT_MODE, privKey);
byte[] plainText = cipher.doFinal(cipherText);
}
}
Update 2:
I realized that even if I use just Cipher.getInstance("RSA", "BC") it throws the same exception.
If you use a block cipher, you input must be an exact multiple of the block bit length.
In order to encipher arbitrary length data, you need first to pad you data to a multiple of the block length. This can be done with any method, but there are a number of standards. PKCS7 is one which is quite common, you can see an overview on the wikipedia article on padding.
Since block cipers operate on blocks, you also need to come up with a way of concatenating the encrypted blocks. This is very important, since naive techniques greatly reduce the strength of the encryption. There is also a wikipedia article on this.
What you did was to try to encrypt (or decrypt) data of a length which didn't match the block length of the cipher, and you also explicitly asked for no padding and also no chaining mode of operation.
Consequently the block cipher could not be applied to your data, and you got the reported exception.
UPDATE:
As a response to your update and GregS's remark, I would like to acknowledge that GregS was right (I did not know this about RSA), and elaborate a bit:
RSA does not operate on bits, it operates on integer numbers. In order to use RSA you therefore need to convert your string message into an integer m: 0 < m < n, where n is the modulus of the two distinct primes chosen in the generation process. The size of a key in the RSA algorithm typically refers to n. More details on this can be found on the wikipedia article on RSA.
The process of converting a string message to an integer, without loss (for instance truncating initial zeroes), the PKCS#1 standard is usually followed. This process also adds some other information for message integrity (a hash digest), semantical security (an IV) ed cetera. With this extra data, the maximum number of bytes which can be supplied to the RSA/None/PKCS1Padding is (keylength - 11). I do not know how PKCS#1 maps the input data to the output integer range, but
my impression is that it can take any length input less than or equal to keylength - 11 and produce a valid integer for the RSA encryption.
If you use no padding, your input will simply be interpreted as a number. Your example input, {0xbe, 0xef} will most probably be interpreted as {10111110 +o 11101111} = 1011111011101111_2 = 48879_10 = beef_16 (sic!). Since 0 < beef_16 < d46f473a2d746537de2056ae3092c451_16, your encryption will succeed. It should succeed with any number less than d46f473a2d746537de2056ae3092c451_16.
This is mentioned in the bouncycastle FAQ. They also state the following:
The RSA implementation that ships with
Bouncy Castle only allows the
encrypting of a single block of data.
The RSA algorithm is not suited to
streaming data and should not be used
that way. In a situation like this you
should encrypt the data using a
randomly generated key and a symmetric
cipher, after that you should encrypt
the randomly generated key using RSA,
and then send the encrypted data and
the encrypted random key to the other
end where they can reverse the process
(ie. decrypt the random key using
their RSA private key and then decrypt
the data).
RSA is a one-shot asymmetric encryption with constraints. It encrypts a single "message" in one go, but the message has to fit within rather tight limits based on the public key size. For a typical 1024 bit RSA key, the maximum input message length (with RSA as described in the PKCS#1 standard) is 117 bytes, no more. Also, with such a key, the encrypted message has length 128 bytes, regardless of the input message length. As a generic encryption mechanism, RSA is very inefficient, and wasteful of network bandwidth.
Symmetric encryption systems (e.g. AES or 3DES) are much more efficient, and they come with "chaining modes" which allow them to process input messages of arbitrary length. But they do not have the "asymmetric" property of RSA: with RSA, you can make the encryption key public without revealing the decryption key. That's the whole point of RSA. With symmetric encryption, whoever has the power to encrypt a message also has all the needed information to decrypt messages, hence you cannot make the encryption key public because it would make the decryption key public as well.
Thus it is customary to use an hybrid system, in which a (big) message is symmetrically encrypted (with, e.g., AES), using a symmetric key (which is an arbitrary short sequence of random bytes), and have that key encrypted with RSA. The receiving party then uses RSA decryption to recover that symmetric key, and then uses it to decrypt the message itself.
Beyond the rather simplistic description above, cryptographic systems, in particular hybrid systems, are clock full of little details which, if not taken care of, may make your application extremely weak against attackers. So it is best to use a protocol with an implementation which already handles all that hard work. PKCS#7 is such a protocol. Nowadays, it is standardized under the name of CMS. It is used in several places, e.g. at the heart of S/MIME (a standard for encrypting and signing emails). Another well-known protocol, meant for encrypting network traffic, is SSL (now standardized under the name of TLS, and often used in combination with HTTP as the famous "HTTPS" protocol).
Java contains an implementation of SSL (see javax.net.ssl). Java does not contain a CMS implementation (at least not in its API) but Bouncy Castle has some code for CMS.
This error indicates that the input data size is greater than the key modulus size. You will need a bigger key size to encrypt the data. If changing the key length is not an option, alternatively you may need to investigate if you are really expecting that big input data.
RSA can only be used to encrypt, when the number of bits being used to encrypt is greater then the size of the thing you are tying to encrypt + 11 bytes
Public-Key Cryptography Standards - PKCS
Scroll down a bit and you'll see it. It's not an cypher algortihm (like RSA) or a cypher mode like CBC, but a description of the way the certificate is encoded as bytes (i.e., a data structure syntax). You can find the spec for it here.
PKCS#7 is listed (referring to your link). It's encoding is PKCS7
Description
A PKCS#7 SignedData object, with the
only significant field being
certificates.
Use java.security.cert.CertificateFactory or CertPath when using PKCS7.
RSA is a block cipher. It encrypts block of the same key size.
Therefore, BouncyCastle RSA gives an exception if you try to encrypt a block
which is longer than the key size.
That's all I can tell you so far.
You should not encrypt your data using RSA directly. Encrypt your data with a random symmetric key (i.e. AES/CBC/PKCS5Padding) and encrypt the symmetric key using RSA/None/PKCS1Padding.
I am writing a Java implementation of an app originally written in C. I can't modify the C version, and the Java version must share encrypted data with the C version.
Here's the relevant part of the C encryption code:
makekeys(password,&key1,&key2); /* turns password into two 8 byte arrays */
fill_iv(iv); /* bytes 8 bytes of randomness into iv */
des_key_sched(&key1,ks1);
des_key_sched(&key2,ks2);
des_ede2_ofb64_encrypt(hashed,ctext,hashedlen,ks1,ks2,
&iv,&num);
I can see that the JCE equivalent is something like:
SecretKey key = new SecretKeySpec(keyBytes, "DESede");
IvParameterSpec iv = new IvParameterSpec(new byte[8]);
Cipher cipher = Cipher.getInstance("DESede/?????/?????"); // transformation spec?
cipher.init(Cipher.ENCRYPT_MODE, key, iv);
byte[] cipherTextBytes = cipher.doFinal(plaintext);
Questions:
The C code takes two keys, JCE takes one. How do I reconcile this? Just append the two into one array? In which order?
What transformation spec (if any!) is equivalent to OpenSSL's des_ede2_ofb64_encrypt? How would I find out, other than by asking strangers on the Internet? ;)
In answer to your last question, you'd find out by reading the documentation on the specific algorithms themselves. The Sun docs do generally assume you already are familiar with the subject matter. In this case, you would know that: triple DES is the application of three independently keyed DES ECB instances in sequence; that the most common way to this is something called DES ede, which means the 1st and 3rd DES instances are run in the encrypt direction but the 2nd DES instance is run in the decrypt direction; that ede3 three means that each DES instance is keyed independently and ede2 means that the 1st and 3rd instances use the same key; that OFB64 means 64-bit output feedback mode.
You should get the the same result with getInstance("DESede/OFB64/NoPadding"), and by making the key1 the 1st 8 bytes of the DESede key, key2 the 2nd, and key1 the 3rd.