CODEWITHSUNDEEP
javaencryptionaessalt-cryptography
cody
cody

Reputation: 435

Java AES Encryption with salt

Alright, turns out I suck at Encryption/Decryption. I just dont get it. How can I make Java encrypt String message1 = "hello world"; with String salt = "mySalt"; using AES encryption? also how can I decrypt it once encrypted?

If you have the time to provide the most basic code, it would help me a lot.

Also 1 general question about AES encryption, using the same salt, will the same message always have the same encryption?

Thanks in advance.

Upvotes: 13

Views: 47356

Answers (4)

JeeBee
JeeBee

Reputation: 17546

With Spring Security Crypto, it is simplified (mainly because they default to the password based encryption rather than other forms):

final String password = "A private password that you need to keep secret.";  
final String salt = KeyGenerators.string().generateKey();
TextEncryptor encryptor = Encryptors.text(password, salt);

String cipherText = encryptor.encrypt(textToEncrypt);

String decryptedText = encryptor.decrypt(cipherText);

AES is just a cipher, and you can use an IV with the text you are encrypting. With symmetric encryption, the salt is used for the key/secret that you encrypt with, as you can see above.

In the real world you will have to deal with distributed systems, shared keys and salts across the cluster, etc, etc. Lots of fun.

Spring Security is a thin abstraction over JCE, so it's easy to adapt if you don't use Spring itself.

Upvotes: 6

James879
James879

Reputation: 381

Always salt your AES files. The reason for this is say you have a directory of JPEG files that are cipher encrypted with the same password but don't have a salt. If somebody gets hold of those files they will see all the files start with the same bytes (as that is the JPEG header and the same passphrase will be always encrypt to the same values until the bytes start to differ, at least with a CBC), they will also know what the first blocks of the file will look like unencrypted. Even if they don't know what type of files they are, they can probably guess the type from the length of the lead in that are similar and the various file formats out there.

Knowing this, they can reverse engineer your password in a manner similar to rainbow tables/brute force. Salting won't stop this happening, but will make it really hard to crack as every file (after the salt) will be different so file type identification is difficult, plus they would have to generate a rainbow table for each salt or the computational overhead of creating an Initialization Vector for the salt.

OpenSSL stores the salt in the file

e.g. I created a file using this command with a password of 'password':
echo "randomprhase" | openssl aes-128-cbc -out message.enc
Here is the hexdump of the resulting file:-

[james@web openssltest]$ hexdump message.enc
0000000 6153 746c 6465 5f5f 7eaa c4fd 63d8 8c8c
0000010 9519 75c9 0497 d449 27f5 2c91 0d34 5ceb
0000020

And the same data when I ran the encryption again:-

[james@web openssltest]$ hexdump message1.enc
0000000 6153 746c 6465 5f5f a876 5394 53f1 bf1a
0000010 adcb e1cd dba9 8034 cf13 8b3f c37c 5048
0000020

The first 4 bytes say that the file is salted (6153 746c 6465 5f5f) and will always be the same.

The next 4 bytes is the random salt (7eaa c4fd 63d8 8c8 for first file & a876 5394 53f1 bf1a for the second file) OpenSSL will take this salt and build the Initialization Vector (IV), being an MD5 hash of the password + salt repeated 3 times. This IV is then used to encrypt the file. Note the payload of the last 8 bytes in each case is different.

If we ran the same command while not salting:

[james@web openssltest]$ echo "randomprhase" | openssl aes-128-cbc -nosalt -out nosalt.enc

[james@web openssltest]$ echo "randomprhase" | openssl aes-128-cbc -nosalt -out nosalt1.enc

[james@web openssltest]$ hexdump nosalt.enc
0000000 947e f4ab 6dd7 c548 89e4 b587 82f4 5136
0000010

[james@web openssltest]$ hexdump nosalt1.enc
0000000 947e f4ab 6dd7 c548 89e4 b587 82f4 5136
0000010

Notice that when I repeated it using the same password and specified not to salt the payloads are identical.

In a Java implementation you can store your salt separately but worth spending your time writing something that emulates the OpenSSL implementation so you don't have to rely on your own code to decrypt a file (especially if you lose your code at some point in the future, encryption can thwart you as much as it can thwart an attacker).

Upvotes: 5

Prabath Siriwardena
Prabath Siriwardena

Reputation: 5921

When you use AES with a salt value, salt value differs from the text to encrypt - but the key remains the same - in that case you need to also store the salt value as well..

Here is a good example...

Upvotes: 1

Oliver Charlesworth
Oliver Charlesworth

Reputation: 272437

AES doesn't have a concept of a salt. It just takes data, and a key. For the same input, it will always generate the same output.

How you combine your message with your salt is up to you. String concatenation is probably sufficient. But note that salts don't really make a lot of sense for something like AES, because it's not a hash algorithm.

Upvotes: 12

Related Questions