[Freeipa-devel] DNSSEC key wrapping: cryptographer needed

[Petr Spacek]

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
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf

>
>> >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