[Esapi-user] [Esapi-dev] ESAPI 2.0 crypto documentation
mike.boberski at gmail.com
Sat Apr 17 10:49:39 EDT 2010
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
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
- ... 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
- 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)
- 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
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!
> ----- 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
> I took a first cut at 3 new / updated docs. You can find them at:
> Describes reasons we are changing the ESAPI symmetric crypto for 2.0
> 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.
> User Guide for Symmetric Encryption in ESAPI 2.0
> Please provide feedback. Note that none of these updated documents are in
> latest ESAPI-2.0-rc5.zip file.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user