In Error Correction OR Cryptography :

Concatenated Coding is always more secure and more reliable

(and, in some circumstances can be in the Analogue Domain)




Abstract
For some bizarre reason, neither Cryptographers nor those involved with Error Correction theory have failed to notice the obvious -- Concatenated Coding is necessary to make Error Correction systems work and Cryptographic systems actually be secure.

Without going into too great a detail, Concatenated Coding allows one coding system to cover up the failures of another coding system. No coding system can ever be perfect as no perfect coding system has yet been found.

An important theorem that has been proven in both Cryptography and Information Theory is this :

COMPRESSION EQUALS ENCRYPTION, with respect to the fact that both functions remove the redundancy in data ... albeit it is understood that it is assumed that only one step is used in both cases.

Concatenation in Compression and Encryption has a different grammatical meaning.

The Compression = Encryption theorem makes it possible to prove -- with Information Theoretical certainty -- that Concatenated Error Correction Coding and Concatenated Encryption are "Information Theoretical" reliable.


Mechanics

The Error Correction & Cryptography analogues

Plaintext (P) --> [CY code A(P)] --> [CY  code B(A(P))] --> {Transmission}

Data (D) --> [EC code K(D)] --> [EC code L(K(D))] --> {Transmission}
The corollary : Data = Plaintext, because CY = EC.


However, if one were to statistically observe

Signal and Plaintext recovery and its limits

With respect to concatenated Cryptography


Classical Examples (Failures to implement 2 layers of Encryption : IP Telephony)

Almost universally "Consumer Grade" IP Telephony has had a history of poor implementations of cryptography. Several research papers written since 2000 have uncovered the ability to recover spoken words over supposedly secure IP telephony systems. Consumer grade IP telephony almost exclusively uses SINGLE STAGE ENCRYPTION.

IP Telephony, at lower bitrates (4 kbs to 16 kbs) implements some Vocal (aka Vocoder) or Phycoacoustical model for encoding the Audio. Vocoders typically output very stereotypical data during silence and equally stereotypical data with respect to people speaking very stereotypical words.

The only way to get around the VOIP low bitrate encoding defect is to collect large blocks of VOIP packet data and encrypt it with at least 256 bit keys. The larger the number of VOIP packets encoded at once the better, as it seems to help with the encoding entropy. The cryptography fix does work somewhat deeply in the lower OSI layers of VOIP so it is not easy for many people to understand. 

However Single Stage VOIP Encryption is technoloigcally moot since the mid-2000s, and a security risk since the 2010s. Single state VOIP encryption may be fast, but it underuses the CPU hardware avalable to it. Modern IP encoders can do 2 stage encryption (Encoding and Decoding) with only a ~1% change in the delay times under normal conditions, based on the current hardware [and drivers and encoders] existent in the 2015s.

Phycoacoustical encoders are less terrible at having sterotypical outputs during slience or sterotypical words, but some encoders are worse at this than others. The main detriment to Phycoacousitcal encoders are slient passages [when there is no "low level backgound noise"] that create some entropy to encode.

A Hybrid (Analog + Digital) Workaround :

By using a Digital Implimentation of an Analog Voice Scrambler, it is possible to get aound the Single Stage Cryptography defect in current VOIP. There are several hardware open source audio scramblers that would be adiquate to keeping the encoded audio secure. This is one of the few cases when Analog Scrambling + Digital Encryption can work together to form a robust 2 layer encryption system.


Classical Examples (Error Correction practices mirroring Cryptography Practices)

Galileo Spacecraft

The Galileo spacecraft was launched in October 1989, to investigate Jupiter and its moons. The baseline plan for communication utilized a prime link via X-band, 4.8-m high-gain antenna (HGA), as well as two backup links through S-band, low-gain antennas (LGA). Galileo’s data rate through the prime link, at Jupiter range, would have been as high as 134.4 Kbits/s.

After the HGA deployment failed, JPL faced the challenge of implementing a science-rich mission with a LGA at data rates of 10-20 bits/s, almost four orders of magnitude less than originally planned for the HGA supported mission. A JPL study in late 1991 led to a successful integrated program that included reprogramming of the spacecraft, development of new ground equipment, and some radical changes in the operational concepts.

The cumulative effect of all the changes was to recover almost 2 orders of magnitude more data. Additional reordering of science priorities led to recovery of almost 70% of the science objectives. On May 23, 1996, Galileo has switched to its updated software and has been communicating with the upgraded DSN ever since in this mode, returning fascinating data from 10, Ganymede, Europa, Callisto, and Jupiter itself.

... (3.5) Use of “fill” data.

At times. At times, link analysis indicated that even with the DGT operating properly, a break in the data recovery is expected, e.g. due to high spacecraft dynamics. In these cases, Galileo inserts frames of uncompressed “fill” data with lower or no value, to assure that even if this
secondary data is lost, the loss will not be magnified and hamper the recovery of the primary data.

... (3.9) Improved Error-correcting coding.

The error-correcting coding for the mission is a 4-redundancy (255, n) R/S code concatenated with a (14,1/4) convolutional code. The total coding gain is 1.3 dB compared to the CCSDS standard [Voyager] coding : (7,1/2) convolutional code concatenated with a (255,223) R/S code.





References

Error Correction Theory

Cryptography

Error Correction (applications)

Cryptography (applications)






Created by

Initial Idea

Initial Version

Last Revised

Version
Last Revision

Revision State


Max Power

19 September 2013

19 September 2013

30 September 2014

0.18
Add IP Telephony

Revisable, Final