Encryption Of Memos/Messages

Problem Statement: Memos/messages when incorporated by a layer 2 service will need to be encrypted to ensure only the Nano addresses involved in a particular block can read the messages. Finalize the best approach to encrypt arbitrary data using the existing private/public Nano keys on a Layer 2 system.

Potential Solution: Asymmetric key encryption of the arbitrary data using existing account private/public keys.

I want to open up a discussion on the above topic. I understand rudimentary basics of cryptography but would like someone to elaborate on a solution for the above problem statement.

Example flow:

  1. Alice sends Bob 10 Nanos and wants to send the message 'Hello World' to Bob for that particular block hash/transaction.

  2. Alice encrypts the message 'Hello World' using Bob's public key derived from Bob's public Nano address (Please suggest which algorithm to use for this).

  3. Alice signs the encrypted message (using her private key) in the similar fashion how a standard Nano transaction block is signed to authenticate the encrypted message is being published by Alice.

  4. Alice publishes the signed encrypted message to a layer 2 service. Layer 2 service verifies the signature and ensures it is Alice sending the message.

  5. Layer 2 service stores this data mapping it to the transaction block and broadcasts it to Bob.

  6. Bob receives the message and decrypts the message with Bobs private key (remember that the message was encrypted using Bobs public key.)

  7. Bob can read the plain text 'Hello World' and stores it on device cache. A reply message can be sent by Bob using the same flow.

Potential issues: If message data is too long maybe use hybrid system of asymmetric and symmetric key encryption instead.

Kindly suggest which algorithms can be used for encryption as well as any short comings to this technique.

1 Like

I strongly agree that Nano needs a message feature for it to be useful as a currency. This way it would be similar to normal (fiat) banking transactions. It has been suggested in the past to be added to nano itself, but this idea was rejected because it would increase the ledger size and have personal messages openly available.

So I like your idea to solve this using layer 2, however as I currently understand it nano doesn't have a layer 2. But something akin to it would be a good way to go about it. There already is a separate centralised cryptographic memo solution in nanomemo.cc, but it's currently down. I would suggest convincing the developers of the Nano wallets to integrate this into their app.

BETTER PROTOCOL USING HYBRID SOLUTION:

  1. Alice sends Bob 10 Nanos and wants to send the message 'Hello World' to Bob for that particular block hash/transaction.

  2. Alice creates a shared secret key using combination of Bob's public key (derived from public Nano address) and Alice's private key (derived from Nano seed). This shared secret key can be generated using Diffie-Hellman key exchange algorithm shown below.

  1. Alice encrypts the message 'Hello World' using the shared secret key through symmetric key encryption algorithms like AES 256.

  2. Alice signs the encrypted message (using her private key) in the similar fashion how a standard Nano transaction block is signed to authenticate the encrypted message is being published by Alice.

  3. Alice publishes the signed encrypted message to a Layer 2 service. Layer 2 service verifies the signature and ensures it is Alice sending the message.

  4. Layer 2 service stores this data mapping it to the transaction block and broadcasts it to Bob.

  5. Bob receives the message and decrypts the message with the shared secret key (Remember that Bob has also generated the shared secret key using Bob's private key and Alice's public key combination).

  6. Bob can read the plain text 'Hello World' and stores it on device cache. A reply message can be sent by Bob using the same flow.

This solutions ensures end-to-end encryptions between the two parties and due to symmetric key encryption being using for the arbitrary data encryption, speed and big files encryption is not an issue. All above processes happen locally on the client side except for broadcasting and storing the encrypted arbitrary data using a Layer 2 service.

If you want a general messaging service, just use a general messaging service. If you want a single message associated with the transaction (i.e. a memo) then I'd suggest you read this thread. The memo would be part of a larger exchange of information between the two transactees, which should already be private.