NOTICE: EVERY PERSON WHO WANTS TO COLLABORATE ON THE PROJECT IS WELCOME, WE NEED SOMEONE WHO IS AN EXPERT IN UI TO FIX A SMALL KEYBOARD BUG *** TO COLLABORATE, WRITE AN ISSUE ***

ThreadScoopOnionChat

This is a fork privacy focussed extra features from SESSION " https://github.com/session-foundation/session-android ", .

How Did ThreadScoopOnionChat Come About?

I have always been a fan of privacy and security in communications, and I am constantly researching potential security breaches in messaging applications. ThreadScoopOnionChat emerged after the analysis of this blog "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/", in which several aspects are described as to why using Session is not recommended, and I wondered how it is possible that a foundation focused on privacy—with the grants and support it receives—has not been able to improve this protocol. I still do not understand the answer, since my resources are much smaller than those of a foundation compared to that of a person who is simply a fan of privacy and security. In this blog, certain problems were described:

1> "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#insufficient-entropy-ed25519" 2> "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#in-band-negotiation" 3> "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#public-keys-aes-gcm"

Solutions Provided in This Version

Regarding reference 1> "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#insufficient-entropy-ed25519"

This flaw is fixed by using 256-bit keys instead of 128-bit keys.

Corrected files:

KeyPairUtilities.kt

MnemonicCodec.kt

KeyPairUtilities.kt

The length of the generated seed is increased to 32 bytes: val seed = sodium.randomBytesBuf(32) The 16-byte zero padding is removed and the seed is passed directly to cryptoSignSeedKeypair(seed)

MnemonicCodec.kt

·In the decode method, it is enforced that the mnemonic phrase has exactly 25 words: if (words.size != 25) throw DecodingError.InputTooShort

With these adjustments, the issue of insufficient entropy (now 256 bits) is corrected and recovery with 25 words for the Ed25519 key is implemented.

Regarding reference 2> "https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#in-band-negotiation"

To solve this issue, "ExtraSecurity" is implemented, an activity accessible from the settings.

Important Details:

The addition of this extra layer with out-of-band symmetric encryption can solve the problem. By doing so, the message is protected even before entering the session protocol, so that an attacker cannot inject or modify the included Ed25519 key, since only the sender and the receiver know the key for that first layer of encryption. In other words, by first applying encryption with a pre-shared secret key, it prevents an adversary from altering the content or substituting the public key without breaking that protection. This effectively links the Ed25519 signature to the original message, turning the signature from a mere integrity check (similar to a CRC32) into a true guarantee of authenticity.

However, it is essential to ensure that:

The shared key is exchanged and stored securely out-of-band, for example, exchanged personally, or through another channel that is not Session.

Preliminary Symmetric Encryption:

The message is encrypted using a shared key (pre-shared between sender and receiver) before the session protocol encryption is applied. This ensures that the content, including the Ed25519 key, is protected against tampering.

Protection of the Public Key:

By incorporating the additional encryption layer, the Ed25519 public key is no longer transmitted in clear text. This mitigates the vulnerability where an attacker could arbitrarily substitute that key, effectively reducing the signature to a verification similar to a CRC32.

Secure Key Exchange:

The symmetric key is exchanged and stored securely out-of-band (for example, through export in Settings/Extrasecurity), ensuring that only the sender and receiver have access to it.

Security Benefit:

With this change, the authenticity of the message is strengthened, as the Ed25519 signature is securely linked to the original message, eliminating the possibility of injection or malicious modification of the public key.

This approach reinforces the overall security of the protocol, preserving the integrity and authenticity of the message throughout the encryption and transmission process.

To implement this function, several files were modified:

·Storage.kt

·SQLCipherOpenHelper.kt

·Messagesender.kt

·Messagereceiver.kt

·Threadatabase.java

·ConversationsV2.kt

·SettingsActivity

·Extrasecurityactivity.kt

·Storageprotocol.kt

·ConversationMenuHelper.kt

·MessagingModuleConfiguration.kt

·KeyPairUtilities

·Contact.kt

·SignalServiceProto

·MessageWrapper.kt

·ReceivedMessageHandler.kt:

STEPS TO CONFIGURE AND USE EXTRASECURITY (THREADSOOP ENCRYPTION)

1. Access the Settings:

   • Open the application and navigate to "Settings".
   • Within "Settings", select the "Extrasecurity" option.

2. Key Generation:

   • In the "Extrasecurity" section, generate the keys that will be used for encryption.
   • Available options: a. "Generate Random" to create a random key. b. "Import from QR" to import an existing key via QR code.
   • It is recommended to have a unique key for each chat.

3. Key Export:

   • To export a key, long-press the desired key in the list.
   • Select the "Export as QR" option to generate a QR code for the key.

4. Key Import:

   • Use the "Import key from QR" option to scan the QR code and add the key.

5. Importance of Alias:

   • It is essential that both the sender and the receiver use the same key and the same alias.
   • Example: If a key is exported with the alias "Test", when importing the key, it must be assigned exactly "Test".

6. Activation of Encryption in the Conversation:

   • Start a normal chat with the desired contact.
   • In the conversation's drop-down menu, select "ExtraSecurity".
   • Choose the encryption key that has the same alias on both devices.
   • Activate the extra encryption and save the configuration.

7. Result:

   • The conversations will be protected by ThreadScoop encryption, ensuring that only the participants with the correct key and alias can decrypt the messages

If you want, donate or leave a compliment. My USDT Wallet: TNufycDSRfWbQs79e2Fjyy2DKrNiySN95m