Addressing the Risk of Dictionary Attacks on ONS

[venezuela01]

Addressing the Risk of Dictionary Attacks on ONS

According to List of data breaches and Biggest Data Breaches, there are over 10 billion compromised records from more than 360 data breaches up to 2023. This staggering number surpasses the world's human population.

These compromised records often consist of usernames, emails, phone numbers, addresses, IP addresses, chat histories, social accounts, and other sensitive data. They serve as virtually limitless resources for malicious agents, potentially enabling them to deanonymize individuals on most social networks, given a specific extent of metadata exposure.

Considering Session’s commitment to being a privacy-centric messenger application, it is imperative to fortify defenses against attacks that harness these cross-referenced, third-party breached datasets.

However, the present design of ONS, which maps human-readable usernames to Session IDs, is vulnerable to dictionary attack. A well-equipped adversary could extract numerous potential usernames from these datasets, download the Oxen blockchain, and then locally query each candidate username, successfully associate some usernames with their Session IDs. Not only could this expose registered ONS users to spam, but it could also match anonymous Session IDs with data from other breached datasets, revealing their personal information and social graphs, and potentially performing sophisticated social engineering attacks.

To mitigate the risk of dictionary attack, we suggest the following enhancements:

1. Adopting a Time-Expensive Hash Function

Currently, ONS employs the blake2b algorithm to hash a username into a name_hash, which serves as a key in the ONS mapping. The intent is to hinder straightforward reverse mapping from Session ID to name. But blake2b, being a fast algorithm, remains vulnerable to dictionary attacks. We recommend switching to a robust Password Hashing Algorithm like Argon2. Further analysis is necessary to finalize the algorithm and parameters, ensuring a fortified defense against potential attacks.

2.Implement ONS Redirection: Migrate Sensitive Data Off-Blockchain

The current ONS system transparently stores both the name hash and encrypted Session ID on the public blockchain. Given that anyone with the name can decrypt and access the Session ID, attackers with an expansive dictionary can easily compromise data.

Our solution is twofold:

• Establish a redirection mechanism: Store on the blockchain only a reference to a specific location in the Oxen swarm, which would then save the actual encrypted Session ID.

• Specifically, on the blockchain, records would look like:

  {
    blockchain::ons_name_hash = Hash(name),
    blockchain::encrypted_pointer = Encrypt(ons_pointer||nonce1, sk=Hash(name||constant1))
  }
  

  Here, the ons_pointer (a 256-bit binary) is computed by ons_pointer = HASH(name||nonce2).

  Simultaneously, on the swarm, records would appear as:

  {
    swarm::pointer = ons_pointer,
    swarm::ons_encrypted_value = Encrypt(session_id||nonce3, sk=Hash(name||constant2))
  }
  

By bridging with the ons_pointer, sensitive data is effectively isolated from the public blockchain. Only a handful of Oxen Service Node operators could access segments of encrypted Session IDs, thus mitigating dictionary attack risks.

3. Nonce Implementation Explanation

The integrated nonces, generated when first registering the ONS, guarantee unidirectional information flow. For instance, in the absence of a nonce3, a service node operator with extensive swarm ID coverage might brute force all combinations of known Session IDs and leaked usernames, potentially compromising user identity. By weaving in the nonce, we enhance protection against dictionary attacks, even from operators with expansive access to Session IDs.

4. Introduce an ONS Toggle Feature

To further shield users from unsolicited messages, deanonymizing, and to diminish the dictionary attack's efficacy, we advocate for an ONS toggle mechanism.

To deactivate an ONS, users do not need to update the blockchain. Instead, they would connect directly to the swarm. To modify a record, users would utilize the get_tx_proof from the Oxen wallet, signing the record update request to demonstrate their ownership of the ONS. The swarm, after validating the request through check_tx_proof, would update the record accordingly. An additional field is required to store the block_height as a timestamp, signing by get_tx_proof, to prevent replay attacks.

If the ONS value updates to Encrypt(null_id||nonce3, sk=Hash(name)), with null_id equating to 000…000, it signals the ONS's deactivation. Deactivating the ONS, especially when not needed, reduces potential spam and bolsters overall database security, discouraging attackers from initiating dictionary attacks.

5. Conclusion

By adopting these proposed measures, Session can significantly elevate its defenses against potential dictionary attacks. Moreover, the ONS Redirection feature empowers users to update their ONS mapping value without needing to engage with the blockchain, thereby conserving both funds and storage space.

[KeeJef]

I think i see ONS names in a different context than you might. Rather than viewing ONS as a privacy-preserving feature, I see it primarily as a convenience feature, especially for users who wish to advertise their Session IDs and aren't overly concerned about their Session ID being associated with their ONS name.

I wouldn't recommend the use of ONS for users seeking the highest degree of privacy. Adding an ONS invariably means adding more metadata to the network. Those most concerned about privacy will likely continue using raw Session IDs. However, there might be a better method to represent these raw Session IDs in a more human-friendly manner.

This perspective aligns with our development of ONS/LNS over the past few years. Initially, ONS utilized Argon2 #1252 , but we transitioned to blake2b since Argon hashing made adding someone by their ONS quite slow and computationally demanding on mobile devices.

If we transition to an EVM L2, I believe ONS registrations should be transparent. As you've mentioned, dictionary attacks can already uncover and resolve simple names quite easily. I'd like to move further in this direction, likening ONS more to ENS in the future.

