<?xml version="1.0" encoding="ISO-8859-1"?>
<faqs title="Frequently Asked Questions">


  <part id="aboutjasypt">
    <title>About Jasypt</title>
    
    <faq id="where-does-jasypt-come-from">
      <question>Where does Jasypt come from? Is it made or backed by any software company?</question>
      <answer>
        <p>
          Jasypt is Open Source Software created in his spare time by a Spanish Software Engineer
          called <a href="team.html">Daniel Fernández</a> --also author
          of other popular java libraries like <a href="http://www.thymeleaf.org">thymeleaf</a> or
          <a href="http://www.op4j.org">op4j</a>--, and which
          has also received contributions of diverse kind from <a href="team.html">some other people</a>. 
        </p>
        <p>
          It is neither made nor backed
          by any software (or any other type of) company, and it is offered to the public
          totally free of charge, both in binary and in source code forms, under the <b>Apache License 2.0</b>.
        </p>
      </answer>
    </faq>
    
    <faq id="does-it-implement-or-include-cryptographic-algorithms">
      <question>Does it implement or include any cryptographic algorithms?</question>
      <answer>
        <p>
          <b>No, it doesn't</b>, Jasypt by itself does not implement nor distribute in any of its forms any cryptographic
          algorithms. It simply uses the algorithms already present in the users' Java installations via the Java Cryptography Extension.
        </p>
      </answer>
    </faq>
    
    <faq id="can-it-be-considered-production-ready">
      <question>Is it stable? Can it be considered production-ready?</question>
      <answer>
        <p>
          <b>Yes</b>, it can be considered stable and production-ready.
        </p>
      </answer>
    </faq>
    
    <faq id="does-jasypt-offer-commercial-support">
      <question>Does Jasypt offer any type of commercial support or warranty?</question>
      <answer>
        <p>
          No, it does not. Commercial support is not offered at the moment.
        </p>
        <p>
          Also, jasypt is offered without warranties of any kind, as expressed in the
          <a href="license.html">Apache 2.0 License</a>.
        </p>
      </answer>
    </faq>
    
    <faq id="contribute">
      <question>How can I contribute to Jasypt?</question>
      <answer>
        <p>
          In many ways:
        </p>
        <ul>
          <li>You can write to the <a href="team.html">Team</a> with your
              ideas for improving Jasypt.</li>
          <li>You can contribute some code, write a patch for a new feature
              or behaviour (please, tell the project admins first about your idea so 
              that effort can be correctly coordinated).</li> 
          <li>You can write articles, reviews, blog posts, etc. about Jasypt, showing
              how it works or how it integrates with other technologies.</li> 
          <li>You can promote Jasypt in your company/work, showing your colleagues
              or customers how encryption
              can be an easy and powerful task by using Jasypt.</li>
        </ul>
        <p>
          If you want to contribute some code to Jasypt, please read first the
          page on <a href="contributing.html">Contributing to Jasypt</a>.
        </p>
      </answer>
    </faq>
    
    <faq id="what-is-jasypts-export-classification">
      <question>What is Jasypt's export classification in the United States of America?</question>
      <answer>
        <p>
          Although Jasypt does not implement nor distribute in any of its forms any cryptographic
          algorithms, it can use them via the Java Cryptography Extension API and, as such, it is 
          classified under ECCN code 5D002 and approved for export under License Exception TSU.
        </p>
      </answer>
    </faq>

  </part>
  

  <part id="general">
    <title>General</title>
    
    <faq id="what-is-jasypt-useful-for">
      <question>What is jasypt useful for? Give me some examples of use, please...</question>
      <answer>
        <p>
          Jasypt is useful for many encryption tasks associated with applications, for example:
        </p>
        <ul>
          <li>Encrypting (digesting) passwords.</li>
          <li>Encrypting sensitive information.</li>
          <li>Encrypting data communications.</li>
          <li>Creating sums for integrity checking of data.</li>
          <li>...and many more.</li>
        </ul>
      </answer>
    </faq>
    
    <faq id="does-jasypt-implement-algorithms">
      <question>Is it "simplified encryption" because it is less safe?</question>
      <answer>
        <p>
          No. <b>Jasypt does not implement any encryption algorithms</b>, but instead
          delegates to the ones already provided by a JCE 
          (Java Cryptography Extension) provider, which can be either the
          default VM one or any other of your choice, adding a layer for ease and 
          correctness of use, configurability, integration with many 
          other technologies, etc.
        </p>
        <p>
          It is "simplified encryption" because it is much easier to use
          and integrate than the standard APIs, but you will
          get the same encryption power as if you were using the JCE API directly, 
          or even more, as jasypt will enforce
          best practices and use standards that will ensure that you always
          get the highest level of security from the encryption features present
          in your Java installation.
        </p>
      </answer>
    </faq>
    
    <faq id="is-jasypt-only-for-web-applications">
      <question>Is jasypt intended for use only in web applications?</question>
      <answer>
        <p>
          No, not at all. Jasypt offers some special configuration facilities
          to web applications, but it is not necessary for an application
          to be web-based in order to use jasypt. Jasypt will <b>not</b> add any dependency
          on any web-related API to your application if you don't want it to.
        </p>
      </answer>
    </faq>

    <faq id="i-dont-use-hibernate">
      <question>I don't use Hibernate at all. Can I use jasypt anyway?</question>
      <answer>
        <p>
          Yes, you can. Jasypt provides an <b>optional</b> integration package for
          Hibernate, but <b>it does not need Hibernate for normal operation</b>. It 
          won't add a dependency on Hibernate to your project.
        </p>
      </answer>
    </faq>

    <faq id="i-dont-use-spring">
      <question>I don't use Spring at all. Can I use jasypt anyway?</question>
      <answer>
        <p>
          Yes, you can. Jasypt is designed to be seamlessly integrated into
          a Spring-based application if required, but <b>it does not depend on Spring</b>
          in any way. It won't add a dependency on Spring to your project nor
          will force you to develop in an IoC-friendly manner.
        </p>
      </answer>
    </faq>

    <faq id="i-dont-use-spring-security">
      <question>I don't use Spring Security (or Acegi) at all. Can I use jasypt anyway?</question>
      <answer>
        <p>
          Yes, you can. Jasypt provides an <b>optional</b> integration
          package for Spring Security, but <b>it does not need Spring Security
          for normal operation</b>.It 
          won't add a dependency on Spring Security to your project.
        </p>
      </answer>
    </faq>

    <faq id="does-jasypt-need-bouncy-castle">
      <question>Can jasypt use the Bouncy Castle JCE provider? Is it required?</question>
      <answer>
        <p>
          Yes, since version 1.3, it can. The provider API in jasypt is open,
          so that <b>you can use Bouncy Castle or any other JCE provider of
          your choice</b>. You will only have to specify your provider to the
          encryptors or digesters you are using when configurig them.
        </p>
        <p>
          But, <b>Bouncy Castle is not required</b>. Jasypt has no dependency
          on it, and thus you can decide not to use Bouncy Castle at all,
          for example if you want to use the algorithms shipped with your JVM's
          JCE default provider.
        </p>
      </answer>
    </faq>

    <faq id="are-algorithms-like-AES-or-WHIRLPOOL-supported">
      <question>Are algorithms like <i>AES</i> or <i>WHIRLPOOL</i> supported in jasypt?</question>
      <answer>
        <p>
          Yes and no. Jasypt by itself does not implement any algorithms, but
          it lets you use any JCE provider of your choice. 
        </p>
        <p>
          AES (encryption) is supported by the Sun JCE provider since Java 8, and it can be
          used by Jasypt since version 1.9.3.
        </p>
        <p>
          <b>Also, both AES (encryption) and WHIRLPOOL (digests) are algorithms supported 
          by the Bouncy Castle JCE provider</b>, and thus you can use them from 
          jasypt as long as you set Bouncy Castle as your JCE provider for your
          jasypt encryptors or digesters.
        </p>
      </answer>
    </faq>
    
    <faq id="which-is-the-difference">
      <question>Which is the difference between digests and password-based encryption?</question>
      <answer>
        <p>
          Digests are the results of applying <b>cryptographic hash functions</b>
          such as MD5,
          and are a type of <i>one-way encryption</i>. This means that an original
          input cannot be reconstructed from its digest, once it has been
          generated.
        </p>
        <p>
          Password-based encryption is a type of <i>bidirectional encryption</i>, which
          means that encrypted data can be decypted to reconstruct the original
          input. Encryption is done by generating an <i>encryption key</i>, and passing it
          to an <b>encryption algorithm</b> such as DES. This key, in password-based
          encryption, is derived from a password set by the user 
          (usually by a applying a digest algorithm to it).
        </p>
      </answer>
    </faq>

    <faq id="use-snapshot">
      <question>How can I use a SNAPSHOT release of Jasypt?</question>
      <answer>
        <p>    
          From time to time, Jasypt will produce a <i>snapshot</i> release that will allow
          you to test new or being-developed features. These are <b>non production ready</b>
          releases, but will be stable enough for most testing purposes, and will enable you
          to try new features before they are generally available.
        </p> 
        <p>
          In order to use snapshot releases, you need to add the Sonatype OSS Snapshots
          repository in your Maven <tt>pom.xml</tt> file, like this (the · dots are only for 
          indenting, remove them in your code):
        </p>
        <code>
          &lt;repositories&gt;<br />
          ··&lt;repository&gt;<br />
          ····&lt;id&gt;sonatype-nexus-snapshots&lt;/id&gt;<br />
          ····&lt;name&gt;Sonatype Nexus Snapshots&lt;/name&gt;<br />
          ····&lt;url&gt;<b>https://oss.sonatype.org/content/repositories/snapshots</b>&lt;/url&gt;<br />
          ····&lt;snapshots&gt;<br />
          ······&lt;enabled&gt;true&lt;/enabled&gt;<br />
          ····&lt;/snapshots&gt;<br />
          ··&lt;/repository&gt;<br />
          &lt;/repositories&gt;
        </code>
        <p>
          Also, you will have to modify your Jasypt dependency/ies to use a 
          <i>snapshot version</i>, which usually consists of the version number of the
          <b>next</b> release (not the current one), followed by <tt>-SNAPSHOT</tt>.
          For example, while <tt>1.9.2</tt> is the latest published stable release,
          snapshots will probably appear under the <tt>1.9.3-SNAPSHOT</tt> or
          maybe <tt>1.10.0-SNAPSHOT</tt> version numbers:
        </p>
        <code>
            &lt;dependency&gt;<br />
            ··&lt;groupId&gt;org.jasypt&lt;/groupId&gt;<br />
            ··&lt;artifactId&gt;jasypt&lt;/artifactId&gt;<br />
            ··&lt;version&gt;<b>1.9.3-SNAPSHOT</b>&lt;/version&gt;<br />
            ··&lt;scope&gt;compile&lt;/scope&gt;<br />
            &lt;/dependency&gt;
        </code>
      </answer>
    </faq>
    


    
  </part>



  <part id="passwords">
    <title>Encrypting paswords</title>

    <faq id="i-am-already-using-X-for-encrypting-passwords">
      <question>I am already using X for encrypting passwords. Why would I want to use jasypt instead?</question>
      <answer>
        <p>
          Well, first of all, if you are simply using a <tt>Message.digest()</tt> 
          or a <tt>DigestUtils.md5()</tt>
          call to encrypt your passwords and store them in a database, you should know
          that your password system is much weaker than you think, and that
          acquiring access to your application could be easy for any attackers.
          And it even becomes worse as the number of users in your application increases.
        </p>
        <p>
          If you want to learn why this happens and how you could try to avoid it,
          have a look at the article "<a href="howtoencryptuserpasswords.html">How 
          to encrypt user passwords</a>".
        </p>
        <p>
          ...and, if you are not using such calls but some other APIs or 
          techniques, maybe you should consider reading
          it anyway to know if jasypt can help you do things better.
        </p>
        <p>
          If you are using Spring Security (former Acegi Security) for encrypting
          passwords in your application, check the corresponding question in
          this FAQ (below) to see what jasypt can do for you.
        </p>
      </answer>
    </faq>

    <faq id="i-am-already-using-spring-security-for-encrypting-passwords">
      <question>I am already using Spring Security / Acegi for encrypting passwords. Why would I want to add jasypt to my security infrastructure?</question>
      <answer>
        <p>
          Before all, understand that <b>jasypt is not a substitute
          for Spring Security / Acegi</b>, which is a powerful and very complete
          security framework (and which use the Jasypt author recommends). 
          Jasypt will instead <b>integrate into Spring Security / Acegi</b>
          and improve its password encoding capabilities.
        </p>
        <p>
          Some reasons for considering this integration are:
        </p>
        <ul>
          <li>First and most important, because the default standard encryptors (<tt>PasswordEncoder</tt>
          implementations) shipped with Spring Security (as of 2.0.1) are simple
          message digesters (one hashing iteration, none or user-property based fixed salt...), 
          and are not as safe as
          jasypt's password encryptors can be (learn more about random salt and
          iteration count at the article "<a href="howtoencryptuserpasswords.html">How 
          to encrypt user passwords</a>").</li>
          <li>Second, because they don't provide the same level of configuration
          capabilities as jasypt's password encryptors: algorithms, 
          parameters resolution...</li>
          <li>And third, because using jasypt will help you decoupling your
          user management logic (more bussiness-oriented) from the authentication
          and authorization component represented by Spring Security (you won't
          need to add dependencies on Spring Security's <tt>PasswordEncoder</tt>s to
          your user management logic, and will instead use classes from a more
          neutral library like jasypt).</li>
        </ul>
        <p>
          For more information on integrating Jasypt into an Spring Security-enabled
          application, please check the <a href="springsecurity.html">Jasypt + Spring Security</a> guide.
        </p>
      </answer>
    </faq>
    
    <faq id="i-want-to-encrypt-a-password">
      <question>I want to encrypt passwords and I know NOTHING about encryption. What do I have to do?</question>
      <answer>
        <p>
          Simply use <tt>org.jasypt.util.password.BasicPasswordEncryptor</tt>.
          There is nothing more you need to know (if you don't want to :-)).
        </p>
        <p>
          If you want more power (such as deciding which algorithm to use),
          then you can have a look at <tt>org.jasypt.digest.StandardStringDigester</tt>.
        </p>
        <p>
          And if you want to know more, have a look at the article 
          <a href="howtoencryptuserpasswords.html">How to encrypt user passwords</a>
          to learn about how a password should be encrypted.
        </p>
      </answer>
    </faq>
    
    <faq id="can-i-decrypt-an-encrypted-password">
      <question>Can I decrypt an encrypted password?</question>
      <answer>
        <p>
          If you have encrypted it using a message digesting technique, 
          which is precisely what you should have done (by using 
          a <tt>PasswordEncryptor</tt> implementation, 
          <tt>StandardStringDigester</tt> or similar...), <b>you cannot</b>.
        </p>
        <p>
          This is because digests are a <i>one-way</i> technique. Once you have
          created the digest, there is no way to reconstruct the original message
          (or password) back. To check if an input password matches a stored digest, 
          the password is digested itself and then both digests are matched.
        </p>
        <p>
          And why should passwords be encrypted in a way they cannot be decrypted?
          Because this is safest way to ensure that a password is known only
          to the user that created it, and that <i>no one, not even system or database 
          administrators, can know it</i>.
        </p>
      </answer>
    </faq>
    
    
  </part>


  <part id="behaviour">
    <title>Behaviour</title>
    
    <faq id="what-does-jasypt-do-to-create-password-digests">
      <question>What does jasypt do to create message/password digests, exactly? They are so different to the ones I create manually with a MessageDigest object...</question>
      <answer>
        <p>
          Jasypt follows the RSA standards for the creation of digests 
          (in fact, keys), specifically the use of <b>both a 
          (preferably random) salt and
          an iteration count</b>.
        </p>
        <p>
          The salt is an array of bytes (randomly and securely generated by default) which
          is added to the message prior to digest. The iteration count specifies
          how many times the hash function will be applied to the message.
        </p>
        <p>
          This means that the process of digesting your passwords (or any other 
          messages) with jasypt 
          is not as simple (internally speaking) as just using 
          MessageDigest, and because of this results look quite different.
        </p>
        <p>
          For learning more about how password/message digesting works in jasypt, see
          <a href="encrypting-passwords.html">Encrypting Passwords</a> or the
          javadoc for the <tt>StandardStringDigester</tt> class.
        </p>
        <p>
          For more info about the RSA standard, see <a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2127">PKCS #5: Password-Based Cryptography Standard</a>.
        </p>
      </answer>
    </faq>
    
    <faq id="if-i-create-two-digests-of-the-same-message">
      <question>If I create two digests of the same message (or I encrypt the same password twice), results differ. Is that normal?</question>
      <answer>
        <p>
          If you are using a random salt generator (which is the default), 
          yes, it is. It is normal and, specially if you are
          encrypting a password, it is good for you.
        </p>
        <p>
          Using a random salt offers you several important security advantages
          as you can read in <a href="encrypting-passwords.html">Encrypting Passwords</a>,
          but if it is important for you that two digests of the same message
          be equal, you can set the salt size to 0 bytes or, if you
          prefer, use a different implementation of 
          <tt>SaltGenerator</tt>.
        </p>
        <p>
          A salt is also used for the obtention
          of keys for password-based encryption and so, when using a random 
          salt generator (default), two password-based encryption
          results for the same original input will also differ. Nevertheless, 
          this behaviour cannot be avoided in password-based encryption by setting
          a zero-byte long salt, as
          a salt is required by the PBE Java API itself. Thus, in this case
          you will have to use a fixed-salt <i>SaltGenerator</i>.
        </p>
      </answer>
    </faq>
    <faq id="I-see-jasypt-uses-salt-and-iteration-count">
      <question>I see jasypt uses salt and iteration count for creating digests. Does it also use them for generating keys for password-based encryption?</question>
      <answer>
        <p>
          Of course. You see the use of salt and iteration count 
          more thoroughly explained in jasypt documentation when referred to
          digests, but this is simply because many people wrongly (and dangerously) forget about 
          using them when
          doing digests of, say, passwords. Thus, it seemed important to remark
          its use when digesting.
        </p>
        <p>
          On the contrary, password-based encryption is usually done the right way, partly
          because the Java API for PBE enforces it to some extent. Anyway,
          jasypt offers you the advantage of transparently dealing with secure 
          salt generation and checking.
        </p>
        <p>
          For more info about the way password-based encryption should be done
          (and is done by jasypt), see see <a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2127">PKCS #5: Password-Based Cryptography Standard</a>.
        </p>
      </answer>
    </faq>
    <faq id="why-only-big-numbers">
      <question>Why does jasypt number encryption support only apply to <tt>BigInteger</tt> and <tt>BigDecimal</tt>?</question>
      <answer>
        <p>
          Because numbers are encrypted using the byte encryption support
          (encryption algorithms refer to bytes, not numbers), and so the
          result of encrypting a number will span a higher number of bytes than
          the original number. This provokes that a 4-byte integer needs no less
          than 16 bytes when it is in encrypted form.
        </p>
        <p>
          Because of this, only <tt>BigInteger</tt>s and <tt>BigDecimal</tt>s
          are supported in jasypt, as they provide arbitrary precision and
          so can handle such a big amount of bytes.
        </p>
        <p>
          Nevertheless, if you are looking for hibernate encryption support
          for Longs, Doubles, Integers... jasypt provides support for encrypting
          them stored into SQL VARCHAR fields (instead of NUMERIC ones).
          Have a look at the <a href="hibernate.html">Hibernate Integration
          Guide</a> for further details.
        </p>
      </answer>
    </faq>
    <faq id="store-pbe-passwords-strings">
      <question>Does jasypt store PBE encryption passwords as Strings in-memory? Isn't that a security issue?</question>
      <answer>
        <p>
          From version 1.8, Jasypt's out-of-the-box encryptor implementations do not store
          passwords as Strings in memory, but rather as char[] objects that are zeroed as soon
          as they are used. This improves jasypt's Java Virtual Machine environment safety in extreme 
          security-conscious scenarios.
        </p>
        <p>
          Besides not storing passwords as Strings (which can pose a risk because of being immutable
          objects), jasypt does its best for not creating temporary Strings storing the password at all
          during its operation --thus not having to rely on garbage collection for removing these
          from memory--, but because of the String-based java.text.Normalizer API for normalizing unicode, this 
          can only be accomplished completely by adding icu4j at the classpath so that jasypt can use
          this library for normalization instead of java.text.Normalizer (icu4j provides a char[]-based API).  
        </p>
      </answer>
    </faq>
    
  </part>  


  <part id="problems">
    <title>Problems</title>

    <faq id="i-receive-a-classnotfoundexception">
      <question>I receive a <tt>ClassNotFoundException</tt> when I try to encrypt or digest data.</question>
      <answer>
        <p>
          You probably haven't added all the required dependencies to your classpath.
          Please check the <a href="dependencies.html">Dependencies Page</a>.
        </p>
      </answer>
    </faq>

    <faq id="i-receive-a-classnotfoundexception-icu4j">
      <question>I receive a <tt>ClassNotFoundException</tt> for class com/ibm/icu/text/Normalizer when I try to encrypt or digest data.</question>
      <answer>
        <p>
          Since version 1.5, jasypt does not include ICU4j's jar files in its standard
          distribution, as this dependency is not required unless java 1.5 or older versions
          are being used and the ICU4j library is a very large jar file.
        </p>
        <p>
          You can manually download icu4j from the <a href="http://icu-project.org/">ICU4j
          website</a> or from your maven repository. 
          Please check the <a href="dependencies.html">Dependencies</a> 
          and <a href="maven.html">Jasypt + Maven</a> pages for further information.
        </p>
        <p>
          If you are receiving this error when using the CLI tools, check
          the <a href="cli.html">CLI page</a> about adding ICU4j to your
          classpath when executing the tools.
        </p>
      </answer>
    </faq>

    <faq id="encrypted-fields-not-in-where">
      <question>I do not get correct results when querying a Hibernate-mapped entity with encrypted fields when I set conditions on some of those fields.</question>
      <answer>
        <p>
          This is normal behaviour if you are using a random salt generator for your encryptor (which is the default). 
          In this case, two different encryption operations on the same data should not 
          return the same
          value (due to the use of a random salt). Because of this, none of the fields that
          are set to be encrypted when persisted can be a part of a WHERE clause in
          your search queries for the entity they belong to.
        </p>
        <p>
          If you need to query encrypted fields, <b>you should set a fixed 
          salt generator</b> to your encryptor, so that the same text encrypted
          twice will produce the same results. Although, be warned that <i>this
          will only allow you to use that field in EQUALITY comparisons inside
          a WHERE clause, and that you will be reducing your level of security
          for that field</i>.
        </p>
      </answer>
    </faq>
   
    <faq id="no-unlimited-strength">
      <question>I receive an <tt>InvalidKeyException</tt> when trying to use the <tt>StrongTextEncryptor</tt> or the <i>TripleDES</i> or other strong algorithms, although some algorithms work alright.</question>
      <answer>
        <p>
          This probably happens because you need download and install the
          <a href="http://java.sun.com/javase/downloads" target="_blank">Java 
          Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy 
          Files</a> in order to be able to use strong-encryption algorithms like TripleDES.
        </p>
      </answer>
    </faq>
   
    <faq id="i-keep-on-receiving-encryption-operation-not-possible">
      <question>I keep on receiving <tt>EncryptionOperationNotPossibleException</tt> exceptions when trying to decrypt my data.</question>
      <answer>
        <p>
          <tt>EncryptionOperationNotPossibleException</tt> is a very general exception which
          jasypt raises whenever there is a problem with encryption or decryption
          operations. It does not provide any further information to prevent the
          encryption infrastructure from showing too much information about what is going
          on (we wouldn't want an attacker to get any algorithm-specific errors...)
        </p>
        <p>
          When you get that error while decrypting, most of the times it will simply
          mean that the encrypted string you input was not adequate for the
          algorithm/password/keyObtentionIterations configuration you provided. Check
          that your encryptor is configured in exactly the same way as the one with
          which you originally encrypted the data.
        </p>
        <p>
          Also, if you are storing your encrypted data into a database, check that the
          table columns that you use to store it are big enough to host the encrypted data
          (which is always bigger than the original data). If you are transmitting your
          encrypted data via HTTP, check that you are not having problems with the
          transmission of BASE64-encoded data as URL parameters (BASE64 uses characters
          which are forbidden in URL parameters, like "="). For these uses, try
          using hexadecimal output.
        </p>
      </answer>
    </faq>

    <faq id="i-receive-null-when-encrypting-decrypting">
      <question>I receive a null output when trying to encrypt/decrypt my data using
       AES-based encryption.</question>
      <answer>
        <p>
          Since Jasypt v1.9.3 PBEWithDigestAndAES algorithms (from the JCE Provider of JAVA 8)
          are supported. They require an initialization vector (IV) parameter. By default
          Jasypt PBExxEncryptors use a NoIvGenerator for maintaining backwards compatibility
          and decrypt values encrypted with previous Jasypt versions. 
          Establishing a IvGenerator (setIvGenerator method) will solve the issue.
          The IV should be random and only used one time, so org.jasypt.RandomIvGenerator is the recommended
          one.
        </p>
      </answer>
    </faq>
    
  </part>


    
</faqs>