[Esapi-dev] Towards ESAPI 3

Chris Schmidt chris.schmidt at owasp.org
Wed Dec 11 02:13:10 UTC 2013


I don't have time to fully process this right at the moment - I am in
Baltimore and headed out for a drink now; however - my off the cuff
answers are thus:

1) Focus on the interface first - so no thought about CTOR because how
the implementation is constructed will be solely up to the implementation.

2) For the reference implementation of the Encryptor, I think you kind
of have free reign here - the beauty of the new model is that we are not
tied to ESAPI 2.x constructs or ideals at all; so if you want a CTOR
that takes Properties, build it! I trust your judgement on the best way
to design *and* implement the encryption.

~C

On 12/10/13, 6:06 PM, Kevin W. Wall wrote:
> Chris,
>
> As you are aware, the security configuration in
> ESAPI 2.x and earlier is a mess. Because the crypto
> has need to change be able to support alternate
> encryption algorithms simultaneously (e.g., AES
> *and* DESede for example), I am rewriting the
> JavaEncryptor so that it is no longer a singleton.
> This will allow me to support that as well as
> being able to fully support NIST KDF 'context'
>
> which will help remove secret key / IV reuse
> (as unlikely as that may be) with any stream
> cipher mode that might be used.
>
> Anyhow, for now, that is in ESAPI 2.1.x, I was
> NOT planning on tweaking the Encryptor interface.
> I intend to completely rewrite that for 3.0, so
> this means that I intend to add some new methods
> and CTORs directly in JavaEncryptor (ugh! why didn't
> we pick DefaultEncryptor to follow the pattern of
> most other ESAPI reference implementations, but
> I digress).
>
> Given that they are at least a 1/2 dozen or
> so crypto-relatedd properties that a developer
> may wish to tweak from one instance of JavaEncryptor
> to another (e.g., encryption algorithm, signature
> algorithm, hash iterations, etc.), I think that it
> is obvious that I do not want to provide setters
> for each of these possibilities. Likewise, I
> think having a new CTOR where a developer has
> to specify all of these properties separately is
> likely to be a problem as well.
>
> So my proposal is to do provide a new CTOR something
> like this:
>     /**
>     *   Construct a new {@code JavaEncryptor} instance with the specified
>     *   properties. The properties from {@code ESAPI.properties}
>     *   are first applied and the specified properties are then loaded via
>     *   the {@code Properties(Properties)} constructor to override the
>     *   defaults.
>     *
>     *   @param  props   New properties that override the default
>     *                   crypto-related properties. Note that these
> property
>     *                   values only apply to this particular instance.
> If an
>     *                   unknown property or a non-crypto related property
>     *                   is given, then those properties are simply
> silently
>     *                   ignored and the relevant default property is used
>     *                   instead.
>     */
>     public JavaEncryptor(Properties props)
>
> [Note: Alternately, there could be a new
> JavaEncryptor.getInstance(Properties)
> method. For now, let's go with the CTOR approach.]
>
> Now, here is the rub. Because we didn't specify a separate class or
> interface to specify ESAPI property names (e.g.,
> Encryptor.CipherTransformation),
> if we allow this, so we will developers hard-coding these property
> names into
> their source code in order to use this new functionality. That's
> something that
> I think that we should avoid as it makes the migration path to ESAPI 3.0
> that much more difficult.
>
> So, it would be nice if we had these property names hard-coded as
> constant strings somewhere that they could use them.
>
> But wait...we already do...sort of. They are all there the reference
> implementation, org.owasp.esapi.reference.DefaultSecurityConfiguration.
>
> But wait...that's a reference implementation class, so even though these
> properties are public, we probably do NOT want to encourage to do things
> like:
>
>   tdesEncryptor = new JavaEncryptor(
>       new Properties().setProperty(
>          
> DefaultSecurityConfiguration.CIPHER_TRANSFORMATION_IMPLEMENTATION,
>           "DESede/CBC/PKC5Padding") );
>
> Surely that is even uglier than hard-coding it as:
>
>   tdesEncryptor = new JavaEncryptor(
>       new Properties().setProperty("Encryptor.CipherTransformation",
>                                    "DESede/CBC/PKCS5Padding") );
>
> One problem as I see it is that the ESAPI property names are defined in
> org.owasp.esapi.reference.DefaultSecurityConfiguration. (They are also
> in org.owasp.esapi.DefaultSecurityConfigurationTest under src/test/java
> as well, so we've managed to screw ourselves by putting them in two
> places.)
>
> Anyhow, the obvious, easy thing to do would seem to pick some new
> class and
> move all these property names to there as public static final Strings.
> E.g.,
> something like:
>     org.owasp.esapi.ESAPIPropNames
> Or if we every intend to bounce every support other ESAPI
> configuration constructs
> such as loading from an XML file, instead of simple Java property
> names, we may
> want XPaths so perhaps either we have multiple property files, such as:
>
>     org.owasp.esapi.ESAPIJavaPropNames
>     org.owasp.esapi.ESAPIXPathPropNames
>     etc.
> (or alternately, use nested classes, which IMO just makes things messier).
>
> Anyway, I just wanted to get your idea for an approach. The kludge that we
> have with (re)setting the SecurityConfiguration from the ESAPI service
> class
> is not suitable for production and neither is the current (deprecated)
> hack
> that I have now that simply is intended to allow me to test multiple
> algorithms.
>
> But thought I'd ask you and the larger ESAPI developer community
> (assuming there
> are more than the two of us still subscribed to this mailing list ;-)
> to get
> your feedback.  I don't really think this will impact the crypto
> interfaces
> for ESAPI 3.0, but I do think it could have a major impact on how
> difficult
> we make that part of the migration path from ESAPI 2.x to 3.0.  And
> since I
> am gutting JavaEncryptor for other reasons (to address CVE-2013-5960;
> CVE-2013-5679
> was fixed, but the other is a design issue), now seems like the right time
> to do this.
>
> Thoughts?
> -kevin
> -- 
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-dev/attachments/20131210/f076d1dd/attachment-0001.html>


More information about the Esapi-dev mailing list