1 Our simulation API

[Note added 1 March:] If your simulation crashes with an error like thread panicked at range start index 18446744073709551594 out of range for slice of length 10, then this is from sending a message that is marked as encrypted but whose data is too short. Versions of securelab.tar after 2023-03-01 3:45pm give a better error message in this case.

The code for forward_normal looks like:

void forward_normal(struct message *message) {
    send_message(message);
}

It just forwards the message without making changes.

You can modify this to change the messages in various ways, for example:

• change the contents of certain message

   void forward_change_to_B(struct message *message) {
       if (message->to == 'B') {
           strcpy(message->data, "This replaces the original message.");
           message->data_size = strlen("This replaces the original message.");
       }
       send_message(message);
   }

• change the recipient or sender of certain message:

   void forward_send_A_back_to_B(struct message *message) {
       if (message->to == 'B' && message->from == 'A') {
           message->to = 'A';
           message->from = 'B';
       }
       send_message(message);
   }

• add a brand new message before the first message:

   static int counter = 0;
   void forward_with_additional(struct message *message) {
       if (counter == 0) {
           send_message(new_message(
               'A', 'B',
               "This is an additional message."
               false, false
           ))
           counter += 1;
       }
       send_message(message);
   }

1.1 Manipulating and creating messages

The struct message is defined as follows:

struct message {
    char from;              // message sender
    char to;                // message recipient
    bool is_encrypted;      
    bool is_signed;         // if true, 'data' is signed using from's private key
    char data[1024];        
    size_t data_size;
    char signature[64];     // only used if is_signed is true
};

to indicates where the network will attempt to deliver the message when you can send_message().

Signed messages will have signature set to some meaningful data.

You can construct messages (including encrypting them) using the following utility function:

struct message *new_message(
    char from,
    char to,
    const char *data,   // NULL-terminated string
    bool is_encrypted,  // encrypt the message
    bool is_signed      // sign the message --- only supported if 'from' is 'M'
);

You can decrypt messages encrypted to M using:

void decrypt_message_for_M(
    const struct message *message,
    char *buffer,
    size_t buffer_size
);

which will copy the decrypted contents of the message into buffer (truncating the contents if the buffer_size is too small).

Encrypting a message will public-key encrypt it to to’s public key. new_message has a list of all the public keys to do this.

If you manipulate the data or data_size of an encrypted message directly or unset the is_encrypted field of an existing message (instead of encrypting a new message to the public key), then most likely the resulting message will be considered malformed.

Signing a message will only work if from is M; new_message does not have any other private keys.

2 The scenarios

2.1 Scenario 0

A->B [not encrypted]: PAY $1000 TO M
B->A [not encrypted]: PAID
A->B [not encrypted]: PAY $0438 TO M
B->A [not encrypted]: PAID

2.2 Scenario 1

A->B [encrypted to B's public key]: PAY $1000 TO M
B->A [encrypted to A's public key]: PAID
A->B [encrypted to B's public key]: PAY $0438 TO M
B->A [encrypted to A's public key]: PAID

2.3 Scenario 2

A->B [encrypted to B's public key, then signed by A's private key]: PAY $1000 TO M
B->A [encrypted to A's public key, then signed by B's private key]: PAID
A->B [encrypted to B's public key, then signed by A's private key]: PAY $0438 TO M
B->A [encrypted to A's public key, then signed by B's private key]: PAID

2.4 Scenario 3

B->A [encrypted to A's public key]: START [random number 1]
A->B [encrypted to B's public key]: [random number 1] PAY $1000 TO M
B->A [encrypted to B's public key]: [random number 1] PAID
B->A [encrypted to A's public key]: START [random number 2]
A->B [encrypted to B's public key]: [random number 2] PAY $0438 TO M
B->A [encrypted to B's public key]: [random number 2] PAID
B->A [encrypted to A's public key]: START [random number 3]
A->B [encrypted to B's public key]: [random number 3] NO MORE PAYMENTS FOR YOU

2.5 Scenario 4

B->A [encrypted to A's public key, then signed by B's private key]: START [random number 1]
A->B [encrypted to B's public key, then signed by A's private key]: [random number 1] PAY $1000 TO M
B->A [encrypted to A's public key, then signed by B's private key]: [random number 1] PAID
B->A [encrypted to A's public key, then signed by B's private key]: START [random number 2]
A->B [encrypted to B's public key, then signed by A's private key]: [random number 2] PAY $0438 TO M
B->A [encrypted to A's public key, then signed by B's private key]: [random number 1] PAID
B->A [encrypted to A's public key, then signed by A's private key]: START [random number 3]
A->B [encrypted to B's public key, then signed by A's private key]: [random number 3] NO MORE PAYMENTS FOR YOU