[venezuela01]

Thanks for comments.

I think i see ONS names in a different context than you might. Rather than viewing ONS as a privacy-preserving feature, I see it primarily as a convenience feature, especially for users who wish to advertise their Session IDs and aren't overly concerned about their Session ID being associated with their ONS name.

That clarifies our main point of divergence. I had assumed that ONS aimed to provide convenience for the general user base while maintaining privacy. I didn't view it as something for public figures or internet influencers who want to connect with a large online audience. I think we should clearly document the privacy concerns in our ONS introduction; I might not be the only person who had a different interpretation of ONS than you.

If we transition to an EVM L2, I believe ONS registrations should be transparent. As you've mentioned, dictionary attacks can already uncover and resolve simple names quite easily. I'd like to move further in this direction, likening ONS more to ENS in the future.

If ONS isn't intended for privacy preservation, and if we're really moving to an EVM Layer 2 framework, should we forego ONS's development and instead extend or adopt ENS? Absent privacy features, ONS may offer no unique benefits compared to ENS, rendering additional development unwarranted.

[venezuela01]

It's important to note that many centralized messaging apps allow users to be found by their usernames while still mitigating large-scale dictionary attacks. This is because only registered users can perform username lookups, and centralized measures such as rate limiting are in place to prevent abuse. Users transitioning from centralized messaging apps to Session might falsely assume that their privacy remains protected when they register a human-readable username. They may not realize that the risk of dictionary attacks is even greater than in centralized systems. Therefore, it's crucial to educate our users about the privacy implications of registering a human-readable ONS.

[KeeJef]

If ONS isn't intended for privacy preservation, and if we're really moving to an EVM Layer 2 framework, should we forego ONS's development and instead extend or adopt ENS? Absent privacy features, ONS may offer no unique benefits compared to ENS, rendering additional development unwarranted.

Yes, however there are registered ONS names which would clash with registered ENS names already, and we need to preserve existing mappings, so its not possible to fully migrate. I think its likely that ONS would become a fork of ENS with its own namespace.

It's important to note that many centralized messaging apps allow users to be found by their usernames while still mitigating large-scale dictionary attacks. This is because only registered users can perform username lookups, and centralized measures such as rate limiting are in place to prevent abuse. Users transitioning from centralized messaging apps to Session might falsely assume that their privacy remains protected when they register a human-readable username. They may not realize that the risk of dictionary attacks is even greater than in centralized systems. Therefore, it's crucial to educate our users about the privacy implications of registering a human-readable ONS.

Yes this is certainly a concern, i definitely see some issues around spam to registered ONS names if we fully moved to this model.

[venezuela01]

Yes, however there are registered ONS names which would clash with registered ENS names already, and we need to preserve existing mappings, so its not possible to fully migrate. I think its likely that ONS would become a fork of ENS with its own namespace.

ONS name clashing with ENS name might be able to mitigated by a special namespace, like ons::name?

[venezuela01]

I have another approach that can enhance the privacy of the ONS using a ring token and a temporary account, making ONS users less vulnerable to dictionary attacks.

1. Assumption: The Session client needs enhanced account management. Instead of supporting a single account, it should be extended to support both a primary account and multiple temporary accounts.

2. ONS Registration: When a user, Alice, registers with ONS, she no longer binds her ONS name directly to her primary Session ID. Instead, Alice needs to register two ONS records. The first record maps her desired Session name to the ring token derived from her primary Session ID. The second record further binds her ring token to her temporary Session ID.

The concept of a ring token is introduced by distributed databases like Cassandra or ScyllaDB, where a primary key is hashed by a partitioner function to map it to a specific node. A ring token indicates a swarm space position in Session's terminology, while aligning with terminology used by the broader distributed database community.

The partitioner function is deterministic and one-way, meaning one can calculate a ring token from a user's primary account ID, but not vice versa.

When Bob wants to connect to Alice, he resolves Alice's ONS in two steps. The first step retrieves Alice's ring token by looking up her human-friendly username. The second step retrieves Alice’s temporary account ID using Alice’s ring token. Then, Bob constructs a message request, encrypts, and signs it using Alice's temporary account ID, and sends the encrypted message request to Alice's swarm. Bob does not know Alice's primary account ID but knows her swarm because Alice’s ring token was calculated from her primary account ID.

When Alice's swarm receives the message request, the storage server also looks up the ONS name database. The server does not need to know Alice’s human-readable username; it just needs to verify whether the secondary ID has been bound to the ring token, which can be validated using the ONS name database. If validation passes, the storage server stores the message request, waiting for Alice to poll it. When Alice polls the message request, she decrypts it using her temporary private key, decides whether she wants to reply to Bob, and potentially sends her primary account ID to Bob using this temporary account as a bridge.

With this protocol, unless Alice explicitly approves Bob's message request, Bob has no way to know Alice's primary account ID. Other attackers might still be able to obtain Alice's ring token and temporary account ID through a dictionary attack on a wide range of potential usernames and potentially spam Alice with flooding message requests. In this case, Alice can update her ONS record to map her ring token to a null ID, like 0x0. If the storage server receives any further ONS message requests for Alice, the server first looks up Alice’s ring token from the ONS database. If it realizes that Alice’s ring token points to a null ID, then the server will refuse to process any message requests, thus preventing Alice from being spammed.