[messaging] App updates over Tor

Van Gegel torfone at ukr.net
Sun Jun 21 23:58:52 PDT 2020

>What do you think about updates over Tor?
Updates via Tor is acceptable: at least this excludes targeted updates for a specific user, which has already been practiced for compromise. It is better to host the update server in onion.

>On the site I see mentioning of PGPFone. Is code related?
PGPFone is an early development of Zimmerman, where the concept of ZRTP, the code for Windows and MAC only. First prototype of Torfone was based on this code but it is outdated and not compatible on protocol.

>Can you either give some script to setup environment for compilation, or give detailed doc.
Torfone's IKE protocol and interactions between modules are previously described here:
Links to buid instructions, prepared archives with source codes and executable files with GUI for Windows, Linux and Android, signed by my PGP, are here:
>Do you have license there (like in each file)? Or do you want it to be a public domain?
This is in public domain now.

You can write personally to me  about code details. The code style looks strange, but it was written not for OS but for bare metal. Right now I am debugging Torfone on two isolated platforms: Tor and transport on a single-board computer under Linux and cryptography + GUI on the Nucleo STM32F446RE board + TFT display. Code execution in Cortex RAM is denied. Exchanging data packets have fixed fields and unambiguous interpretation of data. Communication over UART  without any possibility of affecting the execution of the code in trusted module. There is also an idea to port Torfone together with Tor on STM32F776 board, but for this we need to carefully study the Tor code, limit unnecessary memory allocation (leaving only 8 circuits - this is enough) and make wrappers for libevent, sockets etc. for implementation on bare metal. This is a hard but interesting job.

21 June 2020, 17:31:56, by "Mikalai Birukou" <mb at 3nsoft.com>:

Most messengers provide only the illusion of security. They sacrifice basic rules for the convenience of ordinary users without caring for those who really need security.

Really safe messenger MUST:
- never updated remotely;
- does not integrate with other services (for example, does not use phone numbers or mail as an ID);
- has powerful ID protection in its protocol;
- provides plausible deniability of having contact in book.
What do you think about updates over Tor?
In particular: app developer provides update url that is same for everyone. Clients only do GET request on that url. And client can/should come via Tor to hide its ip/identity.
And updates are allowed when user clicks button, i.e. never without the confirmation. Downloaded bytes' hashes can be calculated and compared to known safe version's hash. Friends should provide assurance, hashes should be calculated and checked by program, showing only confirmations as info for user.
Anonymity of client leaves to attacker only in-discriminant bundestrojaner scenario.
Thoughts, concerns, UI suggestions?
I tried to implement these requirements in my Torfone: https://github.com/gegel/torfone

The onion address is generated locally and uses as ID.
Authentication is performed independently of Tor using own keys. The IDs of  caller and callee are protected with PFS (by adding the SPEKE protocol result to the hash of the signal's tDH). The session key is output using a simple DH: tDH result is used only for authentication. This makes it possible to receive calls from unauthenticated subscribers (with the corresponding notification). During a call any subscriber can add his or other contact to your address book, so you can explain the presence of a compromising contact in it. Open source makes it easy to check the protocol for leaks.
Wow. This sounds cool. But may I voice issue #2 again? Can you either give some script to setup environment for compilation, or give detailed doc. This whole concept of usability first of all touches us, devs :) , then we try helping users.
On the site I see mentioning of PGPFone. Is code related? Or, do you take conceptual inspiration?
Can you spell out architecture? It can be doodly doc file(s) for project, and cc-ed/ref-ed here. We'll appreciate that.
Do you have license there (like in each file)? Or do you want it to be a public domain? If later, you can say this explicitly, like djb did with nacl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20200622/17b90e53/attachment.html>

More information about the Messaging mailing list