[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- dmlloyd commented on 11 Jan It doesn't have to be a dichotomy. We just have to adhere to the contract of the password class, which is that a Password object contains everything needed to represent the password, and that all of a Password object's fields are inputs into the password content (i.e. no "optional" data is allowed). Since IV is not required for all masking types, then we need to either restrict the MaskedPassword type to only PBEwithMD5andDES (and other algorithms that may exist with no requirement to use IV) or else introduce a second MaskedPasswordWithIV type which includes IV, with a corresponding AlgorithmParameterSpec if necessary. In order to store such a password, you could (for example) introduce a credential store which stores the IV and/or initial key material in the configuration for the store, or uses a constant (like PB), and stores only the ciphertext in the store itself, assembling the Password object only on read. But doing so is not necessary. Our normal keystore-backed credential store can (and should) easily encode the additional information alongside the password (this credential store implementation simply DER-encodes the constituent parts of each password type). -- This message was sent by Atlassian JIRA (v7.2.3#72005)