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