Open ErikBjare opened 7 years ago
Another comment may be to use as different ciphers as possible to minimise the risk that a new fancy attacks breaks all ciphers involved, e.g. by using one block cipher and one stream cipher to maximise diversity in the cipher selection.
This is similar how it's done e.g. in the 3GPP specifications, which is the base for encryption and integrity algorithms in UMTS (3G) and LTE (4G). (They don't use both ciphers simultaneously though, but rather negotiate to use one of them). However they include two different ones in the standard - one block cipher and one stream cipher - so that it is unlikely that a new attack will render both ciphers in the specification insecure.
First off: I really like this idea. I've thought about it in the past but never started working on it due to fears that AES might be broken in the coming decades. (I currently use git-annex with encrypted remotes instead)
Basically: Freely distributed backups can be dangerous if the data should be protected for a longer period of time.
Some encryption software, such as Veracrypt (previously Truecrypt), enables the user to compose encryption functions such as AES, Serpent and Twofish (AES finalists). This could vastly improve security in case weaknesses are found in AES.
Basically, encryption would work like this:
(Sorry if this isn't valid Go, it's been a while)