Simo ✔️
@david_chisnall I am not a certified cryptographer but adding error correction requires redundancy one way or another, so doing it after encryption is simpler and faster (hw can deal with it easily). Doing it as part of the cipher sounds like a recipe for a weak cipher and probably a good way to create side-channels that will quickly compromise the private key.
Do not recommend.
alcinnz
@simo5 @david_chisnall I have to think: If I have my history right, in the late 1980s we had miniaturized all the logic needed to read data from the laser-light reflected from a CD into a single microchip. Including strong error correction.
I'm sure we've refined our error correction techniques since then, & we certainly can fit even more into a microchip!
Marcus Müller
@alcinnz @simo5 @david_chisnall you'd be right, and none of the high speed interfaces that even get remotely close to 1 Tb/s do it without extensive error correction.
State of the art is that we correct errors, mostly using block codes with blocks as long as the requirements and medium permit.
Marcus Müller
@alcinnz @simo5 and @david_chisnall is also seeing the right problem there: the error correcting code decoders are usually pretty energy-hungry per payload bit, even as they are all specific silicon these days, because nobody can do 30 iterations of a giant graph message passing algorithm on frames far beyond 15000 bits in length in software.
I don't know how these decoders compare to an AES accelerator in power per bit, but my guess is that the fact alone that they are working1/2
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.