Hi Frank, > On Jul 1, 2016, at 11:11 AM, Frank Siebenlist <[email protected]> > wrote: > > snip snip key identifiers
This is why some key derivation functions and PRFs have “purpose” or “info" fields, yes; including BLAKE2 and HKDF. Deriving a lesser key (which might just be a keyid) is a perfectly valid strategy from objcap practice. I’m doing something similar in the scheme of a larger semiprivate key scheme using libsodium. You probably do want something that explicitly supports that instead of just implicitly picking a particular nonce or whatever — I’m not sure which nonce you’re referring to, I don’t think the systems you mentioned take one. TL;DR: make the derivation completely distinct based on what you’re deriving and why you’re deriving it :) You might also want to look at the related concept of NMR and key-wrap, which might let you solve the problem at a slightly different part of your protocol; essentially giving you a protected key with associated data about that key. It’s not entirely clear what the people standardizing GCM-SIV want to do exactly (other than “not TLS”, I don’t think they’ve said), but this is the obvious choice, especially given GCM-SIVs separate code path for tiny messages and the historical linking of the two from a crypto design perspective. I am also writing NMR stuff on the side in libsodium/caesium, but that focuses mostly on being a Fernet replacement, rather than a keywrap, using secretbox (which makes it easy because big nonce space). Pretty sure I can translate it to the AEAD schemes, but the security proof gets iffier. Which reminds me: we should talk about Clojure bindings to libsodium some time :) lvh _______________________________________________ Cryptography-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/cryptography-dev
