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

[David Barrett]

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

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.
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 7670 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20210130/95917bd6/attachment.txt>