Hi everyone,
I just published a JS/TypeScript library to generate secret Stellar memos, and wrote an accompanying article surrounding the motivations and design.
Feedback, comments, and criticisms welcome. Already there's been some ideas about how to squeeze even more data into the memo by using the sequence number as an initialization vector.
Well done.
Using the sequence number as the initialization vector is indeed a good idea. If your algorithm require the initialization vector to be a random number (which's likely else it would be called a nonce), then you can use a hash of the sequence number.
Important:
Actually there might be an issue with using the same IV with several different secret keys (i.e.: several people encrypting a memo at the same sequence number). A safer solution would be: hash(sequenceNumber+publicKey)
Interesting article, thanks for sharing.
One question without looking into your code: what do you do if you would need padding for 1 byte only (so the size of the random padding does not fit anymore)?
Cajga I'm actually wasting some bits because the maximum amount of padding I'd ever need is 22 characters, which would fit in 5 bits (can fit a number up to 32). You can't really any useful user information in the leftover space, but I may end up using it in the future for a version number so I can add enhancements without breaking it.
In the implementation I end up encoding the size into a character before encrypting it and then after decrypting turn it back into an integer.
MisterTicot Good idea. There is also randomness introduced by the padding needed to fill it out to 32 byte of hex, it's just applied as if it's part of the data instead of just in the generic encryption algorithm.
It is indeed just a nonce -- but I chose an implementation that uses 8 bytes of randomness so you did not have to maintain that nonce anywhere. Luckily Stellar has that baked in already though!
The only downside that I see to this approach is that you cannot construct a memo that is independent of a transaction. I would not be able to alter transaction details after generating the memo, such as the idea I had for the channel account manager that would replace the transaction source with a channel account (https://galactictalk.org/d/1474-project-idea-channel-manager-aka-the-chanchanman).
MisterTicot I encountered one major issue with this approach: it only works when the person who knows the secret is also the one building the transaction. In the core use case I outlined: different memo fields every time you deposit into an exchange, the exchange would not have the source account or the sequence number available, even if it was created via a federation response.
Ho ok, then we cannot use the sequence number as well. Well, in that case I can't imagine any simple way to gain space.
This thinking was interesting though, and could be useful in other cases.
Ho wait! We still have timebounds.
min/max date values could encode quite big numbers for free as they are the number of second since epoch ?
The federated server could provide this value aside from the memo.
I just found myself implementing something similar for a different use-case and remembered this thread.
With AES-CTR, each block has a different counter, starting at the initial 16-byte value defined by the IV.
For a specific encryption key, each value of the counter should only be used once, i.e. an overlap in the counter ranges between different encryption runs is BAAAAAD. For a memo, we should be OK, since the size of a memo is just one AES-256 block.
