[Esapi-dev] Discussion of CipherText serialization for ESAPI 2.0 crypto
greg at denimgroup.com
Mon Jan 4 12:45:40 EST 2010
My general take on the whole thing is whatever the simplest method is that still exposes developers to the options available to them would be ideal. Specifically, exposing enough of the encryption pieces so that they know that things can be represented as strings or byte arrays, and that IVs can be stored with the encrypted data or separately and that there are tradeoffs in doing so.
If there was something that would complement DefaultCipherText.getEncodedIVCipherText() on the deserialization side I would be happy.
From: esapi-dev-bounces at lists.owasp.org [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Jim Manico
Sent: Sunday, January 03, 2010 9:20 PM
Subject: Re: [Esapi-dev] Discussion of CipherText serialization for ESAPI 2.0 crypto
> Yeah, generally at (my company) we just return byte and let the applications
> determine how they want to handle it. (Although we do also provide a
> base64 encoder.) I would have preferred this (and that's why I originally
> argued that 'String encrypt(String)' and 'String decrypt(String)' decrypt
> methods should be deprecated, not just in the LegacyJavaEncryptor, but in
> the Encryptor interface. It was an argument that I felt I lost in the wider
> ESAPI-Dev forum.
Kevin, I have the unpopular opinion of agreeing with you 100% on this
topic. Both the "String encrypt(String)' and 'String decrypt(String) "
are significant security (or at least functionality) Anti-Patterns in my
mind, and I strongly believe they must be deprecated for ESAPI 2.0
final, and removed for ESAPI 3.0 final.
I'm holding up the ESAPI 2.0 final release until we resolve this in some
way. This is the most difficult API to figure out, and I'd like to call
a (Skype) meeting to try to resolve this. I'm also starting to think
that understanding and really being "FIPS compliant" deserves further
investigation and I'd like to get some of Mike's time to walk us though
Please considering participating in this meeting. Let me know your
interest. I'll start sending out possible invites, soon, to make this
- Jim Manico
OWASP ESAPI Project Manager
OWASP Podcast Host/Producer
Esapi-dev mailing list
Esapi-dev at lists.owasp.org
More information about the Esapi-dev