Author: Russell O'Connor 2018-01-17 15:28:15
Published on: 2018-01-17T15:28:15+00:00
The email begins with the sender stating that there is no similarity between SSS and RSA or any other public-key or symmetric crypto, as SSS is effectively a one-time pad and is information-theoretically secure. Additionally, using error correcting codes and truncated hash functions create identical amounts of information theoretic redundancy, so there cannot be a problem with SSS. The sender reiterates that SSS is "information-theoretically secure" and it is impossible to break SSS. The recipient of the email had raised concerns about the entropy argument and the sender responds by explaining that the rule of thumb which says it is safer plaintext to have low redundancy is based on Shannon's information theory and is an application of a precautionary principle. However, there are some examples of cryptographic attacks which may be considered as a consequence of the breach of the rule. For example, given RSA ciphertext of two plaintexts x and a*x + b, where a, b are known, it's possible to effectively compute x provided public exponent is three. From the information-theoretic point of view, the second message is redundant because it's determined by the first one. The sender considers that there's no use in applying the precautionary principle against impossible attacks, especially at the cost of losing the useful properties of a real error correcting codes that would provide actual guarantees against likely errors. Moreover, there is a considerable similarity between RSA and SSS. Both schemes are algebraically-based (rather than boolean function based). CRCs (and error-correcting codes generally) introduce redundancy into the message. The redundancy is induced by a linear relationship among messages. Related Message Attack wouldn't be possible if you had two plaintexts x and hash(x). To sum it up, there is a precautionary principle which tells us not to increase redundancy of a message unless it is introduced in a complicated way (for example by a hash function). That's why we use SHA rather than CRC. One more reason why we stick to the principle is that there's no randomisation in our scheme (such as padding or initialisation vector). We understood advantages of error-correctings codes over hash functions (minimal codewords distance property, performance) and we considered it thoroughly.
Updated on: 2023-06-12T23:33:41.476533+00:00