Command Codes

Send Key

Allows clients to send a 128 bit cryptographic key to a server or other machine for the purposes of encrypted communication. This key is undiscoverabl except in the case where all 25 raida administrators unite their data within a few seconds of the key being sent.

Here are the steps to share a key with a server

1. QClient resolves the server's IP address, port numbers,raida membership and key IDs using DNS service records(SRV)
2. QClient generates a Raida Scatter Table to scatter the key parts amoung random data.
3. QClient shardes the scatter table into 25 rows. One shard for each raida.
4. QClient encrypts each shard using existing shared secrets with the raida (128 bit AES).
5. QClient sends each shard to the corrensponding raida's "Send Key" service.
6. Raida decrypts the client's request and finds the server's IP, port, key ID, challenge and other information.
7. Raida uses the server's key ID to encrypt the shard and sends the request to the QServer "Receive Key service".
8. QServer decrypts the raida's request, puts together the shards, finds the key in the Raida Scatter Table and records the key.
9. QServer encrypts Qclient's challenge and respondes to one of the raida.
10. Raida sends the QServer's acknoledgement and responds to the QClient with other requirments like key changes
11. QClient stores the key and follows the QServers requests

RAIDA Scatter Table

The scatter table is designed to allow a client to pass a key to another machine without the raida admins being able to discover the key. The scatter table can also protect the key from tappers unless they are able

Here's how it works:

Input:

You provide a number called "remainder" (between 0 and 24).

Goal:

Generate a list of 25 random numbers (each between 0 and 24) that, when added together, gives a sum that has the same remainder as the input "remainder" when divided by 25.

Process:

The client algorithm keeps creating random lists of 25 numbers.

For each list, it adds up all the numbers and checks the remainder when the sum is divided by 25.

If the remainder doesn't match the input "remainder," it throws out that list and tries again with a new random list.

It repeats this until it finds a list where the sum's remainder matches the input "remainder."

Output:

The final list of 25 numbers, where each number is between 0 and 24, and their sum, when divided by 25, has the specified remainder.

Example

Suppose the input "remainder" is 7: The algorithm generates a list like [3, 12, 8, ..., 15] (25 numbers). It adds them up, say, to 307.

It checks: 307 ÷ 25 = 12 with a remainder of 7 (since 25 × 12 = 300, and 307 - 300 = 7).

Since the remainder (7) matches the input, it returns this list.

If the remainder didn't match (e.g., it was 10), it would generate a new random list and try again.

Why It Works

Since the numbers are random and between 0 and 24, the sum of 25 numbers can produce a wide range of remainders when divided by 25.

By repeatedly generating lists, thealgorithm eventually finds one that satisfies the condition.

This trial-and-error approach ensures the remainder matches the input, though it might take multiple attempts.

This method is like rolling dice until you get the desired outcome, ensuring the list is random but meets the specific remainder requirement.

The client sends each RAIDA one of these 25 stipe to a random raida without using the standard

Random Number Table Generator

Each row contains 25 random numbers (0-24) and these numbers are five bits in length. The sum of these numbers has a specific remainder when divided by 25. Here is an example of a table generated so that each column has a unique remainder 0 through 24. These values are shown in Base25.

Byte Layout of SendKey Request Body: 50 bytes fixed.

NOTE: The server will decide the DNs and the SNs of the two keys. The server will also decide the second key by sending the "offset" of the second key. If the scatter table is flattened out into one array of bytes. Then the offset is how many index numbers that should be added to find the byte of the second key. After the table is flattened, it will have 400 bytes. If the first byte of the first key part is at index 55 and the offset is 20 then the first byte of the second key will be byte at index 75. It will need to wrap around after 400.

Response Format:

Response Status Codes

KEY POST

The sender computer that wants to initiate an encrypted session with a receiver server will take a key and divide into parts. Then it will post each part on a different RAIDA.

It is the client that must handle the keys as the Post Key service has no logic besides storing data. See the Key Post Client Guidelines below for details.

