sonKsuru Titanium™ Engine (Perfect Secrecy) vs. AES256 Whitepaper

Greg Peatfield

Greg Peatfield

Founding Scientist, Chief Scientific Officer

sonKsuru's QuSmart is 143%/1.43 times faster processing rate versus AES256.

sonKsuru's Titanium™ Engine: A Quantum-Proof, Keyless System Outperforming AES 256 and 143% / 1.43X faster.

Abstract

This whitepaper presents a comprehensive comparison between the patent-pending technology from sonKsuru and AES256. The focus is on the efficiency and practicality of the use of sonKsuru’s Perfect Secrecy within cryptography. The unique approaches to sonKsuru’s product, the Titanium™ Engine, is cheaper, faster, commercially more practical, and more secure. It is quantum-proof. It shows a 143%/1.43 times faster processing rate versus AES256.

Introduction

The field of cryptography has been rife with questions regarding the efficiency and practicality of Perfect Secrecy. The primary concern revolves around the cost comparison of Perfect Secrecy and AES256. This paper aims to provide a detailed comparison of these two technologies, highlighting the unique approaches of sonKsuru’s Titanium™ Engine. 

Background

As of the time of this whitepaper’s publication, AES256 is the only encryption algorithm selected by NIST that offers Post Quantum Computing protection for encrypted data. AES256 encryption relies on a mathematical algorithm that is considered NP-hard to crack or simply too complex to solve within a reasonable timeframe. This complexity is believed to provide a long “safe time” for digital assets/data encrypted with AES256.

However, with the rapid advancements in Quantum Computers and Classical Computers utilizing AI algorithms, concerns have arisen regarding the longevity of AES256’s data safety. These advancements threaten the viability of this encryption method as a long-term solution. It’s important to note that NIST does not claim that AES256 is quantum-proof, only that it is currently quantum-resistant, acknowledging that this status could change in the future.

Traditional Perfect Secrecy: The Solution and Its Challenges

The proposed solution to this problem is Perfect Secrecy. There isn’t much published about this concept other than other sources driving this whitepaper which state it isn’t practical to implement Perfect Secrecy. Perfect Secrecy is made up generally of more of a formula such as:

In this formula, where “i” is the index of the message byte/data, Fi is the encryptor of message Xi which uses Yi to generate the cyphertext Zi which is the perfect secret. Y is sometimes called the Mask or Pad depending upon function performed by “fi()”. The important part here is to realize that the cyphertext Zi is a function of both Xi (the plaintext message to encrypt) and Yi (some unknown data). Since Z is the only part published, to get X you need to know Y. This is because you have 1 equation with 2 unknowns. To look at “f” as a simple additional operation (X + Y = Z), to solve to X (decrypt to plaintext) you need Y & Z (X = Z – Y). Until Y can be obtained, there is no solution for X, making it a perfect secret.

Here is where practicality comes in as an issue. To encrypt X into Z, you need to generate a secret Y. But to now decrypt Z back into X plaintext, you need Y again. This means, for Z to be useful in the future and be decrypted, Y needs to be associated with this transmission in secret. Given that Y is indexed by the number of bytes, if you have a 1 MB Z cyphertext, then you must maintain a 1 MB Y Mask/Pad to recover X the plaintext. AES256 only uses a small key for its encryption algorithm, and is easier to transmit secretly than 1 MB of Mask/Pad data.

The problem exacerbates for longer files. The issue boils down to how the AES256 key is created and how the newer Post Quantum Computing keys are generated. The use of a public-key encryption system such as Diffie-Helman (not quantum safe but still in use today) and PQC algorithms such as Kyber are very computationally intensive and generate keys on the order of 64 bytes of a shared secret between the end-points. The time, network traffic, and CPU utilization of using this for a 1MB+ secret Y is impractical. It also limits the applications that will work with the technology as Video and possibly audio connections are not possible due to the need for constant generation and transmission of Y also as a perfect secret is not practical.

