The cr.yp.to microblog: 2022.08.30 03:44:24

2022.08.30 03:44:24 (1564428794219208704) from Daniel J. Bernstein, replying to "BenBE (@BenBE1987)" (1564225876597809153):

Would be interesting to look at speed of known techniques for RS decoding in this context. I think ~1 cycle/byte for extended Hamming (with current portable software) is fast enough to slip in unnoticed for tons of data, but something slower is probably broadly affordable too.

Context

2022.08.29 13:25:45 (1564212707745665027) from Daniel J. Bernstein:

Given the current reality of desktops/laptops/smartphones almost never having ECC RAM, I'd love to see more operating-system support for periodically sweeping through pages to detect and correct errors, storing (say) 14 bytes of error-correction data for each 4096-byte page.

2022.08.29 13:30:41 (1564213947359793153) from "BenBE (@BenBE1987)":

What gives this number of 14 bytes? What error correction capability does this aim for? Where does it stem from? Why not use cross-interleaving for larger blocks of memory (of e.g. 1MiB)?

2022.08.29 13:52:00 (1564219310259679232) from Daniel J. Bernstein, replying to "BenBE (@BenBE1987)" (1564213947359793153):

4096+14 is what libsecded (from https://pqsrc.cr.yp.to/downloads.html) does for 4096 bytes. Can de-interleave into original page + checksums. It's SECDED on the bottom bit of each byte, SECDED on the next bit of each byte, etc. Mixing bits can give better error correction for the same space.

2022.08.29 14:18:05 (1564225876597809153) from "BenBE (@BenBE1987)":

Sounds reasonable to go with Hamming codes. Wondered if using RS instead could be viable (hence the question re interleaving similar to ISO/IEC 10149 / ECMA-130).