我目前正在评估 Java 的 ESAPI 安全库的加密功能。我的目标是验证 ESAPI 是否支持 本指南由 BSI 编写（链接指向德语文档，无英文版本）。
到目前为止，我可以在 CBC 模式下使用建议的 AES-128。不幸的是，BSI 仅建议以下 3 种填充方案（文档中的第 10 页）：
- ISO 填充（参考 ISO-7816-4-2005）
- 符合 RFC 4303 的填充
- ESP 填充
ESAPI 库仅支持 PKCS5 填充 和 ISO-10126 Padding （根据 RFC 4303 （请参阅第 13 页和14）。在我看来，它看起来是兼容的，但第二个意见会有所帮助。任何具有更扎实的密码学背景的人都可以阐明这一点吗？如果到目前为止我的分析有任何错误，如果您能指出来，那就太好了。也许我把事情复杂化了，其中一些方案是等效的，但我错过了这一点。
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):
- ISO padding (referring to ISO-7816-4-2005)
- Padding conforming to RFC 4303
- ESP padding
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.
发布评论
评论（2）
ESAPI 应该支持您的 JCE 提供商可用并支持的任何填充方案。它只是默认使用 PKCS#5 填充，但可以通过调整 ESAPI.properties 文件中的 Encryptor.CipherTransformation 属性来更改。
ESAPI 使用您的 JVM 默认使用的任何 JCE 提供程序。一般来说，这是SunJCE。但是，这也可以通过 ESAPI.properties 中的 Encryptor.PreferredJCEProvider 属性进行更改。 SunJCE 仅支持 JDK 1.6 中 AES 的 NOPADDING、PKCS5PADDING、ISO10126PADDING 填充方案。 （IIRC，我认为 JDK 1.5 及更早版本不支持 ISO-10126 填充，但我尚未确认这一点。）但是，其他 JCE 提供商（例如 Bouncy Castle）可能提供其他填充方案。 （根据此，http://www.bouncycastle.org/specifications.html，看来就像 Bouncy Castle 通过 ISO7816d4Padding 支持 ISO-7816-4 填充一样，我还没有对此进行测试，但如果它不起作用，请向 ESAPI 用户列表发送电子邮件，或者在 http://code.google.com/p/owasp-esapi-java/issues /list，我会尽力为您修复它。）
顺便说一句，我不懂德语，但不确定 PKCS#5 填充的问题是什么，除非它是填充预言机攻击。如果是这样，只要您使用支持消息真实性的密码模式（例如 GCM 或 CCM（两者均经过 NIST 批准））或使用 ESAPI 以通过 HMAC 确保消息真实性，ESAPI 就能满足您的需求。后者通过属性 Encryptor.CipherText.useMAC 进行控制，该属性在交付的标准 ESAPI.properties 文件中默认设置为“true”。
——凯文·沃尔
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
回答 PKCS#5 填充和 RFC 4303 填充机制是否兼容的问题：不，它们不兼容。
首先，我对 RFC 4303 的阅读表明填充字节的值是
01、02、...，并且 PKCS#5 将填充字节数作为所有 填充字节的值。因此，2 个字节的填充在 RFC 4303 中为01 02，在 PKCS#5 中为02 02。我看到的第二个差异是要填充的实际字节数。 PKCS#5 指示当消息已经是块长度的倍数时添加完整的填充块。我在RFC4303中没有看到这样的要求。只是填充范围在 0 到 255 字节之间。然而，除了不正确的值之外，PKCS#5 pad 的长度对于 RFC 4303 来说是可接受的。
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 be01 02in RFC 4303, and02 02in 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.