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

[David Barrett]

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: 6821 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20210129/9dd9951c/attachment.txt>