6

I have following code -

import org.jasypt.util.text.BasicTextEncryptor;

public static void main(String[] args) {
    BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
    textEncryptor.setPassword("kshitiz");

    String cipherText = textEncryptor.encrypt("my_secret");
    System.out.println(cipherText);
}

Every time I run it the output is different -

1st run - 7vZzcsVFortOUf4yLyQ9xSEUM2pKSXAs

2nd run - Z3YDxfPpubGAQMpr+5MAKR5P09mAJ7Wd

3rd run - kVGIGcCEXZDFJnV/n0lxyFN5WW7dWMT7

All the outputs are correct as decrypting them gives me my_secret.

How is this so?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Kshitiz Sharma
  • 17,947
  • 26
  • 98
  • 169

2 Answers2

5

Copied from documentation of the method.

The mechanisms applied to perform the encryption operation are described in PKCS #5: Password-Based Cryptography Standard.

This encryptor uses a salt for each encryption operation. The size of the salt depends on the algorithm being used. This salt is used for creating the encryption key and, if generated by a random generator, it is also appended unencrypted at the beginning of the results so that a decryption operation can be performed.

If a random salt generator is used, two encryption results for the same message will always be different (except in the case of random salt coincidence). This may enforce security by difficulting brute force attacks on sets of data at a time and forcing attackers to perform a brute force attack on each separate piece of encrypted data.

Essentially, to comply to the standard, a cryptographic salt which is randomly generated at runtime is used and appended to the output string. This salt prevents brute force attacks using pre-computed rainbow tables.

Community
  • 1
  • 1
initramfs
  • 8,275
  • 2
  • 36
  • 58
  • I'm not sure if the developers of this library know anything about cryptography. A cipher does not take a salt. The key must not be derived from the initialization vector. Also, rainbow table attacks only apply to hash functions, not ciphers. – ntoskrnl Aug 08 '13 at 06:04
  • @ntoskml I'm assuming they added a salt to the password prior to the PBKDF... And if they said they followed PKCS #5 standards, I'm assuming they're using a random IV as well. I know rainbow tables only apply to hashes... but in the case of a PBKDF I guess you could pre-compute rainbow tables of password -> derived key (assuming the function uses a static IV). – initramfs Aug 08 '13 at 06:09
  • Correction to my previous statement: Upon reading the RFC 2898 document I've found the salt is used in the KDF itself rather than prior to it. The KDF (which I'm assuming to be PBKDF2) commonly uses a hash function (normally HMAC-SHA1) internally to generate the derived key. A attacker could utilize rainbow tables to greatly speed up the KDF by per-computing the hash in a brute force attack. Not no mention also generating Password -> Derived Key tables. The authors of this library seem to generate a new derived key for every encryption, thus stating that a random salt is used. – initramfs Aug 08 '13 at 22:40
3

It is probably using random IVs or random padding. This is actually important for security under some attacks but it will result in different ciphertexts for the same message.

Antimony
  • 37,781
  • 10
  • 100
  • 107
  • 2
    This randomization is actually very important for security. Otherwise a lot of information is leaked about the plaintext. – ntoskrnl Aug 08 '13 at 06:07