What advantage does Signal protocol have over basic public key encryption?

[David Barrett]

Incidentally, for anyone following along, here's a great thread I had on
Twitter regarding this:

https://twitter.com/dbarrett/status/1353768706141163520

My current summary of Signal's primary design goal is:

> Perhaps I'm looking at it the wrong way. Signal's primary design goal
seems to be to *enable* truly effective self-destructing chats (which means
enabling them to self-destruct at every layer), to limit the damage from
device compromise. That is their primary differentiated feature.

Given that the device is the weak link (ie, the most likely place that a
key would be compromised), and without self-destructing chats the device
has a complete record of all past messages, then there's really no point to
all the double-ratchet stuff (which exists purely to limit the damage of
any individual key being compromised) because in the process of
compromising any key, you also compromise *all messages* (obviating your
need for the key in the first place).

Does that seem a fair summary?

-david

On Mon, Jan 25, 2021 at 10:31 AM David Barrett <dbarrett at expensify.com>
wrote:

> On Sun, Jan 24, 2021 at 9:15 PM <jamesd at echeque.com> wrote:
>
>> > 1) This is perhaps an obvious question (I've got to start somewhere,
>> after
>> > all), but what is the downside of the simplest possible solution, which
>> I
>> > think would be for all participants to publish a public key to some
>> common
>> > key server, and then for each participant in the chat to simply
>> re-encrypt
>> > the message N-1 times -- once for each participant in the chat (minus
>> > themselves) using each recipient's public key?
>>
>> This does not work in itself, because what assurance do you have that
>> you are seeing the same public key as everyone else?
>>
>
> Yes, this does assume a central keyserver -- and I agree, it's possible
> that it lies to you, establishing a connection with someone other than who
> you requested (or even a man-in-the-middle).  I don't know how to really
> solve that for real without some out-of-band confirmation that the
> public key returned by the keyserver (whether centralized or distributed)
> matches the public key of the person you want to talk to.
>
> > 2) I would think the most significant problem with this ultra-simple
>> design
>> > is just performance: asymmetric encryption is just too expensive in
>> > practice to use for every single message,
>>
>> Nah, because its cost in human generated messages is absolutely
>> insignificant, particularly if you are using ed25519 or, better,
>> ristretto25519
>>
>
> I think you are saying that performance isn't a real world concern, but
> forward secrecy is?  If so, that makes sense.
>
> -david
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3717 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20210125/7e4d3e4d/attachment.txt>