[Esapi-user] [Esapi-dev] ESAPI 2.0 crypto documentation
Kevin W. Wall
kevin.w.wall at gmail.com
Sun Apr 18 11:13:41 EDT 2010
Mike Boberski wrote:
> This is tough to discuss over email.
> In the abstract I'm pointing out that we need to further abstract
> esapi as a wrapper for crypto, not to pull crypyo functions, key
> management, etc into esapi. Capture in esapi certain design patterns
> like encrypt for data at rest, like associate keys with users, etc.
> Crypto is like auth, not likely I'd use esapi's class, but I'd
> use/extend the interface. You're trying to subsume the functionality
> like encoding, which is not the right thing to do for this type of
> control, need to make a sample ref implementation that is easy to
> replace. Should always assume you're calling a validated module, not
> try to reinvent the blood and guts of this stuff.
This is somewhat along the lines of the worksheet(s) that I've been
mulling over for the cryptography section of the OWASP Dev Guide.
I don't have anything concrete yet, but I've been thinking along the
lines of categorizing things on two axes: one axis is data at rest vs.
data in transit, and the other axis addresses the problem you are trying
to address--e.g., confidentiality, data integrity, non-repudiation,
authentication, etc. I'd had been hoping to have a rough draft by now,
but between some remodeling, replacing a dishwasher, and doing taxes,
I just haven't had the time.
Not sure that's the direction you are thinking, but it sounds we are
on similar paths. I just wasn't planning on taking it that extra mile
of actually providing API interfaces for this sort of thing, but instead
was going to describe how to do them with the crypto primitives that
But as I pointed out in previous email, my expectations would be that
dev teams would extend / wrap ESAPI crypto APIs in their own classes
and as part of that, also add a bit of application context. This makes
sense. What I am not convinced of is whether there could be enough
commonality / reuse possibility at this higher abstraction level to
merit putting something this into ESAPI itself. In many ways, the higher
you move up in terms of abstractions, the harder it is to develop
reusable software. I think things vary a lot more near the application
level than at (say) the crypto primitives level. It might be worth doing
if we can get sufficient feedback from the ESAPI-Users list, but it's
probably going to be hard to gain consensus.
> Maybe we can talk on the phone some time.
Sure. I'll send you (Mike) my cell # off-list along with some times I
might be available to talk. Not sure I want my cell # in the list
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
More information about the Esapi-user