Introducing Encrypted Messaging via TON Wallet: A Comparative Study and Technical Specification

The Open Network (TON) blockchain has recently introduced an innovative feature that significantly enhances user privacy and security: encrypted messaging within transaction comments. This development represents a notable advancement in blockchain technology, providing users with the ability to send encrypted messages alongside Toncoin, Jettons, or NFT transactions. This paper outlines the comparative advantages of this feature against traditional blockchain messaging capabilities and delves into the technical specifications that underpin this functionality.

Comparative Analysis

Feature TON Blockchain Traditional Blockchain Services
Message Encryption End-to-end encryption Typically unencrypted
User Privacy Only sender and recipient can view messages Publicly visible comments
Resilience Operates even during server failures Dependent on centralized servers
Network Fee Approximately 0.006 TON Variable; often higher without encryption
Use Cases Everyday communication and transactions Primarily transactional notes
Implementation Support Web, desktop wallets, MyTonWallet Limited to specific platforms
Accessibility Future updates for mobile wallets Often requires third-party services
Restrictions Recipient must have at least one transaction No specific requirements

Technical Specification for Developers

The encrypted messaging feature operates via a distinct protocol that employs end-to-end encryption to ensure that only the sender and recipient can decipher the content of the messages. The specification involves the following components and processes:

  • Key Management: Utilizes Ed25519 public and private keys for encryption and decryption.
  • Message Encryption: The encryption process involves calculating a shared secret, generating a message key through HMAC-SHA512, and encrypting the message using AES-256 in CBC mode.
  • Message Format: Encrypted messages are identified by the operation code 0x2167da4b and include the sender’s and receiver’s public keys, the message key, and the encrypted data.
  • Storage Structure: The encrypted comment is segmented and stored in a chain of cells, adhering to specific length and format constraints to ensure integrity and confidentiality.

Encryption Process Overview:

  1. Shared Secret Calculation: Derived using the sender’s private key (priv_1) and the receiver’s public key (pub_2).
  2. Message Key Generation: The first 16 bytes of HMAC-SHA512, utilizing a salt derived from the sender’s wallet address and the encrypted data.
  3. Data Encryption: Performed with AES-256 CBC, using the derived key and initialization vector from the shared secret computation.

Encrypted Comment Structure:

  • Public Key Xor: A 32-byte field derived from the XOR of pub_1 and pub_2, facilitating decryption without external key lookup.
  • Message Key: A 16-byte identifier for the encrypted data.
  • Encrypted Data: The message content, encrypted and stored across multiple cells with a specific segmentation logic to accommodate the protocol’s constraints.

Conclusion

TON’s encrypted messaging feature significantly elevates the standards of privacy, security, and resilience for blockchain communications. By incorporating advanced cryptographic techniques within a user-friendly framework, TON provides a robust platform for secure and private messaging integrated seamlessly with blockchain transactions. This feature not only enhances the utility of the TON blockchain but also sets a precedent for future developments in blockchain privacy and communication protocols.

The introduction of encrypted messaging within TON transactions presents a significant advancement in blockchain technology, enhancing privacy and security for users. This feature, as detailed in the article, leverages the TON blockchain’s infrastructure to allow users to send encrypted messages along with Toncoin, Jettons, or NFT transactions. Here are several professional insights and questions regarding this implementation:

Professional Insights:

  1. End-to-End Encryption: The use of end-to-end encryption for transactional messages significantly enhances the privacy of communication between parties. It ensures that only the sender and recipient can decrypt and read the message, protecting against potential eavesdropping or data breaches.

  2. Decentralized Messaging: Integrating messaging functionality directly into the blockchain infrastructure leverages the decentralized nature of blockchain, making the communication resilient to centralized server failures. This approach aligns with blockchain’s ethos of decentralization and redundancy.

  3. Cost-Effectiveness: The stated network fee for delivering messages (~0.006 TON) demonstrates the potential for blockchain-based messaging systems to offer cost-effective alternatives to traditional messaging platforms, especially for microtransactions or when sending value alongside messages.

  4. Technical Implementation: The detailed encryption algorithm, including the use of shared secrets, HMAC-SHA512 for key derivation, and AES-256 CBC for encryption, illustrates a robust approach to secure messaging. This methodology follows well-established cryptographic practices.

Professional Questions:

  1. Interoperability with Exchanges and Payment Services: The advisory against sending encrypted comments when depositing on exchanges or payment services raises questions about interoperability and user experience. How will the system ensure users are aware of and adhere to this guideline, and are there mechanisms in place to prevent accidental encrypted messages to these services?

  2. Public Key Discovery: The necessity for the recipient’s public key (pub_2) for encryption suggests a requirement for public key discovery mechanisms. How does the TON ecosystem facilitate the discovery and verification of public keys, especially considering privacy concerns and the potential for key spoofing?

  3. Message Length Limitation: The limitation on message length (len(msg) ≤ 960) and the technical constraints on the format (k ≤ 16, max string length is 1024) might restrict the utility of this feature for more extensive communication needs. What were the considerations behind these specific limitations, and are there plans to extend these capabilities in the future?

  4. User Experience for Non-Technical Users: While the technical description is thorough, it implies a level of complexity in utilizing this feature. What measures are being taken to ensure that non-technical users can easily access and use encrypted messaging without needing to understand the underlying cryptographic operations?

  5. Security Considerations: Given the critical importance of security in encrypted communications, what external audits or security assessments have been conducted on this feature to ensure its resilience against cryptographic attacks and vulnerabilities?

  6. Future Developments: The article hints at potential future integrations and enhancements. Are there specific plans to expand the messaging feature beyond transactional messages, such as integrating standalone messaging capabilities within the TON wallet ecosystem?

The integration of encrypted messaging within TON transactions represents an innovative use of blockchain technology, offering enhanced privacy and resilience for user communications. Addressing the questions raised above could further clarify the implementation details and operational considerations, contributing to the broader adoption and utility of this feature within the TON ecosystem.

Hello
Please say me
Can I use ton wallet private crypto key for encrypt at my react app?