Data Supremacy From Publisher to Consumer

diagram of components

Let's see how we secure data through each component:

1. RAIDA (Redundant Array of Independent Data Agents)
2. Guardians
3. Internet between the RAIDA and Data Creators and Data Consumers
4. Data Consumers
5. Sensors (Data Creators)

RAIDA Architecture

There are two primary types of architecture used on the Internet: Peer-to-peer (e.g. Blockchain) and Client-Server (used by everything else including cloud computing). However, RAIDATech has invented and patented Client-Server-Array architecture we call RAIDA (Redundant Array of Independent Data Agents).

Network Archetectures

Unique features of the RAIDA architecture include:

  1. Servers are accessed in parallel dramatically reducing the time to upload and download data. Peer-to-peer and client-server systems are accessed in serial.
  2. The servers can be operated by independent agents who may be adversarial to each other but have a common mission to secure the data. Because of this, the RAIDA cannot be compromised by rogue system administrators.
  3. The client computers are the “master” computers in charge of synchronizing data and doing a lot of processing. This takes the load off of the servers.

RAIDATech combines this patented architecture with two other valuable patents-pending innovations including the RKE (RAIDA Key Exchange) that allows for quantum-safe cryptography key exchange between two unrelated computing devices.

RAIDA Locations

RAIDA servers can be located anywhere that electricity and bandwidth are available. They are efficient enough to be placed on satellites, ocean vessels, remote locations, military bases, cell and satellite phones, vehicles, commercial data centers etc. One of the primary requirements for sensors may be datastorage. In this case, each RAIDA server only needs to have 1/16th the data storage capacity of a typical server because the data is distributed to 16 data servers. These servers can be kept in different legal jurisdictions to prevent government takeovers.

RAIDA DATA, The RAIDA’s Storage Protocol

RAIDATech has a technique used for storing data in such a way that we can lose five data devices when the high risk devices are identified and up to three out of sixteen in cases where the likely hood of server failure is the same for all servers. Suppose you have twelve RAIDA servers located in safe buildings. Four more of your servers are located on drones in combat zones. The drones would be marked as high risk and could all be lost along with one in a building. This is a big technological advancement because the best systems in the world today can only handle losing two. If we add three more parity servers, we can handle up to 5 data storage devices failing. Our level of toughness is ideal for military grade storage where adversaries strategically target servers in an effort to bring critical systems offline and cause permanent data loss. Here is a comparison of common fault tolerant systems with our RAIDA system.

RAID Level

Servers Used for Data

Severs Used For Parity

Total Servers

Capacity Utilization

Servers Needed to Disable to Neutralize System

Max Data Servers That Can be Recovered

Cost per 1TB @ $100

Typical RAID 10 (Not RAIDA Tech)








RAIDATech's High Performance








RAIDATech's Crystal RAID





3 to 5



This technology is something that gives RAIDATech a unique advantage over the competition and is something to brag about. Again the closest competing algorithm can only lose 2 disks while ours can lose 5. Existing algorithms could achieve the ability to lose five disks only by making two mirrors of RAID 5. But this would cost $313 per 1TB (as in the example above), double the price of our RAIDA technology.

The images above show a logical arrangment of the 25 RAIDA servers. The first image shows two bytes (16 bits) being written to the RAIDA. The bytes are divided bit by bit into sixteen parts with each bit going to a different data server (the blue blocks). Vertical parity is calculated and stored in four of the parity RAIDA (red blocks). Horizontal parity is calculated and stored on another four parity servers (the green blocks). The last shows RAIDATech's "RAID Crystal" that uses data from a repeating patterns of RAIDA servers to creat parity information stored in the yellow block. If high-risk of loss servers are placed in the yellow highlighted blocks, five RAIDA can be restored.


It is up to the client to decide how they will place data on the RAIDA's 25 servers. If the servers are dependable, the client can use RAIDA 5 which splits the data into twentyfour stripes and one parity server. This provides the most efficient data storage with the fastest read and write times at the expense of fault tolerance only being able to lose one server vs three servers.

Hot Standby RAIDA

RAIDATech’s storage technology can increase the level of fault tolerance to require that 6 servers be knocked offline before the system is unavailable. This is done when each RAIDA is given a hot-swappable mirror so that if the primary RAIDA goes down, the sensors can immediately detect the downed RAIDA and switch to the mirror. This further reduces the possibility of RAIDA downtime.

Role-Based Security

Sensors are given “Sensor IDs” that give them the right to write data on the RAIDA to their specific folder. Data Consumers have “Consumer IDs” that allow them to access all “Sensor Data”. Although not implemented, it can be developed so that each Sensor’s data has an Access Control List to specify which Data Consumers have access to which sensor’s data.

RAD (RAIDA Active Directory)

