But first of first, let's watch this video.
Well, the reason is surprisingly complicated, and it may take a long time to elaborate here. Nevertheless, there is one thing to know: in the respect of whole-file cryptography, the best solution we can find was brought to the world 22 years ago, and this solution, along with other similar solutions, just can't do their job in the intuitive way we expect.
Now, we are glad to have this opportunity to introduce fusionTAP, a new cryptographic solution that may profoundly influence our digital life in the future.
* Conceptual animation of the implementation
01/ What is fusionTAP
"O(n!)→O(log(n!))" kind of NP-hard problem."
"fusion" stands for "confusion" and "diffusion", which implies the way how fusionTAP is working on the plaintext.
"fusion" also indicates that all the core technologies in this product are not merely integrated, but intrinsically work as one.
"T", "A" and "P" are respectively the acronyms of tokenization, asymmetric keys, and permutation, which are the three pillars of fusionTAP in terms of technology.
"fusion" is the second half of both "confusion" and "diffusion", which are "two properties of the operation of a secure cipher..."(Cited from Wikipedia Article Confusion and diffusion), implying the way how fusionTAP is working on the plaintext. "fusion" also indicates that all the technologies in this product, including tokenization, permutation, asymmetric keys usage and others, are not merely integrated, but intrinsically work as one. Technological fusion brings chemical effects, and chemical effects bring true magic that delivers unrivalled performances and unleashes a broader range of capabilities.
Tap T, A, or P on the keyboard Cryptographically, tokenization is as simple as the substitution of plaintext with tokens. This is an ancient method to hide sensitive information and is one of the main ways to add a confusion layer to the plaintext nowadays. However, no matter how tricky it can be, tokenization is widely considered not secure enough by itself since the intrinsic lack of diffusion makes it too easy to expose the original patterns. Another obstacle for tokenization as a data protection solution to be widely implemented is that people still cannot find an effective way to randomly generate a token mapping table that is good enough to handle complex situations. The requirement of a token vault seems still the only choice and this of course is a huge burden for any practical applications. Though not as successful and bloomsome as its kin encryption, tokenization still holds significant potential in cryptography being a non-mathematical approach to generate ciphertext, which could make a big difference in the post-quantum computing era … as long as we can get rid of the weaknesses mentioned above.
Roundtable Knights here proudly make this announcement - it is happening now!
After some major mathematic problems 
being conquered, the tokenization tech in fusionTAP is now rocketing to a brand-new level: The property of confusion that does not simply reach the highest level but goes far off the chart (A bold statement! But it is what it is), the unbeatably fast speed, the scalability of the security level, the parallelability, and of course the vaultlessness, all are attributed to the "T" inside the core.
An asymmetric key cryptographic scheme, apart from its complex definitions in cryptography and mathematics, is like the mechanism of a lock and a key. Anyone can close and lock the door of a house, but only the holder of the key can enter it. Imagine a world where you must hand out your key if there is a need for someone else to lock your valuables in the safe. Would it be horrifying? With the current implementation of file encryption, we are indeed experiencing the dilemma: If you need to encrypt a file, you must hand out the key, but if you hand out the key, you might no longer be its sole possessor. Anyone who uses a block cipher system like AES for data protection has to face this dilemma painfully. Numerous attempts and proposals have been made, and indeed some of them to some extent bring relief in certain specific application scenarios, nevertheless, the fundamental problem remains unresolved. All in all, we are still suffering because only a few symmetric systems like AES and Chacha-poly are by far the reliable solutions fast enough for whole-file encryption in the industry.
fusionTAP provides a solution with faster speed and higher security level, and the realization of native asymmetric keys is the foundation of the whole "TAP" scheme. Ciphering can be done without the risk of key exposure, while the reverse process is only possible with the presence of the key. This intuitive solution has the potential to unlock new and previously unattainable architectural possibilities.Our team has already come up with a handful of new application scenarios, which we will be delighted to share with you in the coming weeks.
Permutation, if its combinatorial property has to be explained in one phrase, is the art of rearrangement. Permutation is naturally a great helper for tokenization, for it makes the adjoining elements in the plaintext "disperse", and thus efficiently destroys the original patterns and structure in the ciphertext, which theoretically adds a diffusion layer to the confusion caused by tokenization. In the system of fusionTAP, "T" and "P" are glued together by a self-developed technique called "bullettrain7", and this kind of cooperation is distinct from the "substitution-permutation network" cipher structure commonly seen in block cipher schemes. Our idea is far more primitive and bolder, and also effective.
Hopefully, there will be an opportunity to talk about it in the near future.
Cryptographically, tokenization is as simple as the substitution of plaintext with tokens. This is an ancient method to hide sensitive information and is one of the main ways to add a confusion layer to the plaintext nowadays. However, no matter how tricky it can be, tokenization is widely considered not secure enough by itself since the intrinsic lack of diffusion makes it too easy to expose the original patterns. Another obstacle for tokenization as a data protection solution to be widely implemented is that people still cannot find an effective way to randomly generate a token mapping table that is good enough to handle complex situations. The requirement of a token vault seems still the only choice and this of course is a huge burden for any practical applications. Though not as successful and bloomsome as its kin encryption, tokenization still holds significant potential in cryptography being a non-mathematical approach to generate ciphertext, which could make a big difference in the post-quantum computing era … as long as we can get rid of the weaknesses mentioned above.
Roundtable Knights here proudly make this announcement - it is happening now!
After some major mathematic problems being conquered, the tokenization tech in fusionTAP is now rocketing to a brand-new level: The property of confusion that does not simply reach the highest level but goes far off the chart (A bold statement! But it is what it is), the unbeatably fast speed, the scalability of the security level, the parallelability, and of course the vaultlessness, all are attributed to the "T" inside the core.
An asymmetric key cryptographic scheme, apart from its complex definitions in cryptography and mathematics, is like the mechanism of a lock and a key. Anyone can close and lock the door of a house, but only the holder of the key can enter it. Imagine a world where you must hand out your key if there is a need for someone else to lock your valuables in the safe. Would it be horrifying? With the current implementation of file encryption, we are indeed experiencing the dilemma: If you need to encrypt a file, you must hand out the key, but if you hand out the key, you might no longer be its sole possessor. Anyone who uses a block cipher system like AES for data protection has to face this dilemma painfully. Numerous attempts and proposals have been made, and indeed some of them to some extent bring relief in certain specific application scenarios, nevertheless, the fundamental problem remains unresolved. All in all, we are still suffering because only a few symmetric systems like AES and Chacha-poly are by far the reliable solutions fast enough for whole-file encryption in the industry.
fusionTAP provides a solution with faster speed and higher security level, and the realization of native asymmetric keys is the foundation of the whole "TAP" scheme. Ciphering can be done without the risk of key exposure, while the reverse process is only possible with the presence of the key. This intuitive solution has the potential to unlock new and previously unattainable architectural possibilities.Our team has already come up with a handful of new application scenarios, which we will be delighted to share with you in the coming weeks.
Permutation, if its combinatorial property has to be explained in one phrase, is the art of rearrangement. Permutation is naturally a great helper for tokenization, for it makes the adjoining elements in the plaintext "disperse", and thus efficiently destroys the original patterns and structure in the ciphertext, which theoretically adds a diffusion layer to the confusion caused by tokenization. In the system of fusionTAP, "T" and "P" are glued together by a self-developed technique called "bullettrain7", and this kind of cooperation is distinct from the "substitution-permutation network" cipher structure commonly seen in block cipher schemes. Our idea is far more primitive and bolder, and also effective.
Hopefully, there will be an opportunity to talk about it in the near future.
Cryptographically, tokenization is as simple as the substitution of plaintext with tokens. This is an ancient method to hide sensitive information and is one of the main ways to add a confusion layer to the plaintext nowadays. However, no matter how tricky it can be, tokenization is widely considered not secure enough by itself since the intrinsic lack of diffusion makes it too easy to expose the original patterns. Another obstacle for tokenization as a data protection solution to be widely implemented is that people still cannot find an effective way to randomly generate a token mapping table that is good enough to handle complex situations. The requirement of a token vault seems still the only choice and this of course is a huge burden for any practical applications. Though not as successful and bloomsome as its kin encryption, tokenization still holds significant potential in cryptography being a non-mathematical approach to generate ciphertext, which could make a big difference in the post-quantum computing era … as long as we can get rid of the weaknesses mentioned above.
Roundtable Knights here proudly make this announcement - it is happening now!
After some major mathematic problems being conquered, the tokenization tech in fusionTAP is now rocketing to a brand-new level: The property of confusion that does not simply reach the highest level but goes far off the chart (A bold statement! But it is what it is), the unbeatably fast speed, the scalability of the security level, the parallelability, and of course the vaultlessness, all are attributed to the "T" inside the core.
An asymmetric key cryptographic scheme, apart from its complex definitions in cryptography and mathematics, is like the mechanism of a lock and a key. Anyone can close and lock the door of a house, but only the holder of the key can enter it. Imagine a world where you must hand out your key if there is a need for someone else to lock your valuables in the safe. Would it be horrifying? With the current implementation of file encryption, we are indeed experiencing the dilemma: If you need to encrypt a file, you must hand out the key, but if you hand out the key, you might no longer be its sole possessor. Anyone who uses a block cipher system like AES for data protection has to face this dilemma painfully. Numerous attempts and proposals have been made, and indeed some of them to some extent bring relief in certain specific application scenarios, nevertheless, the fundamental problem remains unresolved. All in all, we are still suffering because only a few symmetric systems like AES and Chacha-poly are by far the reliable solutions fast enough for whole-file encryption in the industry.
fusionTAP provides a solution with faster speed and higher security level, and the realization of native asymmetric keys is the foundation of the whole "TAP" scheme. Ciphering can be done without the risk of key exposure, while the reverse process is only possible with the presence of the key. This intuitive solution has the potential to unlock new and previously unattainable architectural possibilities.Our team has already come up with a handful of new application scenarios, which we will be delighted to share with you in the coming weeks.
In this part we are going to introduce some of what we think will interest you in fusionTAP with respect to its security, speed, asymmetric nature, access control ability, and bloat rate.
The brute force possibilities for breaking the cipher text generated by fusionTAP is at least 22656 .
* The sum of all the atoms in the universe is about 2260
fusionTAP is a strong probabilistic cipher, and that means if using the same key for ciphering the same file, the resulting token would be nearly impossible to be the same.
The ciphering process is extremely time-sensitive, with the output ciphertext potentially differing every nanosecond, and unaffected by system time halts.
InputOutput* Conceptual demonstration of time-sensitivity
The brute-force possibilities could be raised from 22656 to 226560 with trivial efforts.
There is no mathematical relationship between plaintext and ciphertext/ciphertext and private key. This could make a big difference in the post-quantum computing era.
Before we discuss this topic, we might need to review the definition of semantic security. We say that an encryption scheme is semantically secure when, given two plaintexts and a ciphertext, with the knowledge that the ciphertext is generated from one of the two plaintexts, the adversary cannot choose the right plaintext used for encryption with better probability than 50%.
Traditional tokenization and conventional block cipher (like the ECB mode) don't have semantic security. Because in both schemes, plaintexts are divided into a sequence of rather small units which are processed individually by the same token mapping table or process method. If there is no other means by which we can hide or distort the relationship among the sequence of units, certain patterns in the plaintext may be preserved in the ciphertext, and they are likely to provide chances for the adversary to gain an upper hand in selecting the right plaintext.
As a result, cryptographers believe that the conventional methods mentioned above can provide confidentiality only if the plaintext is uniformly random. Otherwise, if the plaintext has any recognizable patterns, a serious leakage of potentially important information may happen. For example, the Electronic Codebook (ECB) mode, one of the four "classical" modes for block cipher, can leave plaintext data patterns in the ciphertext when used to encrypt a bitmap image.
Original Bitmap Picture
AES-256-ECBThis is obviously unacceptable, and for this reason ECB mode is not advised to be an independent, general-purpose scheme for serious cryptography. GCM mode was developed on top of ECB and added some very clever ideas to get rid of this weakness.
Original Bitmap Picture
AES-256-GCMfusionTAP, as an innovative cryptographic method derived from conventional tokenization, does not inherit this weakness either. With respect to the diffusion level, it may not seem as good as AES-GCM (which is exceptionally excellent because it strictly can be seen as a stream cipher with the necessary length of the computational pad generated by the block cipher), but good enough for any general-purpose use. As you can see, even if we disable the "P" (permutation) function of fusionTAP, the "T" (tokenization) itself in fusionTAP serves well to provide enough diffusion.
Original Bitmap Picture
fusionTAP with tokenization and permutation
fusionTAP with tokenization onlyHowever, in some specific situations, where the file is big but scarce is the information (which indicates a lot of repetitions in the file), it may fail to meet the standard. For example, let us consider a large bitmap which is purely black (#000000) or white (#FFFFFF). The ciphertext generated by fusionTAP can preserve certain characteristics from the original file, and the adversary will have a much higher probability to choose the right picture if the other candidate of plaintext is a visually complicated image like Van Gogh's 'The Starry Night'.
This is because only confusion and diffusion are not enough for the repetition rate of this high, and if we want to handle this situation, we need to expand it by adding additional information as well. As we can see, fusionTAP does a great job on confusion and diffusion, and it surely expands the original pic to a certain extent, so it seems better than AES-ECB visually. But the degree of the expansion of fusionTAP is not enough to pass the test of semantic security. As a contrast, stream cipher can always handle this situation with ease because substantially the encryption of stream cipher is nothing but adding computational information to the plaintext by the operation of "XOR".
But now, we will argue that this is not a problem of significant concern. Because fusionTAP's extremely high time sensitivity can sooth this pain to a large extent. One question: If we give you six ciphertexts generated from either the white or the black bitmap as below, can you tell which ones are the ciphertexts for the black bitmap? Click Here to show answer
If we compare the six images shown above, we may find the fact that the ciphertexts generated each time for the same bitmap may exhibit greater variation than the ciphertexts generated for different bitmaps. So we can conclude that fusionTAP is semantically secure even when “the file is big but scarce is the information”, as long as the two plaintexts are of the same type and of the same characteristic (such as a pure black and a pure white bitmap). You see, time sensitivity is our friend, isn't it? And this is a feature that separate fusionTAP from any traditional encryptions in the market.
In practice, leaking privacy information due to the vulnerability shown in the case we discussed above is generally rare. It happens most in the lab environment where testers use extreme cases to explore the limit of the algorithm. If it really brings concerns, one solution is to lower the repetition rate by the application of lossless file compression. We are willing to add it to future iterations if necessary.
Let us think of the definition of semantic security once again. Why is semantic security important? In the early days, semantic security is of necessity when the information leakage from encrypted message arose serious concerns in some practical situations. A textbook example for this is that when the two possible messages are "ATTACK AT DAWN" and "ATTACK AT DUSK", the adversary would only have a 50% chance of guessing which is the correct message if the ciphertext is semantically secure. This is a good example to demonstrate semantic security for messages of the same length. But, in real-world scenarios, semantic security is not enough. Because in real world, message length matters. For example, if the adversary knows the message is either "YES" or "NO" in some circumstances, he will have 100% certainty to guess which is the correct message no matter how semantically secure is the ciphertext. A Similar example may be guessing email address like "alice@company.com" or "bob@company.com". Actually, the definition of semantic security is a compromised solution and "since there is no general solution to this problem, most real-world encryption schemes (for example, TLS) do not make any attempt at all to hide the length of the message. This can lead to real attacks.” For example, an article shows that “the lengths of encrypted messages can reveal considerable information about private data that a user supplies to a cloud application" (Dan Boneh and Victor Shoup, A Graduate Course in Applied Cryptography Version 0.6, page 17).
A perfect security for messages, especially short messages which are most seen when chatting on a social media, require not only semantic security but also the ability to hide other traces, like length, to achieve real-world confidentiality.
During the development of fusionTAP, we happily found that it can naturally achieve perfect security for short messages. We believe it might be a general solution for privacy protection on chat apps for every one of us. We wish to share this interesting feature of fusionTAP in the fore-coming blog.
Intel Xeon
Hardware
Linux Server (Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz - 20 cores, 64GB RAM)
Compiler
clang version 17.0.0 (https://github.com/llvm/llvm-project.git 5e262d58c42668c78d932fab6bf75cf8c3b9d07e)
Compiler Flag
-s -fvisibility=hidden -O4 -std=gnu11
Implementation Detail
AES-256-GCM & ChaCha20-Poly1305 is implemented on 256-size block using openssl v3.2.0-dev EVP interface
Source Code
Click to see source code - AES-256-GCM
Click to see source code - ChaCha20-Poly1305
Apple M1
Hardware
Mac Studio (Apple M1 Max CPU - 8 performance cores and 2 efficiency cores, 32GB RAM)
Compiler
Xcode version - Version 14.3.1 (14E300c)
Swift-driver version - 1.75.2 Apple Swift version 5.8.1 (swiftlang-5.8.0.124.5 clang-1403.0.22.11.100)
Compiler Flag
-O
Implementation Detail
AES.GCM and ChaChaPoly is implemented using 256-bit key with Apple CryptoKit
Source Code
Click to see source code - AES-256-GCM
Click to see source code - ChaCha20-Poly1305
The test results of fusionTAP on Intel Xeon reveal that its speed is multiple times faster than AES and ChaChaPoly. More surprisingly, even on Apple M1 where AES is hardware accelerated, the speed advantage of fusionTAP remains apparent, and this advantage is further magnified when processing larger files.
* AES-256-GCM & ChaCha20-Poly1305 is implemented on 256-size block using openssl v3.2.0-dev EVP interface
* Experimenting on a Mac Studio (Apple M1 Max CPU - 8 performance cores and 2 efficiency cores, 32GB RAM)
As we can see on the charts, the time complexity of fusionTAP can be described as a very pleasant O(n). Compared to AES and ChaChaPoly, its slope is much flatter, indicating that for every byte added to the input file, the increase in processing time is negligible.
* In the AES-256-GCM test results on the Apple M1, we can notice two significant peaks. This could be due to the limit of data processing in GCM mode, that the data size cannot be larger than 232 bits, approximately 4.29GB.
* Tested on Linux Server (Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz - 20 cores, 64GB RAM)
Through the tests conducted for the hyper-threading technology with the Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz - 20 cores, we have found that:
We are pleased to see that the deciphering process can get full benefit from hyper-threading. As for the ciphering process, we will try to improve its compatibility with hyper-threading in the next version.
A cipher with a symmetric key setting has only one key for both ciphering and deciphering, but with an asymmetric key setting, it has a pub-key for ciphering and a private key for deciphering.
An asymmetric key scheme is based on a trapdoor function which makes encrypting a plaintext very easy but the reverse process very difficult without the knowledge of the private key. One might easily find out that the functionality of asymmetric keys is plainly better than that of symmetric keys for its flexibility in practice . Unfortunately, despite many years of research, when we talk about asymmetric encryptions, only two candidates are left available in the industry: RSA and elliptic curve encryption, and both are very clumsy (or impractical) for file encryption on any scale. In real practice, almost all of our data and files are protected by symmetric encryptions like block ciphers (like AES) and stream ciphers (like chacha-poly), while asymmetric encryptions are popular in key-exchange protocols and authentications.
The native asymmetric key algorithm in fusionTAP is more the kin of RSA, which means that ciphering can be done without the risk of key exposure, while the reverse process is only possible with the presence of the key. Furthermore, fusionTAP could do what RSA can't do -- effortlessly perform whole-file ciphering in any size with unrivalled speed and security. So, unlike any block-cipher-based hybrid asymmetric cryptosystems we can find in the industry, fusionTAP might be the first-ever whole-file ciphering product with this 'super asymmetric power'.
Whole-file ciphering + asymmetric keys - it may seem not that big of a deal, but believe it or not, many things that we haven't seen before could emerge from this little technological breakthrough.
fusionTAP is very good at access control management. Compared to traditional encryptions, fusionTAP has one more dimension by design, with more factors to make overturning differences to the result of ciphering. fusionTAP is very good at access control management. Compared to traditional encryptions, fusionTAP has one more dimension by design, and in this additional dimension, more factors are put to determine the result of ciphering. To make our scheme effective, each factor must have the ability to bring the avalanche effect to the ciphertext. With the combination of those factors, the requirement of complicated access control in real life can be addressed with delicate but simple implementation.
To facilitate complicated access control requirements in real life, a new feature called "Hash Coin System" is under development right now. If you are interested in the use case of it, please see our blog The add-on called "Hash Coin System" is in development right now. If you are interested in the use case of it, please see our blog Anti-piracy and Hash Coin System
From the beginning, fusionTAP is not designed for the protection of information exchanged by random p2p connections or public networks, which SSL/TLS serve very well, nor all kinds of digital signatures. fusionTAP is born for exclusiveness. It focuses on protecting data possessed by individuals and businesses, or data shared within exclusive environments like groups or host-client services.
fusionTAP has made possible for a brand-new "Ciphered in Storage, Plain in Use" file ciphering scheme. It is based on the one-of-a-kind native asymmetric keys we have shown you above, and is for the first time implemented in the application level that is operatable for users. With the intuitive operations of the Cipher Manager and the Private Key Device, the discretion for ciphering and deciphering is handed back to the users. The solution can be a perfect blend of extra-high security and intuitive user experience.
fusionTAP, with its disruptive application potentials, will protect the digital properties and privacy for you and your companies in a way you never dreamed before:
Anytime, anywhere, you can turn your sensitive data into ciphertext in a fusionTAP-embedded cell phone with ease and have no worries about the risk of exposing the secret. The data can only be deciphered by the private key (could be a mini type-c USB stick that lies safely at home).
Messages Pics & videos in the album Contacts All kinds of files in storage Apps Digital assets Simple APIs & a chip-backed solution for app developers to realize in-depth fusionTAP implementation costlessly. With the help of the fusionTAP chip, content providers and vendors can effortlessly form an exclusive host-client environment to realize our radical copyright preservation scheme 
in their Apps.
No, it's always-ciphered everything for enterprises!
Enterprise data protection is a territory where fusionTAP can fully release its potential as both a cipher and an access management system. As with "transparent encryption", fusionTAP could provide a real stored-in-ciphertext-and-used-in-plaintext environment. In this environment, the employees can do CRUD and perform daily operations while the files they are accessing are in the state of ciphertext. But its working mechanism is much simpler than transparent encryption: no OS-level support is needed, nor application monitoring, nor whitelists, nor sandboxes. More importantly, it can do a lot of tricks that transparent encryption can't do:
We plan to provide a local rack mounted hardware version to deliver the service mentioned above for enterprises. We strongly believe that the best defense for enterprise data protection strategy is always local and hardware-deployed.
"Doors locked behind, data is locked as well, for the owner exclusively."
fusionTAP's pioneering solution has the potential to establish a new benchmark for user data collection in smart cars.
Get in touch
fusionTAP is fresh, both for you and for us. We are curious to see what its future would be like. Your valuable feedback is always welcome.
for top talent in tech
from all over the world!
Roundtable Knights 