Each RAIDA can store 128 bytes of a key.

Sample Request: 185 bytes fixed.

NOTE: The Key Start and the Key Length help to strengthen the encryption. It also reduces DOS attacks designed to use up system resource. The key used to encrypt the request will write over any other requests it has made. Each encryption coin can only make one request at a time and is the Primary key in the RKE server's key table.

Response Status Codes

KEY ALERT

Tells the Receiver that there are keys waiting for it. The client can use any combinations of RAIDA it wants to. It can use all 25 or just 2. However, the receiver has the option of using a subset of the key parts that they Sender has suggested. This is because the Receiver may not trust all the RAIDA suggested. In this case, the client will need to assemble the key parts in a different manner.

Sample Request (Unencrypted): 62 bytes for every key part plus two ending bytes.

Sample Response to Sender:

Sample Response Body Showing that key parts 0, 1 and 3 where used and key part. They must be put together in that order.

KEY GET

Allows a client to get a key on an RKE server that was left for them by a computer initiating a private conversation.

Sample Request fixed size:

Sample Response fixed size:

The receiver and the client must store the Key ID and its key. They key ID will be bytes 17,18,19,20 and 21 in the request header.

Response Status Codes

Pass Key Through RAIDA

The client sends the key to the RAIDA and the RAIDA sends it to the server.

The client takes a key and stripes it and create parity stripes. Then the client sends each stripe to a random raida without using the standard way of writing it. The standard way is that stripe 0 goes to r5, 1 goes to r6 etc.

Here is the algorithm

The algorithm creates a list (array) of 25 random numbers, where each number is between 0 and 24 (inclusive). The goal is to ensure that when you add up all 25 numbers and divide the sum by 25, the remainder matches a given input number called "remainder" (which is also between 0 and 24).

Here's how it works:

Input: You provide a number called "remainder" (between 0 and 24).

Goal: Generate a list of 25 random numbers (each between 0 and 24) that, when added together, gives a sum that has the same remainder as the input "remainder" when divided by 25.

Process: The algorithm keeps creating random lists of 25 numbers.

For each list, it adds up all the numbers and checks the remainder when the sum is divided by 25.

If the remainder doesn't match the input "remainder," it throws out that list and tries again with a new random list.

It repeats this until it finds a list where the sum's remainder matches the input "remainder."

Output: The final list of 25 numbers, where each number is between 0 and 24, and their sum, when divided by 25, has the specified remainder.

Example Suppose the input "remainder" is 7: The algorithm generates a list like [3, 12, 8, ..., 15] (25 numbers). It adds them up, say, to 307.

It checks: 307 ÷ 25 = 12 with a remainder of 7 (since 25 × 12 = 300, and 307 - 300 = 7).

Since the remainder (7) matches the input, it returns this list.

If the remainder didn't match (e.g., it was 10), it would generate a new random list and try again.

Why It Works

Since the numbers are random and between 0 and 24, the sum of 25 numbers can produce a wide range of remainders when divided by 25.

By repeatedly generating lists, the algorithm eventually finds one that satisfies the condition.

This trial-and-error approach ensures the remainder matches the input, though it might take multiple attempts.

This method is like rolling dice until you get the desired outcome, ensuring the list is random but meets the specific remainder requirement.

PEER TO PEER

How computers connect to each other after key exchange.

1. The client and server must have the RAIDA Token Core Traffic Router Installed
2. The client and server must be direct software to use the traffic router as a default gateway.
3. The encryption type in the request header should be '3'
4. Bytes 17 through 21 in the Request header should be the key ID This is used when two computers who have used RKE to exchange keys are using byte 17 through 21 of the header as an ID for a key instead of a coin.

Post Key Client Protocol

This is how clients should use the RAIDA to send keys.

Assume we have the following Bitcoin Address:

The client should first break this up into 16 parts. The table below shows the key part and what RAIDA that key part should be stored on. R05 means RAIDA 5.

Then the parity information is calculated horizontally and vertically according to the following diagram.