libsignal-protocol-java VS libsignal-protocol-c

Signal message keys seem to include an IV. [1] Message keys are generated by passing a chain key through a key derivation function. [2] So you can also expand a shared secret established through Diffie-Hellman.

Someone please correct me if I'm wrong.

[1] https://github.com/signalapp/libsignal-protocol-java/blob/ma...

[2] https://signal.org/docs/specifications/doubleratchet/Set0_1....

Parece que a lib de encriptação do WhatsApp é baseada na do Signal.

You might want to use the Signal protocol libraries https://github.com/signalapp/libsignal-protocol-java

Signal Protocol Java library

Whatsapp provides API at least for business. Moreover, in theory the use signal protocol and signal library that are open source and available. Moreover, there are many projects, browser, that can connect to whatsapp server as rambox or ferdi.

Signal protocol library for Java.

Signal wrote their own open source protocol, libsignal, to provide end to end encryption; or as they put it "a ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments." Source I'd wager good money a chunk of that space is for said library and dependencies PLUS the regular rigamarole for an Android app.

The whitepaper at [1] is more impressive than I expected it to be, not for what is built today (which on a quick read appears to be rather unexciting), but for the class of attacks recognised as unsolved, and identified as requiring future work.

Improvements identified include:

1) Encrypted messages should have a constant size (padded). Note that the Signal protocol used by Session currently uses variable length messages[2].

2) Encrypted messages should be sent as noise by clients through the onion network and back to themselves at random intervals frequent enough that messages to/from other parties are statistically indistinguishable to Eve from the noise generated.

3) Intermediate nodes in the onion network should hold and delay encrypted messages so they are adequately mixed before being sent forward. This makes it statistically difficult for Eve to match up a message entering a node and a message leaving a node. Ideally messages would be mixed across enough nodes of the onion network that

4) Proof of work should be replaced with a better technique for preventing degradation of service or spam attacks. The paper quite rightly identifies that proof of work would favour Eve who has setup a data center filled with custom ASICs solving proof of work problems, rather than favouring Alice or Bob with an energy efficient mobile phone SoC. CAPTCHAs are identified as a possible future solution to this class of attacks.

I doubt those improvements would have much application outside of labs and experiments though. Unless a significant part of the global economy surprisingly becomes dependent on a traffic analysis resistant anonymising protocol, it is too easy to just block such protocols similar to what China does with its Great Firewall.

[1] https://arxiv.org/pdf/2002.04609.pdf

[2] https://github.com/signalapp/libsignal-protocol-c/blob/maste...

Signal protocol library for C/C++.