Hi lvh, Guess you're the "lvh" who is responsible for "lvh/caesium" ;-). Good to see that you've reanimated that project! Believe you were kind of distracted for awhile, which "forced" me to play around with "franks42/naclj"... which has been on live-support for about a year now, because my new job consumes even my playtime.
As part of that "franks42/naclj" effort, I suggested to standardize the derivation of a kid from the two curve25519 public keys. However, I recognize that you do not always have any DH-keys available when you have a bare symmetric key, so I suggested a scheme based on blake2. I wrote up some rationale for those choices here: "https://github.com/franks42/naclj/blob/master/Keys%2C%20IDs%2C%20and%20URNs.md";, but never got much traction on the libsodium list,... and then I got distracted. Now I'm faced again with similar key-management issues, which could benefit from such key-derived kid's - so I try again. In summary, your suggestions all resonate very well, but... there are too many of them. Let's just pick one identifier derivation mechanism for symmetric keys, document it, implement it, use it! Groetjes, Frank. On Fri, Jul 1, 2016 at 9:51 AM, lvh <_...@lvh.io> wrote: > Hi Frank, > >> On Jul 1, 2016, at 11:11 AM, Frank Siebenlist <frank.siebenl...@gmail.com> >> 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 > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
