Q: Can you explain AtomBeam’s built-in security? Is that referring only to the obfuscation of sending compressed data, or is your software also encrypting the transmitted data? If so, are you using standard encryption, or have you made any innovations in developing more lightweight encryption and decryption algorithms for IoT use?
A: Yes. Our chief scientist, Josh Cooper, who is a mathematician and professor at the University of South Carolina, is glad to answer these. Here is his response:
AtomBeam, if viewed through the lens of cryptography, effectively uses an enormous “block cipher” cryptosystem to encode data. In a block cipher, fixed blocks of data are replaced with another binary string according to some set of rules. Some of the strongest and most standardized cryptosystems in use today are block ciphers. Key to the security benefits conferred by the use of such algorithms is the difficulty of inverting the function E which maps input blocks to the corresponding output blocks. This difficulty is generally ensured by the use of a “key” which determines which mapping function E is used. Without the key, an intruder or eavesdropper cannot compute the inverse function D of the encryption function E; but, since the key is symmetric, i.e., secretly shared by the two communication endpoints, the sender and receiver can decode messages. An attacker could only deduce the key (and thus break the cryptographic privacy/security of the system) via difficult and costly computation, usually by observing many plain-text-cipher-text pairs and trying an enormous number of possible keys. The difficulty of the problem of extracting keys is ensured by the use of functions E which are believed to be hard to invert because of widely-believed conjectures about computational hardness in theoretical computer science (mostly stemming from the conjectural falsity of the so-called “P = NP” statement).
In many computational settings, however, users are unable or unwilling to apply the costly operations involved just to compute E and D even with a known key. These operations, while much easier than cracking keys, still incur significant computational overhead, power consumption, and latency. Use cases with very small, inexpensive, low-power, reduced-instruction-set chips will find applying AES or similar cryptographic transformations prohibitive. Therefore, data is frequently sent unencrypted when it is generated or handled by such lightweight devices, presenting an enormous security hazard, both in terms of the privacy of the data being transmitted and the possibility of adversaries interfering with operations.
AtomBeam offers a middle road between unencrypted data transmission and costly hardened cryptosystems. Effectively, when considered as a cryptographic protocol, AtomBeam is a block cipher with the codebook as its key. This codebook is usually very high in entropy, because it was trained on a huge amount of hard-to-predict private data and is obtained by a complicated set of transformations. Unlike modern cryptosystems, whose keys have a few hundred bits of entropy (i.e., unpredictable/random bits of information), the AtomBeam codebook usually contains thousands or millions of bits of entropy. Without this key, it is not possible to decode/decrypt data which has been encoded using AtomBeam. However, unlike classical cryptosystems, the functions E and D which use this key readily reveal information about it if an attacker is able to observe or guess the plaintext (pre-encoded data) or inject their own. This is because the set of all sourceblock—code-word pairs is almost the entire key (sourceblocks are our term for data patterns, which are paired in codebooks to code words). Nonetheless, the amount of information observed with each transmission is very small compared to the entropy of the codebook, so this unraveling of privacy will be painfully slow. Furthermore, information obtained thusly is nearly useless on all but the exact data previously observed during eavesdropping, because the entropy of the “key” is spread throughout sourceblock—code-word pairs and is mostly not shared between them. That is, the user, by observing that sourceblock S is encoded as code-word C would be able to deduce that future occurrences of C correspond to the original data S, but they will not generally be able to use this information to decode any other code-words C’. This contrasts with classical encryption schemes, where learning the key breaks the security of the entire system. Thus, AtomBeam trades-off strict susceptibility to attack for a much more graceful degradation of privacy/security, all the while requiring substantially less computing power to perform. Indeed, the cryptographic properties of AtomBeam are already available to beneficiaries of its data-reduction and other features at no additional cost.