Apparently it's a standard that Google is pushing to replace RC4 and already is using for HTTPS between google.com and Android.
If arc catches on I'm curious if it could support inline operations. E.g. on a 100gb+ archive can I read the tar index without decrypting the entire archive first, can I extract a single file? The ChaCha algorithm is a streaming cipher, which as I understand suggests that I cannot do operations like that.
Even worse now that I'm thinking about this, if my archive has a bit error early in the file does that mean the entire archive cannot be decrypted. Maybe for long term storage I'm better off physically securing my archives than encrypting them to avoid bit rot ruining everything.
Just have more copies on more/diverse media. Encrypted backups (with authenticated encryption) have the pleasant side effect of validating the backup on restore.
With highly specialized requirements comes highly specialized solutions.
However the tape reader/recorder will probably not last that long. These things need special care (don't forget the cleaning tape every other month) and can act a little weird when the mechanical parts wear down (or even before in many cases).
The Ultrium LTO standard states that a tape recorder for version N must read/write N-1 and read N-2. Given that there is a new version around every 3 years, it gives you around 10 years of strong guaranty on your capacity to actually recover your data.
To properly manage data on a longer period you need to migrate the data to a new media. In fact, the problem then became mostly organizational.
That said, authentication of a ciphertext is, in many ways, as important as encryption. So you would need to design the archive format in such a way that individual files' contents could be authenticated and decrypted on the whole, instead of authenticating the contents of the entire archive.
gpg-zip --symmetric --gpg-args --cipher-algo=AES256 --output backup.tar.gpg file1 file2 file3Other than that the "modern" version of it is .tar.xz.
Or can I just point arc to SSH/SFTP and the server can be "dumb" ?
"2. You may use the Tarsnap client code for the sole purpose of accessing the service."
[0]: https://github.com/wg/arc/blob/cdd799359b6f7050fc5e3aa128bf1...
[1]: https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0...