gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unreliable Delivery, Ratcheting, and Secret Reuse?


From: Cy
Subject: Re: Unreliable Delivery, Ratcheting, and Secret Reuse?
Date: Fri, 10 Jul 2020 21:58:15 +0000

It's got to be simpler than I'm imagining it. Both sides could have independent 
secrets,
like MS1 = hash(S1, my public key), and YS1 = hash(S1, your public key), then 
we discard
S1. So if I just send messages with MS1, MS2, MS3, and MS4, and advance to MS5, 
if you
get any of those, you can try MS1, MS2, MS3, and MS4 in sequence, and once you 
hit a
match, like MS3, you can advance to MS4, discarding MS1-3. While still 
remaining at YS1.
And if the message with MS2 then arrives, it doesn't matter because the message 
in MS3
overrides it. So each message must override the previous one, including all the 
same info
as if previous messages never arrived at all.

But each of these secrets corresponds to a KSK, so you would end up doing an 
uncountable
number of KSK searches to get all the messages I send, whereas if I only 
ratcheted when I
got a message from you, you'd only have to search for MS1 and MS2, regardless 
of how many
messages I send in a row.

I guess there could be an... IHAVE message or something so you'd say YS1(IHAVE 
MS3) and I
could retransmit the other three messages under MS5, MS6 and MS7 (since I 
already
discarded MS1-4 myself. But I don't think retransmission is necessary, when 
each message
is just a CHK to the current complete conversation state, with past
messages removed to some degree.

Seems like ratcheting could be ignored altogether if the user hits a switch 
saying "Log my
private messages." PFS doesn't matter if you kept a copy of all the messages on 
your disk
when they get you, and if they never get you, then they can't break the 
encryption
even once. But it's stupid to assume that everyone's security model requires
forgetting everything your friends have shared with you over the years and 
never being
able to refer back to it. I know people whose reason for refusing to use Tox or
Retroshare is because they value having chat logs. And high latency 
communication is by
nature less ephemeral than real time chat, so not logging has questionable 
benefit to all
but the most at-risk. 

But on the other hand people have been incarcerated for the crime of keeping 
their own
logs, so maybe the ones who want to are making a mistake? It's hard to draw
the line between forward secrecy and remembering the past.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]