Feature request: seekable decryption API

[danderson]

I'd like to use age as the cryptographic layer of tape backup software I'm writing. The on-tape format would be roughly a sequence of age(index), age(tar(files...)), .... Tape as a medium is relatively slow to read and seek, but for recovering a small number of files, tactical seeking is preferable to reading and discarding terabytes of irrelevant data.

AFAICT from the spec, the bulk of age ciphertext is seekable, thanks to STREAM chopping the input into independent blocks. So, I'd like to propose exposing that seekability in the age Go API.

Rough proposal: no change to the API structure, but if the io.Reader passed to Decrypt implements io.Seeker, then the io.Reader returned by Decrypt also implements io.Seeker. Seeking to decrypted bytes has at most 1 STREAM chunk of overhead (have to read+decrypt the entire block even for 1 byte of plaintext).

Would y'all be open to a PR that implements this?

Alternatives considered: for my format, I could also flip the nesting around and store tar(age(file), age(file), ...), but that would leave the tar headers in unauthenticated plaintext, and leak a lot more metadata (file count, file size, ...). I could also obviously use some scheme other than age, but age's nice and seems to hit all the things I need.

[str4d]

For reference, here is where I implement seeking over age streams in my Rust implementation: https://github.com/str4d/rage/blob/456ce707f6db01f2f953c9e22c058964f3437795/age/src/primitives/stream.rs#L503-L642

In particular, note that a couple of seeking situations require knowing the length of the plaintext, and that needs to be authenticated by trial-decrypting the last chunk with the last flag set to true. I didn't handle this correctly prior to age 0.6.0.

[danderson]

Thanks, good info. That would make seek-from-eof impractical on tape, because seeking to EOF and back would be very costly - but afaict that work only needs to happen for whence=EOF, so BOF and relative seeks could still happen without requiring additional I/O beyond over-reading for the initial post-seek block.

EDIT: I say "impractical", but I mean more "quite expensive because of the medium's properties, but not really surprising to users".