Bitmessage Anonymous Messaging is Porting to Android

[711 Spooky Mart]

Bitmessage (https://bitmessage.org) is a encrypted communications
protocol that functions like email, usenet, and mailing lists. It hides
non-content metadata and protects against eavesdroppers discovering who
is talking to whom.

Imagine usenet that is untraceable, uncensorable, and anonymous without
requiring complicated and unreliable remailers. It allows connections to
be routed over Tor for extra security, yet Tor is not required.

See below.

=================================
Copy Pasta from [chan] bitmessage
=================================

We're working on an android version, in fact we do have working
prototypes which aren't publicly available. One of the problems is that
they are slowly dropping python2 support, so the python3 port has do be
done first. We also have a working python3 version, the problem here is
the code quality, so it's slowly being integrated.

As you can see on github, a couple of PRs for kivy tests were merged
over the last weeks and there is a new "kivy test" build in the CI/CD
pipeline. These are end-to-end tests for the UI used on android.

Everything is taking longer than anticipated but I want it to be done
properly.

Peter Surda
Bitmessage core developer

> Hello everyone. I have wishes for the Bitmessage core developer Mr.
> Peter Surda. I myself have been a Bitmessage user since about 2014.
> I stopped at version 0.6.1 as it works fine and performs the tasks
> that are required. What's really missing is the equally robust
> stable version of Bitmessage for Android.
>
> For me personally, the main advantage of BM is not encryption of
> correspondence, but the absence of servers where censors could come
> and block the forwarding of messages. This is the most important
> quality of the program. To know that under any circumstances your
> message will be delivered to the person to whom you sent it.
> It is for this reason that I would like BM for Android. Both Windows
> and Android are leaky systems themselves. And the correspondence,
> even encrypted during BM transmission, can be intercepted from the
> device itself through backdoors in the system or special programs.
> Therefore, in my personal conviction, the user must protect his text
> on an offline system using PGP encryption, transfer it on a USB
> flash drive to an online computer and send it to the addressee using
> BM. Well, this is so, thoughts out loud :) I have no such cases that
> would require such a high level of protection of correspondence. But
> on the other hand, in my country I constantly encounter blocking of
> various websites and messengers. Messages sent via BM cannot be
> blocked. And for the convenience of correspondence, I would like to
> see a version for Android.
>
> ------------------------------------------------------
> 0.6.3.2 has some technical problems, it may be better to use 0.6.1
> if you want a stable release.
>
> Peter Surda
> Bitmessage core developer
>
> > I guess I should've asked, why not link windows and mac users to the
> > newest release, 0.6.3.x?
> >
> > ------------------------------------------------------
> > The wiki does not need to be updated. And BM doesn't need to be
> > updated. 0.6.1 works great!
> >
> > ------------------------------------------------------
> > hey should the wiki be updated? I noticed that it still points the
> > suspecting new user to download the version 0.6.1

--
███████████████████████████████████
█░░░░░░░░░░░█░░░░░░░░███░░░░░░░░███
█░░███████░░█░░████░░███░░████░░███ [chan] 711
█░░░░░░░██░░█░░░░██░░███░░░░██░░███ spooky mart
██████░░██░░███░░██░░█████░░██░░███ always open
██████░░██░░███░░██░░█████░░██░░███ stay spooky
██████░░██░░█░░░░██░░░░█░░░░██░░░░█ https://bitmessage.org
██████░░██░░█░░██████░░█░░██████░░█
██████░░░░░░█░░░░░░░░░░█░░░░░░░░░░█
███████████████████████████████████

[Stefan Claas]

On Monday, September 27, 2021 at 6:45:46 PM UTC+2, 711 Spooky Mart wrote:
> Bitmessage (https://bitmessage.org) is a encrypted communications
> protocol that functions like email, usenet, and mailing lists. It hides
> non-content metadata and protects against eavesdroppers discovering who
> is talking to whom.
>
> Imagine usenet that is untraceable, uncensorable, and anonymous without
> requiring complicated and unreliable remailers. It allows connections to
> be routed over Tor for extra security, yet Tor is not required.

Problem with Bitmessage ist IMHO that you can't create messages
offline and then inject them into your BM client, so that third parties
do not know what the destination is, i.e. a personal BM address or a
public chan.

Regards
Stefan

[711 Spooky Mart]

On 9/27/21 1:27 PM, Stefan Claas wrote:

> Problem with Bitmessage ist IMHO that you can't create messages
> offline and then inject them into your BM client, so that third parties
> do not know what the destination is, i.e. a personal BM address or a
> public chan.

One can use the email reader script to compose messages using a mail
client (like Thunderbird) with a POP account that connects to the local
Bitmessage daemon.

Also one can script to the Bitmessage API and inject payloads that way.
I've been using the API for this.

I tried to tell the Bitmessage project that they need to use mix routing
with envelope encryption (like mixmaster) to inject payloads before they
enter the flood data stream, but they think Dandelion is sufficient (it
isn't sufficient).

If you are sending a message to a private address or a secret chan an
eavesdropper cannot distinguish it. But if you send a message to a
public chan that the eavesdropper knows, then theoretically they could
distinguish it. An option for chained envelope encryption would make the
protocol bulletproof, especially if using long chains of forwarding
peers and random hop delays. But then there might be reliability issues
with many peers going offline without warning.

[Stefan Claas]

On Wednesday, September 29, 2021 at 3:44:35 PM UTC+2, 711 Spooky Mart wrote:
> On 9/27/21 1:27 PM, Stefan Claas wrote:
>
> > Problem with Bitmessage ist IMHO that you can't create messages
> > offline and then inject them into your BM client, so that third parties
> > do not know what the destination is, i.e. a personal BM address or a
> > public chan.
> One can use the email reader script to compose messages using a mail
> client (like Thunderbird) with a POP account that connects to the local
> Bitmessage daemon.
>
> Also one can script to the Bitmessage API and inject payloads that way.
> I've been using the API for this.

I am aware of these two options, but I do not see how I can create with
them on an offline computer the encrypted payload, so when injecting
into the popular (and reference implementation) of PyBitmessage that
third parties do not see what the destination address is.

I have not tried out yet, but maybe one can install PyBitmessage on an
offline usage device, create the message there and then use the
created messages.dat file and replace it temporarly with messages.dat
from the online client, so that then messages.dat gets processed,
once connected to the network. AFAIR messages.dat contains only
encrypted binary blobs.

> I tried to tell the Bitmessage project that they need to use mix routing
> with envelope encryption (like mixmaster) to inject payloads before they
> enter the flood data stream, but they think Dandelion is sufficient (it
> isn't sufficient).

Yes, it isn't and this was the reason why I implemented my mail2chan
Gateway, allowing users of classic Mixnetworks to post to chans.

> If you are sending a message to a private address or a secret chan an
> eavesdropper cannot distinguish it. But if you send a message to a
> public chan that the eavesdropper knows, then theoretically they could
> distinguish it. An option for chained envelope encryption would make the
> protocol bulletproof, especially if using long chains of forwarding
> peers and random hop delays. But then there might be reliability issues
> with many peers going offline without warning.

Well, my mail2chan Gateway is piping directly email messages, without
MTA logging, into a BM client, which runs 24/7 and is 24/7 connected
to the BM Network, so this should be no issue.

Regards
Stefan

[711 Spooky Mart]

On 9/29/21 12:21 PM, Stefan Claas wrote:
> On Wednesday, September 29, 2021 at 3:44:35 PM UTC+2, 711 Spooky Mart wrote:
>> On 9/27/21 1:27 PM, Stefan Claas wrote:
>>
>>> Problem with Bitmessage ist IMHO that you can't create messages
>>> offline and then inject them into your BM client, so that third parties
>>> do not know what the destination is, i.e. a personal BM address or a
>>> public chan.
>> One can use the email reader script to compose messages using a mail
>> client (like Thunderbird) with a POP account that connects to the local
>> Bitmessage daemon.
>>
>> Also one can script to the Bitmessage API and inject payloads that way.
>> I've been using the API for this.
>
> I am aware of these two options, but I do not see how I can create with
> them on an offline computer the encrypted payload, so when injecting
> into the popular (and reference implementation) of PyBitmessage that
> third parties do not see what the destination address is.
>
> I have not tried out yet, but maybe one can install PyBitmessage on an
> offline usage device, create the message there and then use the
> created messages.dat file and replace it temporarly with messages.dat
> from the online client, so that then messages.dat gets processed,
> once connected to the network. AFAIR messages.dat contains only
> encrypted binary blobs.

I think I understand you. It seems you want the local filesystem to have
no evidence of payload origin or addresses for an encrypted payload on
that file system.

That being the case, messages.dat stores address data in 'sent' table.
Instead of copying entire messages.dat file from one computer to
another, just dump the 'inventory' table and transfer that.

Bash is much simpler than doing it with python. You can even use
python's subprocess or popen to execute the bash commands to avoid
dinking around with python sqlite commands.

On the offline computer:

$ sqlite3 messages.dat '.dump inventory' > inventory.sql

On the online computer shut down PyBitmessage then:

$ sqlite3 messages.dat < inventory.sql

And restart PyBitmessage. It might work without shutting down the
daemon, then again it might not.

Also there is a unpublished function hidden in the API code to insert a
pre-encrypted blob into the inventory table.

-----------------------------------------------------------------------
api.py -- line 1246
-----------------------------------------------------------------------
https://github.com/Bitmessage/PyBitmessage/blob/72bcbdf4c9c7edac9c1d79ad1c4de9f2b9c0f158/src/api.py#L1247
-----------------------------------------------------------------------
@command('disseminatePreEncryptedMsg')
def HandleDisseminatePreEncryptedMsg(
self, encryptedPayload,
requiredAverageProofOfWorkNonceTrialsPerByte,
requiredPayloadLengthExtraBytes):
"""Handle a request to disseminate an encrypted message"""

# The device issuing this command to PyBitmessage supplies a msg
# object that has already been encrypted but which still needs
the POW
# to be done. PyBitmessage accepts this msg object and sends it out
# to the rest of the Bitmessage network as if it had generated
# the message itself. Please do not yet add this to the api doc.
-----------------------------------------------------------------------

[Stefan Claas]

Thank you very much, this is very helpful.

Regards
Stefan

[Chris M. Thomasson]

[...]

Reminded me of side channel attacks, and memory snooping. On Windows,
they have:

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa366877(v=vs.85)

However, instead of zeros, just blast the memory with random bytes... ;^)

[Chris M. Thomasson]

Instead of SecureZeroMemory, its SecureRandomizeMemory... ;^)

[711 Spooky Mart]

One bloke suggested feeding encrypted payloads from a locked-down FPGA
board doing the encryption, through a one-way serial port to the sending
machine. That would be a tough nut to crack.

- 711