CODEWITHSUNDEEP
javasecurityencryptionpadding
Demento
Demento

Reputation: 4297

Are the available padding schemes compliant to the BSI guideline

I am currently evaluating the cryptographic capabilities of the ESAPI security library for Java. My goal is to verify that the ESAPI supports an symmetric encryption method that is suggested by this guideline written by the BSI (link goes to a German document, no English version available).

As far I am able to use the suggested AES-128 in CBC mode. Unfortunately the BSI only suggests the following 3 padding schemes (page 10 in the document):

The ESAPI library only supports PKCS5 Padding and ISO-10126 Padding (which is outdated, according to Wikipedia). Now I am wondering if the PKCS5 padding scheme might comply with RFC 4303 (see page 13 and 14). In my opinion it looks compatible, but a second opinion would be helpful. Can anyone with a more solid cryptographic background shed some light on this? If I made any mistakes in my analysis so far it would also be great if you could point them out. Maybe I am over complicating things and some of those schemes are equivalent and I missed that.

Upvotes: 1

Views: 1127

Answers (2)

Kevin W. Wall
Kevin W. Wall

Reputation: 1462

ESAPI should support whatever padding scheme that is available and supported by your JCE provider. It just happens to use PKCS#5 padding by default, but that can be changed by tweaking the Encryptor.CipherTransformation property in your ESAPI.properties file.

ESAPI uses whatever JCE provider that your JVM uses by default. Generally this is SunJCE. However, this may also be changed via the Encryptor.PreferredJCEProvider property in ESAPI.properties. SunJCE only supports NOPADDING, PKCS5PADDING, ISO10126PADDING padding schemes for AES in JDK 1.6. (IIRC, I don't think that ISO-10126 padding is supported in JDK 1.5 and earlier, but I haven't confirmed this.) However, other padding schemes may be available from other JCE providers such as Bouncy Castle. (According to this, http://www.bouncycastle.org/specifications.html, it appears as though Bouncy Castle supports ISO-7816-4 padding via ISO7816d4Padding. I have not tested this, but if it doesn't work, please show an email to the ESAPI Users list at or open a Google Issue at http://code.google.com/p/owasp-esapi-java/issues/list and I will try to get it fixed for you.)

BTW, I don't read German, but not sure what the concern with PKCS#5 padding is unless perhaps it is a padding oracle attack. If so, ESAPI has you covered as long as you either use a cipher mode that supports message authenticity such as GCM or CCM (both of which are NIST approved) or use ESAPI so that it ensures message authenticity via an HMAC. The latter is controlled via the property Encryptor.CipherText.useMAC, which is set to 'true' by default in the delivered standard ESAPI.properties file.

-kevin wall

Upvotes: 1

vhallac
vhallac

Reputation: 13937

To answer the question of whether PKCS#5 padding and RFC 4303 padding mechanisms are compatible: no, they are not.

First off, my reading of RFC 4303 indicates that the padding bytes get values of 01, 02, ..., and PKCS#5 puts the number of padding bytes as the value on all padding bytes. So, the padding of 2 bytes would be 01 02 in RFC 4303, and 02 02 in PKCS#5.

The second discrepancy I've seen is the actual number of bytes to pad. PKCS#5 indicates that you add a full block of padding when the message is already a multiple of block length. I didn't see such a requirement in the RFC4303. Only that the padding is between 0 and 255 bytes. However, apart from incorrect values, a PKCS#5 pad would be acceptable in length for RFC 4303.

Upvotes: 1

Related Questions