Thank you for your feedback. The website we present to you is designed to explain and advocate the innovating ciphering tech we have been working for. And the demo shown in the video is just one of the applications on top of it. I am sure you have noticed that, although this application has a lot of similarities to the On-The-Fly Encryption known by us for years, it surely has some very distinct flavors. As a matter of fact, the application is based upon a native asymmetric scheme for whole-file ciphering, which is fundamentally different from almost every encryption scheme the market provides. Traditional On-The-Fly Encryption is based on symmetric key encryption and no matter how the scheme varies the secret key can never be handed over to the users. In our scheme, users, with the private keys in their hands, have full control over the files they want to protect, and we made a lot of efforts to make the operation for ciphering/deciphering smooth enough for users’ daily use. We all know that it is usually painful and error-prone for the users without tech background to directly handle file encryption, so we either handle everything in the background (like TLS protocol, transparent encryption), or offer them password-based encryption (which is absolutely a huge downgrade of security). Our aim is to offer an uncompromised, highest-level approach for every user, with or without tech background, to protect their valued data with their own hands.

Is this going to be supported on all OSes?

- Yes, it is going to be supported on all OSes. We are working on an iOS version of fusionTAP recently.

Do you intend to allow for cli/pragmatic processes?

- Yes. As fusionTAP is a chip-based solution, we will open full API to developers who will develop apps based on the chip-embedded device (pc, mobile phone, digital cameras etc.). A CLI will also be offered in the future. We hope to see more interesting applications upon this ciphering tech in the future.

How do you intend on handling sharing of encrypted data between team members?

- This will be an important feature of fusionTAP. In our design, a host can form an exclusive group by generating a new key pair and sharing them with other group users. But owning the key pair doesn’t grant the group users a lifetime membership, as fusionTAP is more complicated than a simple pub-key encryption system, the host can still control the group users with an add-on called Hash Coin System (under development). More interestingly, the host can decide when the group starts, when the group ends, if a file shared is burn-after-read and etc. You may check the following link for more details:
https://www.fusiontap.com/blogs/2/antipiracy-hashcoinsystem

What happens when i lose my physical key?

- During the initialization process, there will also be a back-up physical device, which can restore the secret key, pub-key and other parameters fusionTAP required. The user should put this back-up device some where safe in case they lost their secret key. However, if you lose this back-up device as well, that’s it. This will be the same case as you forget your password and everything that can be used to restore the password.

- One thing worth mentioning is that the usb-device in the demo is just one basic example to convey the concept of “handing over the key to the users”, but there can be a variety of forms for the physical key. It can be a nfc card, a smart bracelet or even a nano chip planted inside your body. In the next version of fusionTAP, we will make the Apple Watch as a secret key storing device and demonstrate how it can work with gestures and provide seamless experience with the iPhone.

Does this consume an entire disk device, can partitions be used? What about virtual filesystems?

- fusionTAP is NOT a file-based encryption where files are encrypted on the filesystem level (we avoid calling fusionTAP “encryption”, because fusionTAP is based on tokenization, which is a cryptographically different methodology. ). It is implemented on the application level where the users can easily reach and operate. The ciphering request is initiated by the user and executed by the application. So, fusionTAP doesn't rely on the support of file systems generally.

Has this been put through a security evaluation? Wheres the stats?

Security is absolutely the core for any serious cryptography, and we put a lot of efforts to make fusionTAP secure. What kind of security evaluation do you prefer to see? As far as we know, there is no convenient benchmark tools to make security evaluations for an innovative cryptographic system. There are surely some standards and rules for cryptographers to evaluate if a ciphertext or cryptographic system is secure. We have done a lot of evaluations on different levels. By now, we can share the following aspects for the security evaluation of fusionTAP:

- The brute possibility mentioned on the website is a representation of the algorithm strength. The said 2^2656 of fusionTAP indicates the difficulty for the adversary to restore plaintext from ciphertext. Please be noted that this kind of security is equal to AES with 2656-bit key.

- We have done evaluations in semantic security, CPA security and CCA security, which you may find on the website. These are key standards in cryptography to test if a cryptographic method/scheme is secure.

- As for the security of the asymmetric key scheme (this is not mentioned on the website): the difficulty is always to create an effective isolation between the pub key and the private key. In the realm of number theory for cryptography, RSA may be the only setting that can naturally achieve this goal but is unfortunately not applicable to our project. ECC is not applicable to our project too, for its inability to actually encrypt anything. Our goal is to find a solution that can provide both the solid pub key/private key isolation and the fastest exponentiation (to be specific, the exponentiation of a 2048-bit base to the power of 256-bit random number must be done within 0.2 milliseconds in normal implementations.). After some painful and involved research and tests, we create a chip-based scheme to satisfy these two requirements at the same time. In this scheme,

1. The pub key and N will be protected inside the chip, so it is almost impossible for the attacker to know them in the first place.

2. If the pub key and N is by any chance exposed, anyone who want to figure out the private key from the pub key in Zn must face the discrete logarithm problem.

Thank you again for your comment. We will try our best to answer all your questions and formalize them together into a Q&A page on the website.