[Esapi-user] [Esapi-dev] ESAPI 2.0 crypto documentation

Jim Manico jim.manico at owasp.org
Sat Apr 17 16:27:57 EDT 2010


Mike,

Sorry for the short replies - I'm on my mobile and on the run.

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.

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).

Jim Manico

On Apr 17, 2010, at 4:49 AM, Mike Boberski <mike.boberski at gmail.com>  
wrote:

> I've been putting some thought into ESAPI crypto lately, as I've  
> been working on the PHP port...
>
> 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.
>
> 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.
>
> Discussion item #1. I think the following function names would be  
> more ESAPI-ish:
>
> protectFromDisclosure
> protectFromDisclosureAndModification
> protectFromDisclosureWhileAtRest
> protectFromDisclosureAndModificationWhileAtRest
> protectFromDisclosureWhileInTransit
> protectFromDisclosureAndModificationWhileInTransit
> unprotectFromDisclosure
> unprotectFromDisclosureAndModification
> unprotectFromDisclosureWhileAtRest
> unprotectFromDisclosureAndModificationWhileAtRest
> unprotectFromDisclosureWhileInTransit
> unprotectFromDisclosureAndModificationWhileInTransit
> ... maybe then additional qualifier-ish names, e.g.  
> protectFromDisclosureInOracle (maybe output format is in some  
> optimized format for Oracle for example), protectFromDisclosureInPDF  
> (maybe wrap interesting things like this), etc. ...
> ... maybe then additional variations, e.g.  
> protectFromDisclosureUsingMaximumKeySize, etc. ...
>
> Discussion item #2. 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 .
>
> 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
> 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.
>
> Discussion item #2. I think we need to standardize on PKCS#7  
> (ideally CMS) formats
>
> Then, include a parameter in e.g. protectFromDisclosure to return  
> binary or base 64.
> Perhaps further optimize with functions where this parameter would  
> then be hardcoded as mentioned above for the example  
> protectFromDisclosureInOracle
>
>
>
> Mike
>
>
> On Fri, Apr 16, 2010 at 11:03 PM, Josh Drummond <joshdrummond at yahoo.com 
> > wrote:
> Hi Kevin,
>
> 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.  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.  It might be worth  
> suggesting using the Base64 encoding/decoding class also included in  
> ESAPI in that document, however that might be obvious.  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!
>
> Thanks,
> ~Josh
>
>
> ----- Original Message ----
> From: Kevin W. Wall <kevin.w.wall at gmail.com>
> To: Mike Boberski <mike.boberski at gmail.com>; ESAPI-Developers <esapi-dev at lists.owasp.org 
> >; ESAPI-Users <Esapi-user at lists.owasp.org>
> Sent: Sun, February 14, 2010 9:37:29 PM
> Subject: [Esapi-dev] ESAPI 2.0 crypto documentation
>
> Mike,
>
> I took a first cut at 3 new / updated docs. You can find them at:
>
> <http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html 
> >
>        Describes reasons we are changing the ESAPI symmetric crypto  
> for 2.0
>
> <http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-ciphertext-serialization.pdf 
> >
>        Description of the portable serialization of CipherText  
> objects. This is
>    primarily for other ESAPI programming language implementations if  
> they
>    wish to implement something that will be able to interact with the
>    ESAPI Java 2.0 crypto.
>
> <http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html 
> >
>        User Guide for Symmetric Encryption in ESAPI 2.0
>
> Please provide feedback. Note that none of these updated documents  
> are in the
> latest ESAPI-2.0-rc5.zip file.
>
> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
> MIME
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100417/810a22c1/attachment.html 


More information about the Esapi-user mailing list