On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: > 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  but the ticket is in > >> >state > >> >"new" and there was no reply to the e-mail in the original thread . > > 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.
Sounds completely bogus, but in this case we'll have to either provide a random IV ourselves (and then store it alongside or provide data with a confounder at the start implementing padding on our own. > 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? > -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel