<html><body bgcolor="#FFFFFF"><div>Mike,</div><div><br></div><div>Sorry for the short replies - I'm on my mobile and on the run.</div><div><br></div><div>I do not think we want to save crypto keys in the user object - or anywhere in the app at all. It defeats the purpose of crypto storage, especially when trying to defend again insider threat agents.</div><div><br></div><div>Crypto Keys, IMO, should be stored in a key vault. We also need to consider the more difficult aspects of crypto storage such as 'asychronous' key rotation (key rotation outside of any user activity).<br><br>Jim Manico</div><div><br>On Apr 17, 2010, at 4:49 AM, Mike Boberski &lt;<a href="mailto:mike.boberski@gmail.com">mike.boberski@gmail.com</a>&gt; wrote:<br><br></div><div><span></span></div><blockquote type="cite"><div>I've been putting some thought into ESAPI crypto lately, as I've been working on the PHP port...<div><br></div><div>I think we've been not looking at crypto in as big-picture a way as the other controls have been looked at (I am certainly guilty of that, latching onto e.g. FIPS 140-related implementation details), and I think the below/something along those lines will further promote the use of ESAPI to wrap crypto.<br>

<div><br></div><div>In other words, while the 2.0 crypto is technically excellent by anyone's measure, it is not ESAPI-ish (i.e., "make it as easy as possible") enough.&nbsp;</div><div><br></div><div><b>Discussion item #1. </b>I think the following function names would be more ESAPI-ish:</div>

<div><br></div><div><ul><li>protectFromDisclosure</li><li>protectFromDisclosureAndModification</li><li>protectFromDisclosureWhileAtRest</li><li>protectFromDisclosureAndModificationWhileAtRest</li><li>protectFromDisclosureWhileInTransit</li>

<li>protectFromDisclosureAndModificationWhileInTransit</li><li></li><li>unprotectFromDisclosure</li><li>unprotectFromDisclosureAndModification</li><li>unprotectFromDisclosureWhileAtRest</li><li>unprotectFromDisclosureAndModificationWhileAtRest</li>

<li>unprotectFromDisclosureWhileInTransit</li><li>unprotectFromDisclosureAndModificationWhileInTransit</li><li>... maybe then additional qualifier-ish names, e.g.&nbsp;protectFromDisclosureInOracle (maybe output format is in some optimized format for Oracle for example),&nbsp;protectFromDisclosureInPDF (maybe wrap interesting things like this), etc. ...</li>

<li>... maybe then additional variations, e.g.&nbsp;protectFromDisclosureUsingMaximumKeySize, etc. ...</li></ul></div><div><div><div><br></div><div><b>Discussion item #2.&nbsp;</b>I think we need to do better with key management; without going into gory detail or proposing something too hard to implement, I think crypto keys need to be associated with User objects as properties/attributes&nbsp;.</div>

<div><br></div><div><ul><li>Users (likely in many cases users representing server apps) will need to be authenticated and logged in with all of the existing ESAPI plumbing (logging, intrusion, etc.) before able to access keys</li>

<li>This will make clear associations of keys, allow easily for multiple keys (Encryptor would just use keys of whomever is logged in), and again leverage all the existing plumbing.</li></ul></div></div></div><div><br></div>

<div><b>Discussion item #2.&nbsp;</b>I think we need to standardize on PKCS#7 (ideally CMS) formats&nbsp;</div><div><br></div><div><ul><li>Then, include a parameter in e.g.&nbsp;protectFromDisclosure to return binary or base 64.</li><li>

Perhaps further optimize with functions where this parameter would then be hardcoded as mentioned above for the example&nbsp;protectFromDisclosureInOracle&nbsp;</li></ul><div><br></div><div><br></div></div><div><br clear="all">Mike<br>


<br><br><div class="gmail_quote">On Fri, Apr 16, 2010 at 11:03 PM, Josh Drummond <span dir="ltr">&lt;<a href="mailto:joshdrummond@yahoo.com"><a href="mailto:joshdrummond@yahoo.com">joshdrummond@yahoo.com</a></a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Kevin,<br>
<br>
Finally got around to reading your new docs (most notably the user-guide) and updating my own open-source project converting away from the deprecated methods to the new CipherText serialized techniques we discussed a while back. &nbsp;I'm happy to report that the documentation was easy to read/understand and the code changes in 2.0-rc6 worked very well, so thanks very much. &nbsp;It might be worth suggesting using the Base64 encoding/decoding class also included in ESAPI in that document, however that might be obvious. &nbsp;Sure for persistence, serializing the CipherText to a string requires a much longer database column than the old way, but it beats converting to blob columns, so its a good compromise!<br>


<br>
Thanks,<br>
~Josh<br>
<br>
<br>
----- Original Message ----<br>
From: Kevin W. Wall &lt;<a href="mailto:kevin.w.wall@gmail.com"><a href="mailto:kevin.w.wall@gmail.com">kevin.w.wall@gmail.com</a></a>&gt;<br>
To: Mike Boberski &lt;<a href="mailto:mike.boberski@gmail.com"><a href="mailto:mike.boberski@gmail.com">mike.boberski@gmail.com</a></a>&gt;; ESAPI-Developers &lt;<a href="mailto:esapi-dev@lists.owasp.org"><a href="mailto:esapi-dev@lists.owasp.org">esapi-dev@lists.owasp.org</a></a>&gt;; ESAPI-Users &lt;<a href="mailto:Esapi-user@lists.owasp.org"><a href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</a></a>&gt;<br>


Sent: Sun, February 14, 2010 9:37:29 PM<br>
Subject: [Esapi-dev] ESAPI 2.0 crypto documentation<br>
<br>
Mike,<br>
<br>
I took a first cut at 3 new / updated docs. You can find them at:<br>
<br>
&lt;<a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html" target="_blank"><a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html">http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html</a></a>&gt;<br>


 &nbsp; &nbsp; &nbsp; &nbsp;Describes reasons we are changing the ESAPI symmetric crypto for 2.0<br>
<br>
&lt;<a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-ciphertext-serialization.pdf" target="_blank"><a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-ciphertext-serialization.pdf">http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-ciphertext-serialization.pdf</a></a>&gt;<br>


 &nbsp; &nbsp; &nbsp; &nbsp;Description of the portable serialization of CipherText objects. This is<br>
 &nbsp; &nbsp;primarily for other ESAPI programming language implementations if they<br>
 &nbsp; &nbsp;wish to implement something that will be able to interact with the<br>
 &nbsp; &nbsp;ESAPI Java 2.0 crypto.<br>
<br>
&lt;<a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html" target="_blank"><a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html">http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html</a></a>&gt;<br>


 &nbsp; &nbsp; &nbsp; &nbsp;User Guide for Symmetric Encryption in ESAPI 2.0<br>
<br>
Please provide feedback. Note that none of these updated documents are in the<br>
latest ESAPI-2.0-rc5.zip file.<br>
<br>
-kevin<br>
--<br>
Kevin W. Wall<br>
"The most likely way for the world to be destroyed, most experts agree,<br>
is by accident. That's where we come in; we're computer professionals.<br>
We cause accidents." &nbsp; &nbsp; &nbsp; &nbsp;-- Nathaniel Borenstein, co-creator of MIME<br>
<br>
_______________________________________________<br>
Esapi-dev mailing list<br>
<a href="mailto:Esapi-dev@lists.owasp.org"><a href="mailto:Esapi-dev@lists.owasp.org">Esapi-dev@lists.owasp.org</a></a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-dev" target="_blank"><a href="https://lists.owasp.org/mailman/listinfo/esapi-dev">https://lists.owasp.org/mailman/listinfo/esapi-dev</a></a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Esapi-user mailing list</span><br><span><a href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/esapi-user">https://lists.owasp.org/mailman/listinfo/esapi-user</a></span><br></div></blockquote></body></html>