On 02.07.21 12:53, Richard Weinberger wrote: > Ahmad, > > ----- Ursprüngliche Mail ----- >> Von: "Ahmad Fatoum" <a.fatoum@xxxxxxxxxxxxxx> >>> I'm still think that hard coding the key modifier is not wise. >>> As I said[0], there are folks out there that want to provide their own modifier, >>> so it is not only about being binary compatible with other CAAM blob patches in >>> the wild. >> >> I don't think the characterization as a salt is accurate. AFAIU it's more >> of a namespace, so blobs being loaded are "type-checked" against the modifier. > > Well, the CAAM programmer's reference manual states that the blob key is a 128 bit modifier > and has two purposes: > 1. It can be used as tag to provide separation between blobs to detect accidental replacement of blobs. > 2. But it can also be treated as secret to provide additional protection. Because the blob encryption > key derivation includes the key modifier. > > While you have case 1 in mind, I care about case 2. :-) Ah, using the key modifier as a passphrase didn't occur to me. >>> I'll happily implement that feature after your patches got merged but IMHO we >>> should first agree on an interface. >>> How about allowing another optional parameter to Opt_new and Opt_load >> >> Sound good to me. pcrlock for TPM trusted keys has the same interface. >> >> I'd prefer the new option to accept strings, not hex though. > > Both is possible. If the string starts with "0x" it needs to be decoded to a > 128 bit key. Otherwise it has to be a up to 16 byte string. Fine by me. Looking forward to your patches. :-) Cheers, Ahmad > > Thanks, > //richard > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
