USE AGE FOR ENCRYPTION

Generate key-pair (i.e. "identity")

    $ age-keygen -o key.txt
    > Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

    # recorver pubkey from private key (if not already annotated in key.txt)
    $ age-keygen -y key.txt

    # protect the identity file with passphrase (age will detect this when using)
    $ age -e -p < key.txt > key.age && rm key.txt

    # Or us SSH keys
    $ man ssh-keygen

Encryption

    $ tar -cvz DATA | age -r ${recipient pub key}  > data.tar.gz.age

    # With SSH keys
    $ age [...] -R ~/.ssh/public_key -o [...]

    # symmetric encryption
    $ age -p < data.tar.gz > data.tar.gz.age

Decryption

    $ age --decrypt -i ${path_to_key} -o data.tar.gz data.tar.gz.age

    # with SSH key
    $ age [...] -i ~/.ssh/private_key [...]

    # may also redirect output
    $ age --decrypt -i ${path_to_key} data.tar.gz.age > data.tar.gz
    $ age --decrypt -i ${path_to_key} data.tar.gz.age | tar -xzv

    # when used on symmetrically encrypted file, age will ask for passphrase

Quick Notes

    -e / --encrypt                  Do encryption
    -d / --decrypt                  Do decryption
    -r / --recipient=PUBKEY         Specify a recipient (inlined string)
    -R / --recipients-file=PATH     Specify recipients listed in file
    -p / --passphrase               Do symmetric encryption with passphrase
    -a / --armor                    ANSI armored output
    -i / --identity=PATH            Path to the identity file. When used with
                                    encryption, the identity is also used as a
                                    recipient. (-e must be explicit)
    -o / --output=PATH              same as > FILE indirect

-i / --identity format options:

    a. Plaintext file containing age identity (generated via age-keygen)
    b. A passphrase encrypted file, as above.
    c. An SSH private key file
    d. "-" read from standarf input

Security

    If attacker has access to both your encrypted files and yoru age pubkey,
    they can replace the whole data.

    If you want the files strictly encrypted to _YOURSELF_ perhaps consider
    symmetric encryption.

    consider storing also the hash.


Appendix (?) File integrity and authentication

    First understand what attacker vector you worry about:

    a.  for file integrity (against hazards) it would suffice to put the hash
        alongside the encrytped archive

        [data.age	data.age.sha256]    [pubkey]    [priv key]
        ----------------------------    -------     --------
        safe but not hazard resilient    public      safe

    b.  if your pubkey (identity) is public, attacker could REPLACE your
        encrypted file (and produce a new hash). i.e. you have no idea who
        created the encrypted file. Therefore you need a signature.

        [data.age   data.age.sig]       [pubkey]    [priv/sign key]
        ------------------------         -------    ---------------
        untrusted and not resilient       public     safe

    b.1 if you are using SSH keys for age, you could reuse your SSH key for
        signature. (Also checkout signify). However this approach means you
        need to distribute your keypair wherever the encryption(signing) is
        performed. This leads to a very different problem.

    b.2 or, don't make your public key public; hence you effectively have a
        symmetric encryption

        [data.age   data.age.sig]       [pub/priv key, or symm key]
        ------------------------        ---------------------------
        untrusted and not resilient         safe

    c.  Keep the file hashes at a different place (like somewhere safe).

        [data.tar.gz.age]               [data.tar.gz.sha256]
        -----------------               --------------------
        untrusted and not resilient         safe


Trick(s)

    # don't do this
    $ cat FILE | age [...]

    # do this
    $ age [...] << FILE

    they both feed FILE content into age standard input, the later saves you one
    process (cat) and the IPC (pipe)