RAIDA Active Directory has not been implemented yet but has been envisioned. RAD would allow system administrators to create and user and group accounts, create group policies, set auditing policies and administer the RAIDA with complete granularity. e.g., it would be possible to require that Sensor #4938 only be able to access the RAIDA using a specific IP address, only at a specific time window, and only with a certain amount of data.

RKE (RAIDA Key Exchange)

RAIDATech has a patent on a quantum-safe cryptographic key-exchange system we call the RKE. This key exchange protocol will allow your sensors to connect directly to your data consumers without going through the RAIDA. In this case, a typical client-server architecture would be created.

RAIDA Efficiency

The RAIDA is extremely efficient for many reasons. Its use of quantum-safe AES encryption utilizing the Intel® AES machine instructions reduces the number of CPU cycles needed to encrypt or decrypt to about ten which requires just nanoseconds. This compares to the time it takes most every other server to use quantum-vulnerable TLS key exchange with CPU cycles needed to encrypt and decrypt between 100,000 and 1 million CPU and requiring milliseconds.

The RAIDA software is written in the ‘C’ language which is ten times faster than other languages such as ‘C#’. Reducing the CPU cycles reduces electricity usage, which reduces heat and the need for cooling. Our system reduces power consumption, system weight, battery life, cost of machine, bandwidth usage and length of service.


To remove all systemic risk of failure, the RAIDA needs some extra internet infrastructure. Potential failures include these problems:
1. DNS Domains and DNS servers could be compromised causing traffic to be directed away from the RAIDAs and into spoofed RAIDA.
2. If adversaries know the IP addresses of RAIDA servers, the physical location of the RAIDA may be determined leading to a physical attack.
3. If hot-swappable mirrors are implemented, a witness server is needed to help the hot-swappable servers to be promoted to Primaries.


Sensors need to be able to find the IP addresses of the RAIDA servers that they will be storing data on. Instead of trusting publicly available DNS infrastructure, we use 30 “Guardians” for name resolution. The sensors have the IP Addresses of the 30 Guardians hardcoded into them (RAIDA hints). During initialization, the client pings these Guardians to determine which ones are available. The sensor will then randomly choose three of the Guardians and download a host file from each of them. The host files are compared and if all three match, the IP addresses of the RAIDA and their backup mirrors are accepted. If they do not match, three more are randomly chosen until matches are found.

Proxy Servers

Many of these IP addresses can point to the Guardians themselves. The Guardians can act as reverse proxy servers, routing traffic back and forth to the RAIDA and the Sensors so that the true IP address of the RAIDA servers are unknown to anyone but the Guardians.


If hot-swappable RAIDA are desired then a witness is necessary to ensure that the hot-swappable Mirror Server is synchronized with the Primary and confirm to the hot-swappable Mirror Server that it needs to elevate to Primary. RAIDATech has implemented version 1 of this technology and would further development to create a production ready custom system. In the meantime, off the shelf software provides some alternatives ifø it is needed now.



The Internet allows for two different transport protocols: TCP and UDP. The UDP protocol is faster than TCP because UDP is “fire and forget” while TCP requires a “handshake” and is a very heavy protocol made to work through nuclear war. Most traffic uses TCP because UDP can lose data. However, because of RAIDATech's Data storage technology, we can afford up to nine of twenty five UDP packets and still be able to read the data. Therefore, we can trade some of our fault tolerance for speed which removes the need for a TCP handshake and shaves a half a second off of each request and response. This and other innovations add up to make RAIDA Data the fastest data storage solution in the world.

For most applications, UPD can only handle 1450 bytes of data before it becomes unusable. UDP can suffer from lost packets, out-of-order packets, dumped packets by routers and return packets being lost. While most UDP programs can only move 1400 bytes at a time reliably, using RAIDA DATA, sensors can move 22.4 KB at a time (1400 bytes per packet x 16 ). If we own all the routers between the sensors and the RAIDA, we can configure them to increase the data sent reliably to a whopping 1 MB at a time.

Sensors & Data Consumers

Sensors are devices located in unsecure locations in risky conditions and face unforeseeable attacks from the most sophisticated advesaries. Data Consumers need accurate knowledge in a timely manner to make intelligent decisions. It is critical that both the Sensors and Data Consumers be secure without suffering from time-lags.

Sensors and Data Consumers Require 25 AES Keys (Advanced Encryption Standard)

