I'm trying to decipher the encfs volume key in Java. I ran encfs with the standard settings (ie, 192 bit aes encryption). Is there any way to do this?
This is not really a Java question, more an issue of cryptography. A brief investigation into EncFS suggests that the volume key is encrypted by a key derived from a user password. It's probable that this represents the best attack vector: a brute force attack on what is hopefully a weak password. I wouldn't hold out too much hope, however.
For what it's worth, the Java JCE classes in javax.crypto would be your route towards performing symmetric cryptography in Java. The following code snippet shows how you might perform some AES decryption with a plaintext key:
byte[] keyBytes = ...
byte[] volumeKeyFileContents = ...
SecretKeyFactory factory = SecretKeyFactory.getInstance("AES");
SecretKey aesKey = factory.generateSecret(new SecretKeySpec(keyBytes, "AES"));
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding"); // for example
cipher.init(Cipher.DECRYPT_MODE, aesKey);
byte[] plaintext = cipher.doFinal(volumeKeyFileContents);
// (written from memory so may not compile without tweaks)
You would then need to use the plaintext value as a potential candidate for the volume key. Clearly this is a simplified solution and makes many assumptions; you will need to research in more depth the format of these volume key files and the algorithms, modes and padding used during the construction of the encrypted copy.
Good luck.
There is a Java library at https://github.com/mrpdaemon/encfs-java that provides read & experimental write access to the encfs file systems.
Related
so I'm creating a game for my A level project and I'm now at the stage where I need to be able to encrypt and decrypt text files.
I have figured out encryption using AES-256 in GCM mode however I am using a randomly generated key and IV in order to encrypt the data in the first place. So I was wondering, is there any way in which I can decrypt the text file without knowing the key and iv.
Alternatively, from the encryption method shown below, is there anything I could change so that I will know the key and iv when decrypting the text later on.
NOTE: I'm using the libGDX library to create the game which is why I'm not using the standard method to write to the text file.
Encryption method:
public void encrypt ()
{
byte[] input = w.getSprites().toString().getBytes(); // Data to be encrypted
byte[] encrypted = null; // Encrypted output
Cipher cipher; // Cipher algorithm to be used
try {
// Setup the cipher algorithm to use and select the wanted mode
// AES is the cipher algorithm GCM is the mode
cipher = Cipher.getInstance("AES/GCM/NoPadding");
// Generate a random key for the encryption
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(256);
SecretKey key = keyGenerator.generateKey();
// Generate a random iv for the encryption
SecureRandom randomSecureRandom = new SecureRandom();
byte[] iv = new byte[cipher.getBlockSize()];
randomSecureRandom.nextBytes(iv);
// Encrypt the data
cipher.init(Cipher.ENCRYPT_MODE, key, randomSecureRandom);
encrypted = new byte[cipher.getOutputSize(input.length)];
int enc_len = cipher.update(input, 0, input.length, encrypted, 0);
enc_len += cipher.doFinal(encrypted, enc_len);
}
catch (NoSuchAlgorithmException |
NoSuchPaddingException |
InvalidKeyException |
ShortBufferException |
IllegalBlockSizeException |
BadPaddingException e) { e.printStackTrace(); }
FileHandle f = Gdx.files.local("bin/default/saves/default/test.txt");
f.writeString(encrypted.toString(), false);
}
Thank you in advance for any answers, they are very much appreciated.
No, you cannot decrypt without knowing the key. What would the point of encryption be if anyone could decrypt the message without even having the key?
If this is intended to hide data from a local user, then pretty much the best you can is obfuscate the data. The machine needs to know the key in order to encrypt and decrypt it and anyone with access to that machine can eventually find that key and use it to decrypt the data for themselves. Even if you don't write anything to disk, local users could look at memory and find the key. Also remember that code can be decompiled.
Basically just keep in mind that anyone with physical access is king and you can't really stop them, just slow them down.
So the best you can do is make it as painful as possible to get the key. String literals in classfiles or property files are easy to read and not at all painful so avoid using those.
See this question for related ways to handle local security.
Also consider using a tool like Proguard to obfuscate (and optimize) your code in general as well.
You could try a brute force attack.
Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. Fifty supercomputers that could check a billion billion (1018) AES keys per second (if such a device could ever be made) would, in theory, require about 3×1051 years to exhaust the 256-bit key space.
Per wikipedia
In reality the 256-bit AES is considered computationally infeasible. The only 'feasible' way to decrypt would be using the same key used to encrypt. Some background on AES.
There is a faster method (still computationally infeasible for 256 bit) called Biclique attack. but I think this is a bit outside the scope of what your asking.
If you decide you need to pass your AES key from the encryption person to the decrytion person you can use RSA encryption which uses asymetric keys. Take a look at my github for a basic RSA implementation.
I have found an useful AES256 implementation to en/decrypt strings, all work fine except the fact i have to store the initialization vector (IV) for the decoding.
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, secret);
AlgorithmParameters params = cipher.getParameters();
ivBytes = params.getParameterSpec(IvParameterSpec.class).getIV();
All there any (secure) alternative methods maybe without CBC, because with CBC i have to store an IV (and in my case i have to share the IV which is really not secure).
I have read an article on this platform concerning it´s possible to encode without CBC but that´s not a good idea because of dictionary attacks.
so, are there any alternatives to encode a string with aes256 (without storing additional data like IV, or salt arrays)?
The idea behind an IV is to use a distinct new random one for every encryption (with the same key).
This is very important to ensure the the security of cipher-modes such as CTR or CBC which would not be secure at all without an IV. Also when using the same key to encrypt the same message twice it will result in two distinct ciphertexts (since the two IVs were distinct).
In short, you should always use an IV.
Usually you just prepend them to the ciphertexts and then extract them before encryption, so you don't have to store them individually.
I would like to use AES256 to encrypt a text, I'd like to use my email test#gmail.com as the key to encrypt it.
This is what I tried:
String key = "test#gmail.com";
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
byte iv[] = SOME_RANDOM_32_BYTES;
IvParameterSpec ivSpec = new IvParameterSpec(iv);
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec);
byte[] encryptedResult = cipher.doFinal(text.getBytes("UTF-8"));
When I run above code, I got InvalidKeyException:
java.security.InvalidKeyException: Key length not 128/192/256 bits.
I checked on internet, the reason is my key is not 128/192/256 bits. My question is, how can I generate a 256bits(32bytes) key from my email string test#gmail.com ?
You can hash your key string (test#gmail.com) to a 256bit value using SHA256.
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(yourEmail.getBytes());
byte[] encryptionKey = md.digest();
There can be multiple reasons for this. One of them is below.
Usually this error comes when you don't have the update policy in your JRE.
Java by default provide AES with 128, for 256 we have to put new policies provided by Java.
You should not bake your own crypto! (Unless you are very knowledgeable on the matter, that is.)
You should use an existing (and audited) encryption library.
Also, you should not use a guessable string such as your e-mail address as a password. Please, look for advice on how to choose a good password.
Now that I have said this, here are more details.
The proper way to implement password based encryption is to use a KDF (Key Derivation Function) to generate an encryption key from your password. Here are a few KDFs that you can use for this task: Argon2, Scrypt, Bcrypt and PBKDF2.
Key derivation functions include mechanisms to defend against know attacks such as rainbow tables and dictionary attacks, notably a "salt" and a work factor. Modern KDFs such as Argon2 also attempt to prevent attackers from gaining an advantage by using hardware more suitable to the task.
Generally speaking, here how this is used:
Select a work factor (the largest you can afford)
Generate the salt using a CSPRNG
Generate the encryption key and a MAC secret using your chosen KDF with the password, salt and work factor.
Generate an IV (initialization vector) using a CSPRNG
Encrypt the data to be protected using the generated encryption key.
Compute the MAC of the encrypted message using the generated secret.
Serialize the salt, the work factor, the computed MAC and the encrypted data. (Optionally, identifiers indicating what are the chosen KDF, encryption scheme and MAC should also be included if these are not fixed.)
Your encrypted message is the serialized data produced in step 7. Get any of the steps wrong (and that is easy) and your encryption code will probably break in horrible ways.
Perhaps now you get a sense of why you should use an existing library?
Note: the current best practice is to use AEAD (Authenticated Encryption with Associated Data) instead of encrypt-then-MAC as described above. Look this up if you are interested: I am not going to discuss this here.
I am trying to replace PBEWithMD5AndDES with PBEWithMD5AndTripleDES in existing code. So far, I am using the same passphrase that I was using before, and receiving this Exception:
java.security.InvalidKeyException: Illegal key size
I looked online and saw that DES uses a 64 bit key and TripleDES uses a 128 bit key. I am not clear on the details of how my passphrase is used to generate a key, and not sure where to look to understand this fully. My passphrase is 260 characters long. I tried doubling the length, but I get the same Exception.
I am generating a PBEKeySpec from my passphrase, with an 8 byte salt and an iteration count of 12. I see that there's another constructor that takes a keyLength argument, but the documentation describes it as "to be derived," and I don't understand that. I have the idea that I need to modify the iteration count and/or supply a keyLength argument, but I don't want to just do this blindly without fully understanding what I am doing.
Here is the basic outline of the code I'm currently using:
String passphrase = ...
byte[] salt = ...
int iterationCount = 12;
String algorithm = "PBEWithMD5AndTripleDES";
KeySpec keySpec = new PBEKeySpec(passPhrase.toCharArray(), salt, iterationCount);
SecretKey key = SecretKeyFactory.getInstance(algorithm).generateSecret(keySpec);
Cipher cipher = Cipher.getInstance(key.getAlgorithm());
AlgorithmParameterSpec paramSpec = new PBEParameterSpec(salt, iterationCount);
cipher.init(Cipher.ENCRYPT_MODE, key, paramSpec);
byte[] encoded = cipher.doFinal(data);
PBEWith<Hash>AndTripleDES Requires "Unlimited Strength" Policy
This algorithm uses a 168-bit key (although due to vulnerabilities, it has an effective strength of 112 bits). To use a symmetric key of that length, you need the "unlimited strength jurisdiction policy" installed in your Java runtime.
An "Illegal key size" message indicates the key length is not permitted by policy; if the key length is incorrect for the algorithm, the SunJCE provider uses the message, "Wrong key size".
Don't Use PBEWith<Hash>AndTripleDES
Note that "PBEWithMD5AndTripleDES" is a bad algorithm to use.
Password-based encryption generally follows PKCS #5. It defines an encryption scheme for DES (or RC2) called PBES1. Because PBES1 was designed to generate 64-bit (or less) keys, Oracle has created a proprietary extension to generate longer keys. It hasn't been exposed to the same scrutiny that PKCS #5 has, and if you need to inter-operate with any other platform, you'll have to dig into the source code to find out how the key and initialization vector are derived.
It's also strange that the initialization vector is derived from the password. The purpose of an IV is to create different cipher texts each time a given plain text is encrypted with the same key. If the IV is generated from the key, this purpose is defeated. The key-derivation algorithm used by PBES1 avoids this by incorporating a "salt" that is supposed to be different each time the password is used. But, it could be easy to screw this up; providing an IV directly to the cipher initialization is more conventional, and makes it more obvious what is happening.
Use PBKDF2 Instead
PKCS #5 also defines an key-derivation algorithm called PBKDF2 that is now supported by Java. It provides superior security to PBES1 because the initialization vector and any other parameters required by the cipher are not derived from the password, but are selected independently.
Here's an example with PBKDF2, using AES. If you can't follow the recommendation to update to AES, the example can be applied to DESede by using a key length of 192, and changing occurrences "AES" to "DESede".
TDEA Keying Options
There are three keying options that can be used with TDEA ("Triple DES" or "DESede"). They take 64-, 128-, or 192-bit keys (including parity bits), depending on the option.
The key sizes accepted by the TDEA implementation depend on the provider; a few require you to form a 192-bit key, even if you are using the 56-bit key option which is effectively DES instead of TDEA. Most implementations will take 16 or 24 bytes as a key.
Only the three-key option (168 bits, or 192 bits with parity) can be considered "strong encryption". It has 112 bits of effective strength.
As erickson says, the "right" answer to this question is to install the unlimited strength jurisdiction policy files in the JRE.
That will make encryption with PBEWithMD5AndTripleDES "work," but the resulting data cannot be decrypted as far as I can tell. You will get a padding error exception. There may be some way to fix it, but this was proof enough to me that pursuing this route was not worth it as it seems to be a road that is not traveled enough to get the bugs worked out or to popularize working examples.
I also discovered a PBEWithSHA1AndTripleDES and tried it, but got the same padding error upon decryption.
I was able to get our requirements changed from PBEWithMD5AndTripleDES to just TripleDES (DESede), and that eliminated the whole issue for me!
I'm tring to encrypt/decrypt my files using AES. I followed this tutorial to encrypt my data, but I modified the code a little bit, so that I could use the same key to encrypt many files.
In addition to encrypting my files, my AES key is also saved using RSA (this page , saveKey() method).
I encrypted files on my PC, and tried to decrypt them on Android. However, I always got BadPaddingException: pad block corrupted. I printed out the AES keys, and found out that with the same private key, the decrypted AES keys were different on PC and Android.
It worked fine if I decrypt the same files on PC.
Why?!
Is there anything wrong with Android's cipher?! Help needed.
your RSA padding cipher could be on the wrong padding scheme
try this?
pkCipher = Cipher.getInstance("RSA/NONE/PKCS1Padding");
The code you copied is wrong. It may or may not work depending on Android version. My guess is that it doesn't on newer ones. The part which converts from seed to raw key is flawed (see below): SecureSeed.setSeed() is not guaranteed to set the random generator state, it just adds to it. What this means is that you are not guaranteed to get the same key. To reliably get the same key based on a password, you need to use PBE (Password Based Encryption)
private static byte[] getRawKey(byte[] seed) throws Exception {
KeyGenerator kgen = KeyGenerator.getInstance("AES");
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
// this is wrong!
sr.setSeed(seed);
kgen.init(128, sr); // 192 and 256 bits may not be available
SecretKey skey = kgen.generateKey();
byte[] raw = skey.getEncoded();
return raw;
}
Generally, first make sure you can reliably encrypt/decrypt using AES, then you might move on to using RSA. You might want to tell us what you are trying to achieve, you might be going at it the wrong way. Inventing your own cryptographic protocol is rarely a good idea.