You are viewing a single comment's thread from:

RE: Understanding End-to-End Encryption with ECDH: A Deep Dive

in #devlast month

Thank you for the detailed insight on memo encryption and decryption.
The next challenge is protecting the system from spam. For instance, a random user could broadcast the same custom_json operation repeatedly across the network.

This is where the real use case emerges: how to detect, differentiate, and block spam while allowing legitimate requests to pass through.

Sort:  

I believe any user can broadcast multiple operations with custom JSON by using commands. The issue isn't on your end—it's related to the node RPC. However, I've tried several RPC, and they impose limits on successive operations

What I want to say is that it's not your problem. For example, I can broadcast many operations with custom JSON right now, not throwing anything into your system, just with commands. So, it's not an issue on your side.

I’ve implemented strict security measures: On steem users can submit up to 5 operations per block. However, in my opinion, this alone could still allow some level of spamming. To strengthen protection, I’ve added a second layer of security, only operations broadcasted through the official SteemPro frontend are accepted and processed. This ensures that no external source can spam the system.

Congratulations! This post has been upvoted through steemcurator08. We support quality posts, good comments anywhere, and any tags.




1000420827.png
Curated by @miftahulrizky

Also, you have another challenge : when the user generates new keys for their account, all previous messages disappear. I’m not sure if that’s a problem for you or not

Really? I think no. Encryption is made to the counter parties so if they use the valid key then it should decrypt at any stage.

I think you misunderstood me. What I mean is this: When a user generates new keys for their account, both the public and private keys are replaced. As a result, all previously encrypted messages become inaccessible. Even for the other party — who did not change their keys — decryption will fail because the other user's public key has been replaced. The new keys cannot decrypt the old messages; only the old keys remain valid for decrypting previously encrypted messages. The new keys are incompatible with those messages, effectively making them irretrievable.

Example:

User 1 and User 2 exchange encrypted messages . Later, when User 1 generates a new keys, both User 1's and User 2's past messages in that conversation can no longer be decrypted because they were tied to the old keys, which are now replaced.

Congratulations! This post has been upvoted through steemcurator08. We support quality posts, good comments anywhere, and any tags.




1000420827.png
Curated by @miftahulrizky

Right! there's also no solution for it! One should keep the previous memo too if changing password!