Both will have a digital ID in the form of a file containing 430 bytes. This digital ID is composed of a serial number (similar to a driver's license number or SSN) and twenty five unique 128-bit encryption keys. Our custom protocol allows the RAIDA and the sensors to mutually authenticate each other while providing quantum-safe communication. These encryption keys can be changed at any frequency required including on every call to the RAIDA.

Sensors and Data Consumers Use Quantum Safe Encryption

The protocol allows for any type of asynchronistic quantum-safe encryption protocol but uses 128 bit AES as a default. AES 128 allows for suitable encryption at high speeds and low energy use. Most Intel processors have machine commands for AES encryption which reduces processor time to just ten CPU cycles. (Compare this to millions required for TLS)

Sensors Stripe Data and Calculates Parity Stripes. Data Consumers Unite the Stripes

When sensors send data, they will divide the data bit by bit into sixteen different “stripes”. Nine more stripes are calculated for the purpose of fault tolerance and availability. Sensors can send these stripes in a random order to RAIDA severs so long as the Data Consumer also knows the order. See the RAIDA section.

Sensors and Data Consumers May Use Multiple Internet Connections

Both may have multiple connections to the Internet such as cellular, WiFi, terrestrial cable, satellite, and infrared wireless. The sensor can send each stripe out of different network interfaces. By splitting the data into different streams, tapping becomes much more challenging as adversaries will need to combine at least 16 stripes to capture the data. Splitting the streams also adds more bandwidth that can speed up transmissions. (NOTE: Custom Multi Gateway software has not been implemented yet but could be purchased off the shelf)

Sensor And Data Consumer Software

The client software has two components: The GUI and the Client Core. The GUI runs within a web browser and the Client Core is a simple console application. For sensors, only the Core is needed as the GUI is for data consumers. The core is REST-enabled and CLI-enabled. This makes it easy for sensor software written in any language to send data to the RAIDA by making simple API calls to the Client Core. The client software is written in the GoLang language but can be converted to the C++ language to make it faster, more energy efficient and to use less system resources (RAM, Storage, Processor Cycles). Rewriting it in C++ may be a fairly easy job with the help of AI translating the code.

Internet Routers Split Streams

Once those stripes are on the Internet, they will encounter routers that will send packets in different directions depending on where the RAIDA servers are located. Given the fact that our servers are strategically distributed on a global scale, encompassing terrestrial as well as marine and extraterrestrial locations, the routing of the stripes necessitates diverse directional paths. This crucial aspect significantly enhances the complexity for any potential adversary in capturing a sufficient number of stripes, thus reducing their capacity to pose even a minimal threat.

What If An Adversary Was to Successfully Tap 16 Stripes of Data?

If an adversary was to capture all the stripes, they would not know the index numbers of each stream. They would not be able to put the stripes together in the correct order. We calculate that there are over sextillion different combinations should they try to guess.

If they did get them in the correct order, they would need to guess a quantum safe 128 bit key with over a Septillion possibilities. But each stripe is encrypted with a different key. So they would need to decrypt at least sixteen keys so we can multiply that by 16. If they were able to crack those 16, they would not be able to tell that they had decrypted the data because the payload in each stripe will appear as random data.

The RAIDA can block any guessing attempts that it detects and simply refuse to respond to requests. The encryption keys used by RAIDA clients can change every time they are called so that if decryption occurred, they would only get 22 Kilobytes of data. Note: Intrusion detection has not been implemented yet but would be relatively easy to do.

Speed Of Downloading and Uploading Data

The time it takes a Data Consumer to download data from the RAIDA can be as much as sixteen times faster thanks to the striping. Generally speaking, reading and writing from many servers in parallel is multiple times faster than reading or writing from just one server.

Local Storage of Data

In our current implementation, the data files downloaded from the RAIDA ( e.g. PDF, PNG and TXT ) are displayed within browsers. The files are kept in the client’s RAM so that the files will not be compromised if the physical integrity of the client computer is compromised. If the computer is shut down, all files in RAM will be lost. Note: we have the option of encrypting the files in RAM although it has not been implemented.

Physical Security of Sensors

RAIDATech has envisioned a system that uses a 3D printer and a fiber optic cable to create a “Cocoon” around the sensor’s motherboard. The fiber optic cable would be plugged into the motherboard and work off the sensor’s power bus which is powered by an external power supply. In the case of an external power loss, the fiber optics would depend on a rechargeable battery within the cocoon.

This fiber optic cocoon would be impregnated into a resin by using a 3D printer.The cocoon would be woven in such a way that it would be impossible for adversaries to access the sensor’s TMP chip without breaking the fiber optic cable. The motherboard’s CMOS chip would constantly ping the fiber optic cable to detect breakage even when the sensor loses external power. If the CMOS chip detected that the fiber optic cable was broken, the CMOS would delete the sensor’s ID. This would require that the ID be replaced before the sensor could be authenticated by the RAIDA again.

Beware the HAITERS

Hackers. AI. Tech Giant. Enemy Governments. Rouge System Admins. Haiters

Thank you! Contact for more information.