Re: [MLS] Re-randomized TreeKEM

[Konrad Kohbrok <[e-mail]>]

Hi Karthik,

I think you got it right with regard to the additional guarantees gained by
RTreeKEM.

Regarding your UPKE proposal: Wouldn't A then also have to send the private keys
of each key pair to all leaves of the sub-tree blonging to the node that the key
pair is generated for? Otherwise, only A could decrypt updates sent to those
keys. These private keys would have to be encrypted under some previous one-time
key that is subsequently deleted.

Cheers,
Konrad


On 21.10.19 15:03, Karthikeyan Bhargavan wrote:
> I see. So, here’s how I read the improvements proposed in RTreeKEM.
> 
> Currently, in TreeKEM (like in ART before it) we rely on each member to
> regularly *send* updates in order to get both PCS and FS for the group secrets.
> The informal secrecy guarantees we get are that:
> - (FS) if member A sends an update in epoch N (moving the epoch to N+1), and if
> A gets compromised in epoch N+1, the messages sent in epoch N remain secret
> - (PCS) if member A sends an update in epoch N (moving the epoch to N+1), and if
> A was (passively) compromised in epoch N, the messages sent in epoch N+1 remain
> secret
> In other words, each member who sends an update gets local protection against
> compromise, encouraging vulnerable members to keep sending updates.
> 
> However, as Joel, Sandro, Yevgeniy, and Yiannis note in their paper, we could do
> better, at least for FS, if we use one-time decryption keys.
> If each recipient deletes the old decryption key after processing an update,
> then even just by *processing* an update, we get an additional  guarantee:
> - (FS’) if member A processes an update in epoch N (moving the epoch to N+1),
> and if A gets compromised in epoch N+1, the messages sent in epoch N remain secret
> 
> It is also worth remembering that Signal also has a notion of one-time prekeys
> that work similarly for new messaging sessions.
> Although the following would be a bit ridiculous to use in large dynamic groups,
> here  is a sketch to achieve the receiver FS guarantee without the need for new
> crypto.
> - Every time a member A sends an update, it generates fresh node secrets for
> nodes on the path from A to the root
> - From each node secret, A generates a large number K (= 100) private-public
> encryption keypairs and sends the public keys with the update.
> - On receiving the update, each member B stores all K public keys for each node
> in its co-path
> - Each of these public keys can be used only once for sending an update, after
> which the private key is deleted from all recipients.
> - The last public key at each node is not deleted; it can only be replaced when
> one of the members under that node sends a new update (with a fresh batch of
> public keys).
> 
> As far as I understand, the above scheme can be seen as an (inefficient)
> implementation of UPKE, right?
> Of course, it increases the size of each update by K, and only provides FS for K
> updates, after which some member has to send an update.
> Conversely, it does not require any new crypto algorithm. Is this a good
> baseline to compare UPKE schemes against?
> 
> If I am mis-reading something, do let me know!
> 
> -Karthik
> 
> 
> 
> 
> 
> 
>> On 17 Oct 2019, at 17:18, Joel Alwen <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> I think the challenge with the hash-forward approach is how to do that
>> homomorphically. I.e. what we need are two algorithms; one to refresh
>> the PK without knowing the SK (but possibly knowing a secret
>> rerandomizer delta if needed) and one to update SK (again possibly using
>> delta). So to use a hash-forward approach their must be:
>>
>> 1) a way to evolve PK forward to PK' and
>> 2) a *one-way* method to evolve SK forward to SK' compatible PK'.
>>
>> One-wayness is what gives us Forward Secrecy and "compatibility" between
>> the two key evolution methods is what allows for asynchronous (i.e. 1
>> packet) updates.
>>
>> Currently we use a secret re-randomizer delta to ensure the SK update
>> method is one-way. That is, without the delta you cant "undo" the
>> update. But that would break if we (at least naively) used some public
>> delta, say hash(ciphertext). So I think this is the challenge that we'd
>> have to overcome. Basically, make sure we SK evolution is one-way but
>> also compatible the public evolution of PK.
>>
>>
>>
>> Now one way sweet way to get all this (and more) would be to use a HIBE.
>>
>> Initial, PK for a ratchet tree node (i.e. its "identity" since this is a
>> HIBE now) is simply the empty vector PK := () while the secret key is
>> the master public key for a fresh HIBE instance SK := MSK. We also
>> include, as a second component of the nodes PK, the master public key
>> PK_0 = MPK. To "hash forward" / "re-randomize" when sending a ciphertext
>> C to that node we can do:
>>
>> PK' := (PK, hash(C)).
>> SK' := DeriveHIBEKey(PK, SK).
>>
>> So simply append hash(C) to the identity for that node and derive the
>> corresponding HIBE key.
>>
>> Ignoring the problems with using HIBE for a second, this is a very cool
>> solution. We don't need to send out the updated PK since everyone in the
>> group (and even the adversary) can compute it for themselves. We also
>> dont need a re-randomize delta as part of the plaintext because we're
>> using delta := hash(ciphertext) so the plaintext is shorter again.
>> Moreover, HIBE security means that learning SK' doesn't tell you
>> anything interesting about SK. In particular, we have forward security.
>> (In fact, FS will hold even if hash(C) were chosen *completely*
>> adversarially, say, as part of a malicious update in an insider attack!)
>>
>> Of course, the problem with this solution is that we're using HIBE.
>> Worse, with unbounded depth because each new ciphertext sent to a node
>> results in going one depth further into the hierarchy. AFAIK all HIBE
>> constructions have pretty horrible (read exponential) efficiency as a
>> function of their depth. (And I won't mention the state of
>> standardization and open implementations for HIBE.)
>>
>> Now there could be a totally different approach that entirly avoids
>> HIBE. But even with this approach there's at least some glimer of hope
>> to improve on it because, if we don't wory about insider attacks we can
>> assume C is honestly generated which means hash(C) really has a ton of
>> entropy. So we dont seem to need the full expresivity HIBE identities
>> allow us. Rather we only need HIBE for "random" identities. Still, that
>> seems like a pretty slim hope for major efficiency improvement. It also
>> doesn't do anything to address the lack of implementations and standards.
>>
>> - Joël
>>
>> On 17/10/2019 16:37, Karthik Bhargavan wrote:
>>> Thanks Yevgeniy,
>>>
>>> This helps a lot.
>>>
>>> To further my understanding, another question:
>>>
>>>>  Intuitively, the sender will not only encrypt the message, but also a
>>>> random Delta value. It will change public key using homomorthism by
>>>> multiplying with g^Delta (in specific DH based scheme), while the
>>>> recipient will decrypt Delta (using old secret key), and add it to the
>>>> old secret key to get there new one. So now corrupting (old sk plus
>>>> Delta) will not help decrypting the ciphertext just decepted, emailing
>>>> forward secrecy. 
>>>
>>> I see that in the DH-based scheme, this Delta needs to be private,
>>> otherwise the adversary can compute sk once it knows sk+Delta.
>>> But, in general, is it possible to conceive of a UPKE scheme where the
>>> recipient effectively “hashes forward” its symmetric key,
>>> where this one way hash-forward function does not have to rely on an
>>> externally chosen secret value?
>>>
>>> Best,
>>> Karthik
>>>
>>>> This is the high level, hope it makes sense.
>>>> Thanks for your question,
>>>> Yevgeniy
>>>>
>>>> On Thu, Oct 17, 2019, 1:43 AM Karthik Bhargavan
>>>> <[e-mail] <mailto:[e-mail]>
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>    Hi Joel,
>>>>
>>>>    This looks very interesting. It is new to me since I was not at
>>>>    the interim.
>>>>    After reading the paper and the slides, I am still a bit fuzzy
>>>>    about what the recipient of an update needs to do.
>>>>
>>>>    For example, for the running example in your slide deck, it would
>>>>    help if I could see:
>>>>    - what secret keys does each leaf need to keep
>>>>    - how do these secrets change when an update from some other node
>>>>    is received.
>>>>    Just working this out for one update is enough.
>>>>
>>>>    I know that this is made precise in the eprint, but it would be
>>>>    faster if you could help us understand it :)
>>>>
>>>>    Best,
>>>>    Karthik
>>>>
>>>>> On 16 Oct 2019, at 23:51, Joel Alwen <[e-mail]
>>>>> <mailto:[e-mail]>
>>>>    <mailto:[e-mail]>> wrote:
>>>>>
>>>>> <FS-TreeKEM.pdf>
>>>>
>>>>    _______________________________________________
>>>>    MLS mailing list
>>>>    [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>    https://www.ietf.org/mailman/listinfo/mls
>>>>
>>>
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mls
> 
> 
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>