[OWASP-ESAPI] Any reason OWASP ESAPI doesn't have a HexEncoder Codec?

Kevin W. Wall kevin.w.wall at gmail.com
Thu Aug 20 01:22:01 EDT 2009

Hi Neil.

You wrote:
> Jim,
> In the past I've found base64 is the preferred way to encode IVs, kets,
> etc so it plays nicely with OpenSSL for example.  I do not know if
> OpenSSL or other implementations choke on non-base64 but I know it was a
> hard requirement when I fudged together our encryption library.

Saw this post to the list and the comment about OpenSSL and base64 encoding.
My goal is to make it as simple as possible to grab a good (fixed) IV. Since
some cipher algorithms have known "weak" IVs (e.g., DES, and therefore DESede,
aka, 3DES), I wanted people to just be able to grab one from a test vector

Below is my write up to Jim on this matter.

BTW, I don't mean that I wish to hex-encode the _ciphertex_ (or actually,
the IV+ciphertext). That would still be base64-encoded. I'm only referring to
setting the new Encryptor.fixedIV property that would be used if the property
Encryptor.ChooseIVMethod is set to 'fixed'. E.g.,

	# Set in ESAPI.properties to use a specific fixed IV

It's a lot easier to tell if this is the correct length. Just count the
bytes and multiply by 2 and that gives you the bit length for the IV, which
should be the same as the cipher block length in bits.

Hope that makes sense. See below for more details.

BTW, also if you ever want to send an IV as part of an HTTP GET
query parameter, if you hex-encode it you don't have to worry about
URL encoding it. If you base64-encode it you do have to URL encode it
has some of the b64 char set (/, +, and = IIRC) need to be URL encoded.


-------- Original Message --------
Subject: Re: Any reason OWASP ESAPI doesn't have a HexEncoder Codec?
Date: Wed, 19 Aug 2009 08:21:31 -0400
From: Kevin W. Wall <kevin.w.wall at gmail.com>
Organization: Qwest IT - Application Security Team
To: Jim Manico <jim.manico at owasp.org>
References: <4A8B7BC3.6040104 at gmail.com>
<0AD950AE-F864-4E53-AE44-F95774C8993E at owasp.org>

Jim Manico wrote:
> I think we currently base64 encoding our IV's, is there any downside to
> this, or are we just doing it in a non standard way?

For IVs, it's more standard to hex-encode them...probably for one very
simple reason. It's fairly trivial to look at a hex string and know
immediately if its the correct # of bytes for an IV; all you need to
do is to count the length. The conversion from base64-encoding is not
quite a trivial. Plus if you just want to pick up and use some fixed IV
from some test vector (e.g., see RFC 3602, section 4 -- especially
useful for testing :-), than hex-encoding is how you will find them
presented. E.g., here is the first 2 test vectors from the cited RFC:

    Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
    Key       : 0x06a9214036b8a15b512e03d534120006
    IV        : 0x3dafba429d9eb430b422da802c9fac41
    Plaintext : "Single block msg"
    Ciphertext: 0xe353779c1079aeb82708942dbe77181a

    Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
    Key       : 0xc286696d887c9aa0611bbb3e2025a45a
    IV        : 0x562e17996d093d28ddb3ba695a2e6f58
    Plaintext : 0x000102030405060708090a0b0c0d0e0f
    Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a

> Kevin, can you also please re-post your other encryption question from
> last month, if you have it handy? It was very important but no one
> responded. I'd like to reopen that conversation on the list.

Well, if I knew which post you were referring to I would. If you search
for 'Kevin W. Wall' you can find my posts for July and August at these URLs,
sorted by author:

Or are you referring to an email sent off-list? If so, can you perhaps
narrow it down a bit. I've sent our about 65+ emails from this account
since July 1. Perhaps you are referring to the one with the subject of
AES 256-bit vs. AES 128-bit in ESAPI' sent to Jeff (and not to the
OWASP-ESAPI list) on 7/26/2009 09:11 PM EDT

> Thank you for digging so deeply into this Kevin.

NP. This is a lot more enjoyable than writing for _Computing Reviews_.

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 OWASP-ESAPI mailing list