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.siebenl...@gmail.com
> <mailto: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
> <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
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
