In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is not smaller than the message being sent. In this technique, a plaintext is paired with a random secret key (also referred to as a one-time pad). Then, each bit or character of the plaintext is encrypted by combining it with the corresponding bit or character from the pad using modular addition (XOR).  

Incrypteon uses the concepts defined in the One Time Pad, but we utilise our patented approved “Entropy Augmentation” algorithm to extend the length of the initial key to match the length of the message, thus removing one of the main limitations of a OTP.  We remove the secure key distribution problem, by using a secure aPAKE (asymmetric authenticated key exchange).  

We achieve the following 4 conditions:

• The key is as at least as long as the plaintext message to be encrypted
• The key is random, using our patented random number entropy stream
• The key is never reused
• The key is kept completely secret within the library

Once you’ve registered on the website, you will follow some simple instructions to create your first Incrypteon “Application”.  Once you’ve created your “Application” you will be provided a set of credentials that can be deployed in each “Node” that you utilise our SDK.  The SDK allows you to perform cryptographic methods on your data, including encryption, decryption, hashing, signing and verification of messages.

Each application you create provides a set credentials that can be used in your code to encrypt and decrypt data, as well as other features that are available in our SDK.  You might choose to utilise the same “Application” across all of your products, or you might choose to utilise different “Applications” across each of your products and services, giving you more granular control over access to credentials, as well as the analytics for that “Application”.

A “Node” is how we describe a unit of deployment ie, where our SDK is used in your code to encrypt and decrypt data you send.  This could be anything from a console app, to a server less function in the cloud and everything in between.  We’ve built Incrypteon to support many scenarios from client side to server side, client to client side and server to server side.  Indeed, a “Node” could be a device or an app, or it could be part of embedded code in your smart home or car.  We are excited to see what else a “Node” could be!

We currently support C# dotnet core SDK that works on Windows, Mac and Linux.  We have plans to build out libraries for Java, C, C++, Go, Java, Node, PHP, Python and Ruby.  

Our underlying crypto system is based on a solution that delivers both Quantum Secure & AI secure encryption, delivering the worlds first, and currently only solution that delivers Perfect Secrecy, in a way that supports all use cases where you can deploy an application.

Equivocation is the term that Shannon used to mathematically measure the security of a cryptosystem. It is a logarithmic index of the number of unique valid messages / keys under a brute-force attack.  It is conditional entropy.

As a practical example – you are given a pack of 52 cards – a standard deck. The search condition is that the card you are looking for is a queen. No matter how fast you are – infinite time and resources – you will find 4 queens, but still not know which of the 4 queens it is. Such a system has a security index rating (conditional entropy, or equivocation) of 2, since 4 is 2 to the power of 2.  With 2 packs, there will be 8 queens and the equivocation (security rating) will be 3.  Four packs will get equivocation of 4, eight packs will get you equivocation of 5.

The point is, that equivocation – which was defined in 1949by Claude Shannon, is the definitive measure of security. It is not the amount of time to conduct a search, but the total number of valid results which determine the security of a system.

Current cryptographic schemes where messages are longer than keys, have no security, and are therefore insecure by definition.

Yes absolutely, we follow the same principles of Absolute Secrecy to ensure we offer a solution that delivers encryption for data at rest, as well as data in transit.  We support multiple architecture patterns and are looking to expand this further over time.  

In addition to encryption, we can also support message signing and verification, meaning we can support the full suite of Post Quantum secure requirements in a single solution, making it easier for developers and organisations to secure their data in a consistent way.