[Cryptography-dev] "intrinsic" symmetric key identifier?

[lvh]

> On Jul 1, 2016, at 12:54 PM, Frank Siebenlist <frank.siebenlist at gmail.com> wrote:
> 
> Hi lvh,
> 
> Guess you're the "lvh" who is responsible for "lvh/caesium" ;-).

Yup. I’m also a founding member of PyCA and the resident cryptographer, which is why I’m on this list :-)

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

It did what I needed it to do at the time, so I didn’t fix what wasn’t broken ;-) I don’t recall anyone reaching out or filing issues. Once someone did ask questions and contributed code, I was happy to merge/review/cut new releases/do new development. More dev is happening now to scratch my own itch :)

Currently I’m doing a lot of work around NMR as mentioned before, and API design around e.g. different byte buffer types, so that for example you can efficiently dump a nonce and a ciphertext in the same buffer, or derive multiple keys in one iteration of BLAKE2, etc. Also a bunch of work around e.g. pinning and verification of the produced binding and related benchmarking :)

I invite you to look at caesium again, because some of the criticisms you make in naclj’s README no longer apply (e.g. caesium no longer uses kalium and instead binds libsodium directly, albeit for a different reason than what naclj mentions). Because the binding is done in Clojure, it can do all sorts of metaprogramming including binding every permutation of a particular method for various byte types in addition to the inspection mentioned above, e.g.: https://github.com/lvh/caesium/blob/master/src/caesium/binding.clj#L56-L62

Do you intend to continue to develop naclj, or is it effectively retired?

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

Is that scheme documented anywhere? I wonder what the use case is for two curve25519 pubkeys — the “obvious" case would seem to easily degenerate to the shared symmetric secret (after doing a DH exchange).

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

I think there are a few problems preventing this from happening right now, including:

- Historically, cryptographers have not researched key wrap anywhere near as much as other schemes. I think the only reason it’s en vogue now is the interest in NMR, which at least a handful of cryptographers (Rogaway, Krovetz, and humbly, myself) care about now, and is incidentally a related problem.
- People want subtly different things for their protocols, further reducing interest. Do you just want to identify a key? That’s fine, but a problem many protocols dodge. Do you want to ship a key to someone who already has a secret or asymmetric key? AEAD (including NMR AEAD in particular, so key wrap) and just asymmetric encryption (a la non-PFS TLS or GPG) is probably where you’re going to land.
- How does this fit in a grander protocol and what is that protocol trying to accomplish?
- How is the key identifier authenticated? What prevents Mallory from just modifying the key id bytes to effectively deny service? E.g. if I’m doing this to make sure I can rotate keys effectively, how do I auth that? Ideally without replacing an unrotatable secret key with another unrotatable secret key :D (Effective key rotation for KEKs is definitely something I care about.)
- When keys are being sent alongside messages, how do we make this not a footgun for e.g. key selection attacks? (Granted, harder for EdDSA, but I want protocols to be correct for arbitrary schemes :)). PyCA cares about recipes being not footguns. That’s a mixed bag: on the one hand, it means we can give safe advice, on the other hand, it does mean that all we have is Fernet...

Overall, I think this is a reasonable idea for some protocols, but I think we need to be extremely clear about what that is, who it’s for, and how to use it.


lvh

> Groetjes, Frank.
> 
> On Fri, Jul 1, 2016 at 9:51 AM, lvh <_ at lvh.io> wrote:
>> Hi Frank,
>> 
>>> On Jul 1, 2016, at 11:11 AM, Frank Siebenlist <frank.siebenlist at 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 at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 643 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160701/a4542067/attachment-0001.sig>