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

[lvh]

Hi,

Apologies in advance for late and possibly duplicated message. Originally sent from my iPhone, from wrong e-mail address, which made the mailing list manager unhappy.

> On Jul 6, 2016, at 13:22, Frank Siebenlist <frank.siebenlist at gmail.com <mailto:frank.siebenlist at 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 <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160707/4e19079d/attachment-0001.html>