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

[Stefan Claas]

On Sun, Jan 31, 2021 at 4:29 AM David Barrett <dbarrett at expensify.com> wrote:
>
> Hey all, I took the liberty of writing up this proposal and everything I've learned in more detail here:
>
> https://gist.github.com/quinthar/44e1c4f63f84556a9822ebf274dc510a

Hi all,

I just skimmed through the whole thread and have one question, If you
don't mind.

I asssume when talking about design proposals, for secure comms, that
always Android
and iOS devices are used. Are people aware when using such devices,
about zero-click
exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my
smartphone exactly
for that reason and switched to a dumb phone.

What I miss in all those discussion is, when it comes to secure mobile comms,
the usage and promotion of mobile devices running on OpenSource OS devices,
which developers and users have more control of. Then IMHO it would be good
to discuss such protocolls etc.

Best regards
Stefan
>
> I'd really welcome any feedback or (constructive) criticism on it.  Thanks!
>
> -david
>
> On Fri, Jan 29, 2021 at 11:42 AM David Barrett <dbarrett at expensify.com> wrote:
>>
>> Wow, these are (mostly) great responses, and exactly what I was looking for.  Thank you!  To call out a couple responses:
>>
>>> 6, the ratchet protocol produces a hash of previous messages that provides for detection of dropped data, among many other things.  pgp does not do this.
>>
>>
>> It feels like there are easier ways to detect dropped/tampered message, such as with an a simple accumulated hash of all past messages (or even a CBC mode).  We do this with https://bedrockdb.com/blockchain.html and it works great.  However, I get your point that the double ratchet provides other benefits beyond just forward secrecy.
>>
>>
>>> Decryption of destroyed messages is a big thing that signal deters. Journalists can get seriously physically injured when that happens.
>>
>>
>> Yes, I agree, it seems that forward secrecy is both 1) very valuable, 2) very hard to do, and 3) Signal's primary design goal.
>>
>>
>>> Re Signal and Javascript, Signal offers its code in a signed binary, and offers the source to that binary for anybody to build and check.
>>
>>
>> Signal offers source, but given that it's distributing binaries via app stores, there's really no way to guarantee that the binary matches that source code.  Open source is great (Expensify.cash is as well), but still requires that you trust the party giving you the binaries.
>>
>>
>>> They [Signal] have an automated system that gives their donated money to people who contribute improvements.
>>
>>
>> Wait really?  I'm not really finding that mentioned anywhere; can you link me to this?  The FAQ doesn't really mention it, but it seems like this would be front and center: https://support.signal.org/hc/en-us/articles/360007319831-How-can-I-contribute-to-Signal-
>>
>>
>>> Arguably the simplest method is to do what you describe [encrypting every message with the recipient's public key]. However, public-key crypto produces a shared-number of ~256-4096 bits. If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret. This is why (nearly all) public-key crypto systems are paired with some symmetric cipher.
>>
>>
>> I'd really love to learn more about this, as I think I almost understand it, but not quite.  Can you elaborate on what you mean by "If the message is longer than this, these shared-secret bits must be "stretched" without revealing the secret."
>>
>> I get that any encryption (symmetric or otherwise) works on blocks, so to encrypt anything larger than one block requires splitting the input up into many blocks.  And I get that there are concerns with accidentally revealing information by encrypting the same exact block back to back (ie, it reveals "the same block appeared twice", without revealing the actual block content itself).  (More on all that here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Confidentiality_only_modes)
>>
>> But I'm not quite understanding why you suggest that you couldn't just use a CBC strategy (where each block is derived from the block that preceded it) in conjunction with public key encryption to just encrypt every block with the recipient's public key, eliminating the need for the shared symmetric encryption key.
>>
>> Now, understand the performance advantages of symmetric over asymmetric encryption, and certainly the convenience (and bandwidth) advantages of having multiple parties all use the same key (ie, to avoid re-encrypting the same message separately for each recipient).  But I don't see any actual security advantage to introducing the symmetric key (and arguably a disadvantage given the increased complexity it adds).
>>
>>
>> Thanks for all these answers, I really appreciate them!
>>
>> -david
>>
>>
>>
>> On Tue, Jan 26, 2021 at 12:17 AM <jamesd at echeque.com> wrote:
>>>
>>> On 2021-01-26 04:31, David Barrett wrote:
>>> > 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.
>>>
>>> Jitsi's solution works.
>>>
>>> It is the much studied reliable broadcast problem, which is a hard but
>>> much studied problem, with a bunch of hard to understand solutions,
>>> which nonetheless work.
>>>
>>> > I think you are saying that performance isn't a real world concern, but
>>> > forward secrecy is?  If so, that makes sense.
>>>
>>> Yes.
>>>
>>> Ristretto25519 shared secret construction (using asymmetric cryptography
>>> to construct a shared secret that is then used in symmetric
>>> cryptography) takes 2.5 microseconds on my computer running unoptimized
>>> debug code.  For forward secrecy, you need to construct two secrets, one
>>> from the transient key and one from some mingling of the permanent key
>>> with the transient key, which takes 5 microseconds.
>>>
>>> And you then use the authenticated shared secret for the rest of the
>>> session.
>>>