Hi, Sent from my iPhone
> On Jul 6, 2016, at 13:22, Frank Siebenlist <frank.siebenl...@gmail.com> wrote: >> For some more context on “it depends what you want to accomplish, and >> generic schemes are hard”; Bob and Alice may also want to have key ids that >> only work for _them_ — e.g. Bob and Alice’s static DH keys are used to >> generate a shared secret used for an AD key wrap scheme. > > You're right - Alice may name the key she shares with Bob: "Bob's > key", while Bob may name the same key: "Alice's key" on his end. They > can/should use what ever name is easiest to construct the cypher > messages that they want to exchange with each other. However, the key > identifier that they embed inside of the cypher message cannot be a > local nickname, but should be one that both parties can use, like the > key identifier that I'm looking for. Key wrap is symmetric, deterministic encryption; they are only local within the context of that key, not local to an identity. >>> The kid embedded in the cipher message is no more than a “hint”. It could >>> be signed as part of the whole cipher message, but its integrity can only >>> be confirmed after the message is decrypted&authenticated. Changing the kid >>> in a cipher message results in DoS, but so would flipping any other bit in >>> that message. >> >> Does a failed decryption cause Bob to reject the message, or just try all >> the other keys? If so, what’s the benefit between just giving keys names, >> like sequence numbers or even strings? > > What you do with a failed decryption is an interesting question, but > I'm not sure why it's relevant for the key identifier scheme... > (if you loop through all the keys and find one that decrypts the > message even though it doesn't match the kid... could be phishy...). I'm not sure; how you use it has relevant consequences for how efficient you can make the scheme. > You could use any key identifier you want, as long as both Alice and > Bob will know how to find the right key for that kid. > When you use uuids, or arbitrary names/strings, though, you require > Alice and Bob to agree on the (identifier, key) separately, before the > cipher message can be decrypted. > However, when you use an "intrinsic" identifier, like the one I'm > proposing, then both Alice and Bob can generate those kid's for all > the keys that they have and share, without any separate agreement - > they only have to agree on the kid-derivation method. That observation > is probably the main selling point. >>> If one believes that a simple sha2 hash is only borderline enough secure >>> (?), then maybe use a CMAC or HMAC, where you use the key on the key-value >>> itself, and the resulting tag would constitute the identifier. (I did >>> something like that in franks42/naclj with blake2) >> >> What’s the key used to compute the MAC? (In this case, I think what you >> _really_ want is AD key wrapping schemes, including GCM-SIV’s tiny mode). > > > For that blake2 scheme that I used in franks42/naclj, the > authentication-key is the key itself - you hash the key and use that > same key to provide additional integrity protection. Pretty sure > HMAC-like schemes were never meant for that purpose... but it doesn't > hurt... Do you have a proof of security for that? I'm in a car and don't have my notebook, but it seems like it'd be pretty easy to build a secure PRF for which that is not OK; I'm thinking CBC-MAC style vulns for example. Doing this securely (with a real key) is what key wrap tries to solve. >>> Or use HKDF, with maybe a kid-derivation specific constant for the salt, a >>> kid-specific info value, and a sufficient length of the resulting key, i.e. >>> identifier, that makes everybody happy. >> >> I’d probably go with BLAKE2b if this is _all_ you’re trying to do, but I >> think what you might really want is key wrap :) > > Love blake2, but it's not available in plain-vanilla pyca/cryptography... You should go fix that! ;) > Any concerns with using HKDF for this as I suggested in the gist? > https://gist.github.com/franks42/b8b28049adcdf4504271238391c3525b Seems fine; will get it a more thorough review when I get back. > Now comes my question about this "key wrap" that you so obviously try > to promote as a solution ;-)... No horse in this race; it's just that the deterministic encryption folks used to encrypt 16/32 bytes at a time and call what they do "key wrap" and it sounded a lot like what you want. Here's where I would get started: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/siv/siv.pdf > If I understand it well, key-wrap schemes also requires a second > kek-like key, which we do not have... > How would that work? See above; with a real key; perhaps not exactly what you're looking for. > Cipher messages in rest or in flight - both use cases apply - any time > you have to find the key to decrypt/verify a message through a key > identifier send along with that message. > > Multiple recipients - sure - they face the same issue of finding the > right key to decrypt - although you may use the individually shared > keys as kek's but those scenarios are probably distracting... > > Yes, sending and receiving parties must have a shared (symmetric) key > to make this work - through what key-exchange mechanism this was > achieved is not important for this scheme to work. Right. The reason I'm being so persistent is similar to why a lot of cryptographers dislike PAKE -- it's not that it's bad or hard to do -- it just seems like a weird problem to have. To quote Glyph, it sounded a bit like a jackhammer problem :) In short: HKDF and BLAKE2 seem like what you want :) lvh > Regards, Frank. > > >> >>> PS. Don’t believe I will resurrect that franks42/naclj - I’ll add a note >>> about depreciation and send them to your effort - it was a good experience >>> learning about Curve/Ed25519 and the nacl/libsodium code though - also >>> trying to keep all data structures as immutable as possible was a good >>> exercise. >> >> It definitely has. I’m working on a blog post (series of blog posts) on >> crypto API design, particularly in the context of libsodium and the JVMs >> plethora of byte types. > > Crypto API design is complicated and has been screwed up many times - > in my experience API design should probably not be left to the > cryptographers as they live on a different planet ;-) - looking > forward to that blog post! > > >> >>>> On Fri, Jul 1, 2016 at 3:53 PM, lvh <_...@lvh.io> wrote: >>>> >>>>> On Jul 1, 2016, at 12:54 PM, Frank Siebenlist >>>>> <frank.siebenl...@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 <_...@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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