sonKsuru’s Titanium™ Engine has been designed from the ground up to circumvent the pitfalls of what is considered Perfect Secrecy. While we use the same “f(x,y) = z” concept, our implementation of this approach eliminates the impractical aspects of Perfect Secrecy.

sonKsuru's Titanium™ Engine: A Revolutionary Approach

sonKsuru’s Patent Pending technology has been designed to address the primary challenge in maintaining Perfect Secrecy – the transmission of Y. This is achieved through a form of Classical Entanglement, which is modeled after Quantum Entanglement but implemented in the digital domain. By eliminating the need to transmit Y, sonKsuru can create more complex cryptological solutions that allow the merging of data and control planes as well as multiple streams of data.

So, a sonKsuru solution might look more like the following, where “f()” looks more like:

Given some series of messages X1-N one or more Y values can be used to obfuscate (encrypt) the message into its combined stream Zk, where Zk is the transmitted cyphertext containing all messages X1-n in Perfect Secrecy in a highly efficient method. Since Y isn’t transmitted to decryption end-point, sonKsuru’s Titanium Engine is effective for data at rest and a highly efficient method of encryption data in motion.

The Titanium™ Engine ecosystem incorporates an AES256 preprocessing for customers who require AES256 but also want the additional benefits of the Titanium™ Engine. Testing was conducted in four different configurations on identical hardware/software to eliminate differences in system performance. All tests were performed locally on a Dual Intel Xeno X5650, Ubuntu 22.04 Desktop with a physical hard drive and sufficient memory for the application, 70GB+. The four different configurations include System (IO Handling), Titanium™, Titanium™ With Corruption Detection, and AES256.

System: The ecosystem is configured to accept input on a TCP/IP port and echo it back after performing no encryption. This is to baseline the pure IO required for processing the test file so it can be subtracted from the data samples for comparison of the underlying technologies. All of the following configurations will use this basic system. 

Titanium™: The sonKsuru Perfect Secrecy 1-1 comparison to AES256. Comparing the performance and cost of these two methods is the primary focus of this whitepaper.

Titanium™ With Corruption Detection: The Titanium™ Engine is configured with Perfect Security as well as corruption detection. As will be shown in the results, detection of data corruption with perfect security can be achieved with less CPU/Time than required for AES256.

AES256: The ecosystem is configured with AES256 encryption with a random Key (no Public-Key exchange included) and without Perfect Secrecy or corruption detection. This configuration uses the Rust programming language Crates to make up an AES256 Block cipher: 

  • AES version 0.8.3
  • CBC version 0.1.2

A test file of approximately 325.8 MB was used as the input for all tests. The file was chosen due to its availability and size. A larger size was used to eliminate any startup IO issues with the data stream and to get finer measurements on processing time. Processing time was calculated internally to the system where the start time was when the input port was connected to by a “NetCat” command sending the test file, to the time the returned data was exhausted, and the port closed. This was captured from the output of the system.

Test Results

Here is an example output of the “Time processing data” highlighted below. Some data is blacked out due to confidentiality. 

The attached data sheet (Appendix A) includes 80 raw data samples. It shows the conversion to Normalized Time for the operations, allowing the system IO to be removed from the algorithm comparisons. These normalized times were then converted to mb/sec data rates for both the Titanium™ Algorithm alone (1-1 comparison) and with the addition of Corruption Detection. These values were then compared to show the relative speed of the three encryption algorithms.

A summary is shown below:

sonKsuru's Titanium Engine: A Quantum-Proof, Keyless System Outperforming AES 256

The sonKsuru Titanium™ Engine performs 143%/1.43 times faster than the industry standard AES256. Perfect Secrecy is not more expensive than the current state-of-the-art. In fact, it is more efficient, so it can be extended to include additional features. As shown above, adding corruption detection makes Perfect Secrecy with corruption detection 96%/.96 times faster than AES256. Given the need for maintaining keys with AES256 and the speed and other advantages of sonKsuru’s patent-pending Titanium™ Engine, it is difficult to see how Perfect Secrecy is more expensive or impractical to implement. This study concludes that the Titanium™ Engine offers a promising and efficient alternative to traditional encryption methods.

Scroll to Top