On 24.6.2014 15:45, Tomas Mraz wrote:
>Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with
>AES according to RFC 3394 (no padding) or RFC 5649 (with padding).
>RFC 3394 works only on blocks of 64 bits, which is not our case because
>EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get
>proper padding etc.
>And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but
>OpenSSL doesn't support RFC 5649! The patch with this functionality was
>submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state
>"new" and there was no reply to the e-mail in the original thread [4].
I am sorry, but this does not make much sense to me. Iff the SoftHSM's
C_WrapKey is really safe wrapping method for backing up and/or
replicating HSM's it must provide wrapped key in such format that the IV
is pregenerated as part of the Wrap operation and stored in the final
blob of wrapped key. Unfortunately I do not know much of SoftHSM.
SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do something against PKCS#11 standard.

In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user.

See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki – Draft 7" on

>What do we do?
>- Convince OpenSSL to review and accept the patch?
I would say the patch is not too useful as is - there are multiple
problems with it such as it is not using proper high level interfaces
for the AES encryption, etc.
Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it.

Would you review the patch if we re-write it against current OpenSSL git head?

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to