Re: [MLS] Re-randomized TreeKEM

Sorry: typo (symmetric key —> private key)

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 *private* 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 <karthikeyan.bhargavan@inria.fr <mailto:karthikeyan.bhargavan@inria.fr>> 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 <jalwen@wickr.com <mailto:jalwen@wickr.com>> wrote:
>> > 
>> > <FS-TreeKEM.pdf>
>> 
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org <mailto:MLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls