7

I was trying to figure out a way to encrypt a small payload in a transaction memo to anonymize the memo id without having to store anything on the server (like a memo -> user mapping).

To achieve this I was planning to do a simple encryption/decryption:

const cryptr = new Cryptr(encryptionKey);

function getDepositToken(username, algo) {
  return cryptr.encrypt(username);
}

function getUserNameFromDepositToken(depositToken) {
   return cryptr.decrypt(username);
}

However, with usernames > 10 characters the smallest I could get it was 40 bytes using a wide range of encryption algorithms.

My end goal is to encrypt user id + nonce or timestamp so that I can completely anonymize deposits for a given user id without having to store a mapping for them all in a db.

Does anyone else have any tips to being able to fit slightly more data in it? I was hoping I could get to 15-20 characters.

5
  • 3
    does it have to be a memo? You can create data entry for an account, which can keep up to 64 bytes data and the key is sha256(value). Then put this key into memo to make sure you know what this data entry is for. stellar.org/developers/guides/concepts/…
    – umbrel
    Jan 23, 2018 at 22:25
  • That's possible, but it could get expensive. My end goal was to encrypt a user id + nonce or timestamp so that I can completely anonymize a deposit address without having to store each one in a DB.
    – Paul
    Jan 25, 2018 at 14:48
  • then another option I can see is only sending multiple transactions and concatenating all memos into 1 piece of data, but that's not very straightforward too
    – umbrel
    Jan 26, 2018 at 10:23
  • It looks like I can use AES-256, and as long as my input stays under 32 characters i can generate a 64-character hex hash.
    – Paul
    Jun 5, 2018 at 18:08
  • Related: stellar.stackexchange.com/q/670/683
    – Chenmunka
    Dec 18, 2019 at 18:02

4 Answers 4

3

It looks like you are doing a symmetric encryption/decryption. For the particular case you described, a crypto hash may be a better choice.

SHA256 returns exactly 32 bytes and features good collision-proof characteristics. So try to hash a username with SHA256 and store the result to memo.

Of course, it can't be "decrypted", however, the hash can be easily checked on the server side. If you need a lookup by the identifier, you can maintain one more column with hashed username in the "users" ("accounts", whatever) table.

2
  • I was trying to avoid having to have any lookup serverside and have it all contained in the memo.
    – Paul
    Jan 23, 2018 at 20:43
  • I got it, but hashing (or external ids) is the only option for long data. You need to store the info off-chain.
    – Orbit Lens
    Jan 23, 2018 at 20:51
1

If you want to use an account as database you could use manageData operations. If you want to identify transactions then the only option is the memo field or the attachments feature which is not stored on the blockchain.

0

I ended up turning this into https://github.com/stellarguard/secret-memo.

0

This is what I did to send messages between different accounts https://hmatejx.github.io/Interstellar-Whisper

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.