
Age: A simple, modern and secure file encryption tool - nahikoa
https://github.com/FiloSottile/age
======
bscphil
This is great, it fills a gap that I've long defended as PGP's remaining
legitimate use case. Of course, now we just need to work on the adoption
problem. Despite the fact that PGP adoption is a well-known joke in itself,
all the tools designed to replace it (with the exception of the IM space) have
somehow managed to achieve even lower use rates.

It's been almost five years since Magic Wormhole first released, and about
half a year since that popular Latacora post recommended it for transferring
files, and said "Someone stick a Windows installer on a Go or Rust
implementation of Magic Wormhole right away". Guess what you're still not
going to find a reliable Windows build (let alone a GUI) for? Yep that's
right. Despite the fact that most of these projects come from a felt need for
better alternatives to PGP for the average user, very few of them have
actually come up with a product that's more accessible to the average person.

~~~
tptacek
There is now a solid Go implementation of `wormhole` (it's my daily wormhole
driver). It works on Windows. It just needs a UI.

Since PGP has almost no serious real-world adoption (search your feelings; you
know it to be true), it's wide open for replacement. People should use
`wormhole` for file transfer in preference to `age`-encrypted files, if the
only reason they're encrypting is to get the file safely across the wires.

~~~
bscphil
> it's wide open for replacement.

Totally agree there, but I'll remain skeptical until I actually see that
adoption start to happen. Certainly it's not going to until there's a nice
GUI. (It's kind of sad, actually. Wormhole has such a nice TUI that would be
utterly trivial to wrap in a simple QT interface or something.)

~~~
tptacek
Right? RIGHT? I keep saying: everyone I've ever taught `wormhole` to does the
same thing I did when 'lvh showed it to me: immediately and gleefully
wormholing everything. It's such a great tool; the good people of the world
deserve it.

It kills me that so many UI-type people build new encrypted email systems and
nobody works on putting solid UI on cool-kid crypto like `wormhole`. It's such
a high-impact project and it's missing exactly the skillset these people are
strongest with. I mean that sincerely: as I think is obvious to everyone,
crypto people can't do UI to save their lives.

~~~
nabla9
Do programs exist that generate the most basic portable GUI (in Qt for
example) from command line application?

Basically what you need is list of parameters, their types, allowed ranges,
preferred way to modify and input parameter values (file selection, input box,
slider, ...). Then button to run the program.

EDIT apparently there is
[https://github.com/chriskiehl/Gooey](https://github.com/chriskiehl/Gooey) for
Python.

EDIT2 Hmm. maybe fbs is good enough [https://build-
system.fman.io/](https://build-system.fman.io/)

------
nullc
NSA recommended people stop using ECC <384 bits
([https://apps.nsa.gov/iaarchive/programs/iad-
initiatives/cnsa...](https://apps.nsa.gov/iaarchive/programs/iad-
initiatives/cnsa-suite.cfm)).

There are applications where the extra time and space of something like ed448
present uncomfortable trade-offs.

File encryption is not generally one of those applications.

So I find this a little disappointing.

But I suppose that NIST PQ will finalize in the not far future and this will
get replaced by something that hybridizes with a PQ scheme. (I say replace
because the expectation that a pubkey is something you can easily copy and
paste doesn't really work with the PQ schemes you'd likely use with file
encryption.)

What happens if auth fails part way through the file? Do you get a truncated
decryption on stdout? -- or is this buffering the whole input in memory?

~~~
tptacek
It's linked right from the spec: it's a streaming AEAD construction, and
getting that is literally one of the motivations behind the tool. It does not
buffer the whole message in memory, or fail to detect truncation.

~~~
dependenttypes
I think that you misunderstood nullc's question. They are asking what happens
if at some point one of the poly1305 MACs in the file is incorrect. Not if
someone truncates the file.

~~~
nullc
We're talking about the same thing.

I saw that it used a streaming AEAD, but that's actually what inspired my
question.

Since (from the github page) it reads stdin, it can't two-pass the file.

So it _appears_ that if you hand it a file with midstream corruption it's
going to feed a truncated input down your pipeline.

That has consequences. They may well be less serious consequences than
buffering a potentially unlimited amount of data in memory :), but it's useful
to make the behavior very clear because it wouldn't require too advanced an
idiot to make something that was exploitable on this basis.

~~~
tptacek
It's Rogaway's STREAM scheme from
[https://eprint.iacr.org/2015/189.pdf](https://eprint.iacr.org/2015/189.pdf).
Are you pointing out a problem in the paper, or in some specific idiosyncrasy
you see of how it's implemented here? If so: what is it?

The AGL post the spec links to directly talks more generally about the high-
level strategy: you're buffering chunks of files. You're only ever releasing
authenticated plaintext. If you're piping to something processing plaintext
on-line, that thing might need to wait for the end-of-file signal before
processing or else potentially operate on a truncated file (by some integral
number of chunks). `age` is still just a Unix program.

~~~
nullc
My question was asking to confirm that it indeed will put out a truncated
output when given a mid-stream corrupted input (and that it doesn't do
something like buffer just to validate).

That behavior should be clearly documented, so that users can be advised that
their pipelines need to safely handle that case.

> that thing might need to wait for the end-of-file signal before processing
> or else potentially operate on a truncated file

Exactly. The docs should say this clearly, or someone will manage to create an
interesting vulnerability with it eventually. :)

Could go with a message the points out that encryption doesn't authenticate
the source-- which is a not uncommon misuse that shows up with PGP, where
people assume that the source is authentic if the input was encrypted, even
where no signature is used. (the fact that corrupted input gives an
"authentication failed" message might be particularly misleading)

~~~
tptacek
It's _streaming on-line encryption_. That's literally the point of streaming
encryption: not buffering whole messages. The rest of your point directly
follows from "not buffering whole messages".

~~~
nullc
Indeed. And the readme and the usage output makes no mention of streaming,
buffering, on-line, authentication, or anything related.

This is a potential security relevant behavior that most users-- who haven't
written or analyzed tools like this-- would find surprising.

For those following along, I went and tested it-- since the behavior wasn't
documented or clear from the code. If it encounters midstream corruption it
truncates the output, exits with a non-zero return and prints some error text
std stderr: "Error: chacha20poly1305: message authentication failed\n[ Did age
not do what you expected? Could an error be more useful? Tell us:
[https://filippo.io/age/report](https://filippo.io/age/report) ]"

If the input is truncated, it either does that-- or if the truncation is on a
block boundary it prints "Error: unexpected EOF\n[ Did age not do what you
expected? Could an error be more useful? Tell us:
[https://filippo.io/age/report](https://filippo.io/age/report) ]" instead.

It's not a problem, but it should be documented.

~~~
mike_hock
This is a security footgun and a vulnerability waiting to happen, but bash is
at fault, not age. age does the best it can do (while maintaining O(1) memory
requirement) by exiting non-zero, but the shell swallows that if it's in the
middle of a pipeline.

~~~
labawi
IMHO it's not that bad. It's actually quite usable, and reasonably easy to
handle safely.

Use

    
    
      bash: set -eu -o pipefail
      # unfortunately pipefail is not POSIX
    

and some care when writing scripts. Possibly decrypt to a file first.

A proper and likely footgun would be decrypting and passing tainted plaintext
and only then exiting nonzero. E.g.

    
    
      decrypt < file | sh  # owned
    

Definitely should be documented either way.

~~~
mike_hock
I agree with all of what you said.

The footgun you described can still happen if there's a verification error
somewhere in the middle. You could still conceivably craft exploits using only
truncation of the plaintext, depending on the situation.

No one _should_ "decrypt < file | sh" (or anything | sh without verifying),
but they will. Doesn't matter if we have POSIX or non-POSIX shell flags that
can fix it, the defaults are bad.

There's nothing tools like age can do about that, though.

Edit: I was thinking more along the lines of

    
    
        if decrypt < file | postprocess > tempfile
        then
            sh tempfile
        fi
    

where postprocess exits zero. This is where the default shell behavior fails.
The "decrypt < file | sh" antipattern is something not even the shell can do
anything about.

~~~
labawi
> No one should "decrypt < file | sh" (or anything | sh without verifying)

I was thinking of self-prepared scripts, tooling or owner controller
distribution. Decrypt+good signature is precisely what I want.

Anyway, as nmadden pointed out, age does not provide source authentication
_duh_. AFAIU that means, all the streaming semantics and blockwise AEAD are
practically useless, unless you are using the password encryption, which is
helpfully blocked from automation.

------
CodesInChaos
Some questions about the spec:

1\. How does age disambiguate between filenames and other key formats for the
-r argument? (Those formats are also valid filenames)

2\. Does the header use normal Base64 (i.e. +/) or url-safe Base64 (i.e. -_).
The specification sounds like normal Base64, but some lines of the example
contain -_ others contain +.

3\. What characters are allowed in the header? ASCII only? (the current key-
formats are ASCII only, but an implementation is supposed to skip unknown
formats)

4\. Are any characters forbidden in recipient types, arguments and additional
lines?

5\. Which strings at the beginning of a header line have special meaning and
thus are illegal for additional lines? Only `-> ` and `--- `? I assume the
space is mandatory in those strings despite the spec not mentioning that for
`->`?

6\. CRLF normalization of the header is only mentioned in the section about
ascii-armored files. I assume it also applies to non ASCII armored files?

7\. Is keeping the public key secret to achieve symmetric authenticated
encryption an officially supported/recommended use-case?

(If the public key is public, the MACs block decryption oracles. However they
don't provide any authentication, because the message isn't bound to any
sender and thus an attacker can just encrypt their own message to your public
key. If the receiver's public key is secret, this isn't possible and thus the
current implementation provides symmetric sender authentication)

8\. How does the command line tool signal failure/truncation/corruption?

~~~
str4d
Answering what I can. Where something is an implementation detail, I'm
referring to rage (which I'm obviously more familiar with).

1\. rage tests arguments for validity as filepaths, and uses the file
preferentially over treating the argument itself as a recipient format.

2\. The header uses normal Base64. This was changed recently, and the examples
likely need updating.

3\. rage currently rejects unknown formats; I haven't implemented this part of
the spec yet.

4\. Based on the current contents of the age specification, it looks like
limiting to standard Base64 characters is consistent.

5\. Additional lines all need to be standard Base64 characters (i.e.
consistent with the format of current recipient lines) if implementations are
going to be able to skip unknown formats.

(Recipient lines are currently under-specified in the spec. I opened
[https://github.com/FiloSottile/age/issues/9](https://github.com/FiloSottile/age/issues/9)
a while back for addressing this.)

6\. The normalization notes are an artifact of an earlier ASCII armoring
format. Now that the armor is (a strict subset of) PEM, there is no need for
CRLF normalization, as the age format solely uses LF, and PEM (which can
tolerate either) is only a wrapper around the age format and thus does not
affect the header.

8\. rage signals this via an I/O error in the library that will bubble up
through std::io::copy; this amounts to truncation on a chunk boundary and a
non-zero exit value.

------
nmadden
Is there a detailed description of the security goals and crypto rationale
anywhere?

For example, it seems that if you use scrypt then you get fully authenticated
encryption: the message must have come from somebody who knows the password
(either a trusted user or you chose a weak password). But if you use X25519
then the scheme used is ECIES, so no sender authentication, only IND-CCA
security.

The format document says that if you want “signing“ then use minisign/signify,
but I suspect most people want _origin authentication_. We know that it is
actually quite hard to obtain public key authenticated encryption [1] from
generic composition of signatures and encryption, with many subtle details. It
would be better if age supported this directly for X25519 as it does for
scrypt. Unfortunately, you can’t simply use a static key pair to achieve this
(as in nacl’s box) as age uses a zero nonce to encrypt the file key with
chacha20-poly1305 so reusing a static key will result in nonce reuse. (This
seems a bit fragile).

[1]: [https://eprint.iacr.org/2001/079](https://eprint.iacr.org/2001/079)

~~~
nmadden
An example of why I think this is important. Adam Langley’s post that is
linked from the spec [1] talks about cases where people want to do things
like:

    
    
        decrypt file | tar xz
    

Elsewhere in these comments somebody also mentioned the case of

    
    
        decrypt file | sh
    

Presumably the whole point of implementing the STREAM online AEAD mode is to
support these kinds of cases; only releasing chunks of plaintext after
verification.

But these use-cases are only secure in age when using the scrypt decryption
option or if you have first verified a signature over the entire age-encrypted
archive (killing the streaming use-case). The reason is that the X25519 age
variant provides no sender authentication at all, and so an attacker doesn’t
need to tamper with the archive: they can just generate their own ephemeral
key pair and replace the entire thing with data of their choosing. Age has no
way of detecting such an attack.

You absolutely need origin/sender authentication built directly into the tool
to handle these cases securely.

[1]:
[https://www.imperialviolet.org/2014/06/27/streamingencryptio...](https://www.imperialviolet.org/2014/06/27/streamingencryption.html)

~~~
nmadden
I wrote up some more detailed notes here:
[https://neilmadden.blog/2019/12/30/a-few-comments-on-
age/](https://neilmadden.blog/2019/12/30/a-few-comments-on-age/)

------
tialaramex
"it looks like we'll be ok" remains their status on the problem of whether
it's fine to just take SSH keys and use them for something quite different.

That's just not good enough. It was fine in early drafts because there was
hope they'd remember that "Solve all of the world's problems" was not their
goal, and so SSH keys might be irrelevant in later revisions anyway. It's not
fine in something intended to actually ship.

Either get somebody to put lots of work in to verify that yes, it's definitely
safe to do this as SSH stands today, and contact SecSH WG or Sec Dispatch or
whoever to make sure they know you're doing this now - or, as seems much more
likely, rip out all the SSH key code and highlight that line about how you
don't want to do key distribution in age because it's hard.

PGP is full of things its creators thought might be safe that you now have to
tell people not to do because it turns out they're unsafe. This tool should
not recapitulate their mistake.

~~~
FiloSottile
I am fairly confident the SSH key reuse is fine, or I wouldn't have shipped
it. But yes, it would be a misrepresentation to say there are formal proofs of
it. There's no one I can think of that we can pay in short order to make
robust ones. FWIW, we don't really have proofs for ECDSA either, and it's been
almost 30 years. (Anyway, the core age flow with native keys is unaffected.)

------
est31
Rust implementation:
[https://github.com/str4d/rage](https://github.com/str4d/rage)

~~~
AgentME
Ooh, the included "rage-mount" utility allows mounting an age-encrypted zip or
tar file as a directory. (It can be installed with `cargo install --features
mount age`.)

------
_paulc
This looks really good, I've used ccrypt (#1) for years as a simple Unix-y
encryption tool to avoid the complexity of GPG (though this is symmetric
encryption only so you need to have a secure way to exchange keys).

I just added a pull-request to allow the recipients flag to also be specified
as a [https://](https://) or file:// URL - this is mostly useful to use the
GitHub <user>.keys endpoint to grab user keys eg.

    
    
      ./age -a -r https://github.com/<user>.keys < secret
    

will encrypt using <user>'s GitHub SSH public keys.

#1 [http://ccrypt.sourceforge.net](http://ccrypt.sourceforge.net)

#2
[https://github.com/FiloSottile/age/pull/43](https://github.com/FiloSottile/age/pull/43)

------
kick
Not that it matters, but age hasn't hit 1.0 yet. (Close, though!)

With that in mind, it's still really exciting. I can't wait until I never have
to use GPG ever, ever again.

~~~
hnews_account_1
Can I ask a question that I've never been able to answer by Googling?
Kleopatra is the tool of choice for GUI based GPG / PGP stuff on Windows
right? So why is it that literally any software I download, it cannot locate
the keys on any online database including MIT and whatever else are the top
keystores online.

If those keystores are not being regularly updated by trusted data vendors,
how am I supposed to trust Gpg signed stuff? It isn't like SHA where I just
need to compare 2 hashes.

I'd shift to command line tools if I knew that the protocol was being widely
used effectively.

~~~
AgentME
Not everyone uploads their PGP keys to keyservers. Also, keyservers don't
verify the ownership of the keys uploaded to them. You're supposed to import
the signer's public key first.

~~~
hnews_account_1
Yes that's the other choice right? But then if I'm going to a compromised
website with no idea that a MITM attack is taking place, I'd download the
wrong public key wouldn't I? In that scenario, why is it trusted more than
something much simpler like SHA? Is it just because it doesn't need a hash
calculation?

So the larger question is, how do I verify ownership of a medium level
distributed file? Like not tens of millions of users who host mirrors etc so
that everything is cross checkable. But not like a 10 downloads a month
software either.

------
lilyball
What problem is this solving that isn't already done by other tools?

~~~
tptacek
This is like the engine underneath PGP, but modernized and with the
misfeatures stripped out. You'd use it, instead of PGP (which is bad) for
encrypting files, and as a building block for the operational tools that
really are just straightforwardly encrypting files (ie: not messaging, which
has its own distinct needs and has purpose-built cryptosystems for).

More on this: [https://latacora.micro.blog/2019/07/16/the-pgp-
problem.html](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html)

~~~
tzs
From the linked blog:

> A Swiss Army knife does a bunch of things, all of them poorly.

Counterexample: the Phillips head screwdriver in my Swiss Army knife is
actually the best Phillips head I've ever found. It can easily turn without
slipping a wider range of screw head diameters and depths than any other
screwdriver I've used.

(Does anyone else have way more screwdrivers around than they can explain? I
cannot think of any reason I would own more than two or three full sized screw
drivers, and one set of small of jewelers screwdrivers...but I've got more
than a dozen full sized ones and a couple sets of jewelers screwdrivers. I
cannot remember buying, inheriting, finding, stealing, borrowing and not
returning, or being gifted _any_ of them--but there they are. Glitch in the
matrix?)

~~~
xxs
One thing about the Phillips screw driver - perhaps it's Pozidriv[0] type,
that's compatible with Phillips but different/better.

"Phillips" was originally designed to slip to prevent over-tighten. One more
PH. screwdrivers come in various sizes (read the listed article for more).
Using the correct one works significantly better for: flat/ph/pz, etc. For
stuff like torx is not even possible to use incorrect screwdriver. Last
screwdriver quality greatly varies, with some brands being exceptionally
expensive or even pride material to own.

[0]:
[https://en.wikipedia.org/wiki/List_of_screw_drives#Pozidriv](https://en.wikipedia.org/wiki/List_of_screw_drives#Pozidriv)

------
Kovah
Age looks somewhat promising, but I am still looking for a reasonable
alternative to TrueCrypt. Encryption should be as easy as possible. The
process of gathering your files (plural!), put them into a folder, zip or tar
that folder and then encrypt it, to delete the remaining files afterwards, is
anything but not easy. Adding new files is even more horrible. TrueCrypt was
so easy, just select the encrypted file, enter your password and voila, you
got a volume mounted where you can easily add or remove many files. I know
that Veracrypt exists, but it does not feel like a solution for the next
decade(s).

Its super weird. There is this use case to de/encrypt a single file, but mass
storage of files in a secure way and without a proprietary protocol seems
impossible.

~~~
TeddyDD
There are nice solutions on Linux: luks (encrypting partitions) and cryfs
(encrypting directories)

~~~
eikenberry
There is also gocryptfs. It is written by some of the same people who did
encfs and attempts to fix all the security issues discovered during its years
of use.

[https://github.com/rfjakob/gocryptfs](https://github.com/rfjakob/gocryptfs)

------
ur-whale
This is neat. A quick browse through the code, looks like it uses DJB's chacha
and polyxxx underneath.

I've been waiting for a worthy replacement for "crypt" for a very long time,
and gpg, while it can be coaxed into doing that with much effort has simply
become a bloated abomination at this point.

Hope this gets vetted by the crypto community and gains popularity.

~~~
tptacek
Not that I disagree but just a quick note that Filippo is very much a part of
the cryptographic community.

------
monoideism
So the modern alternative would be this for file encryption, and signify for
signing. What's the consensus on an alternative for GPG authenticating?

And what are the expert opinions on themis:
[https://github.com/cossacklabs/themis](https://github.com/cossacklabs/themis)
?

~~~
tptacek
Themis looks like a more complicated take on libsodium, which is already the
de facto standard modern crypto library. I'd use that instead.

------
stutonk
I once made something similar after reading a blog post here on HN [1] just to
see how easy it is to make something like this. Mine [2] uses passphrases to
generate keys with the Argon2 algorithm and then uses NaCl's secretbox for
encryption. I also made a version for use on streams. It's not up to snuff for
industrial use, but it's really easy to use if you just want to encrypt some
files with a password and also very simple if you want to modify it for your
own purposes.

[1] [https://blog.gtank.cc/modern-alternatives-to-
pgp/](https://blog.gtank.cc/modern-alternatives-to-pgp/)

[2]
[https://stutonk.github.io/crypt.html](https://stutonk.github.io/crypt.html)

------
badrabbit
We need a protocol/scheme that other things can adopt much more than a tool.
There will always be a reason why someone can't use a tool,but with an
encoding/scheme/protocol you can push for different things to use it.

To give an example, I was in a work situation more than once where an external
party wanted to transfer files to or from our company and I was suppose to
help find a standard tool/method. The only (and I mean only) way right now is
pgp due to it's ubiquity with s/mime on email being second. We do need great
tools like this but we need them to where if I can't use it due to
license,policy,etc... Issues i can use a separate compatible tool.

So, My only suggestion to the author is to please make a fixed and versioned
standard out of the scheme.

~~~
tptacek
A protocol for what? To send messages securely? We have that. To do
deduplicated mass backup? That exists, too. To securely transfer files? We
have that as well. Each of these problems makes their own demands on
cryptography and deserves their own purpose-built cryptosystem, which is why
Signal looks like Signal, and not a naive message bus over which we push PGP-
encrypted records.

The point of `age` is that when you subtract out all these use cases from PGP
and leave just the file encryption problem, PGP still sucks, and sucks way out
of proportion to how complicated file encryption is.

So instead of bringing all of PGP's bloat, 1990s cryptography, and misfeatures
to bear on that simple problem, we just get a simple, modern tool optimized
for that one problem.

~~~
jonahx
> The point of `age` is that when you subtract out all these use cases from
> PGP and leave just the file encryption problem, PGP still sucks, and sucks
> way out of proportion to how complicated file encryption is.

For clarity: Is this an endorsement of `age`?

~~~
tptacek
`age` is awesome. We wrote something almost identical to `age` internally at
Latacora that has some features `age` doesn't have (encrypting optionally to
KMS keys, and managing encrypted DMGs), and I'm going to kill that tool off
and add those features to a local fork of `age` instead.

------
cies
A tool/protocol is as secure as the people using it.

I found that when working with non-techies that 7Zip is an acceptable
encryption tool. It used proper encryption, it's open source, available on all
platforms, available with GUI and CLI.

~~~
fanf2
That’s no good if you need public key encryption

~~~
cies
Asymmetric encryption is hard for non-techies.

------
Boulth
> Out of scope:

> The web of trust, or key distribution really

Is there anything in the tptacek suite of replacement tools for this? Like
Keybase but fully open source and/or decentralized?

------
zodiakzz
For encrypting text files, I just use vim's `:X` command and enter a pass
phrase. Simple, easy, portable, works everywhere. I have configured my .vimrc
to `set cryptmethod=blowfish2` and disable backup/swap files for encrypted
files. Are there any issues with this? Is there any other option that will
work on virtually all UNIX devices without installing anything additional?

~~~
tptacek
It's so weird hearing what people are doing instead of PGP, and how bad it is.
I had no idea vim even had this feature, but from what I've discovered in
about 3 minutes of Googling, vim's "blowfish2" is the 64-bit-block Blowfish
cipher in unauthenticated CFB mode. Just awful: Blowfish is weak, and
attackers can manipulate the ciphertext of your files. This is why you want
`age`.

~~~
CiPHPerCoder
Trying to unfuck vim's encryption spawned a very interesting Github thread, if
anyone is interested:
[https://github.com/vim/vim/issues/638](https://github.com/vim/vim/issues/638)

~~~
bscphil
Welp, I'm switching to neovim.

------
joshbaptiste
I normally use scrypt (with passphrase) for file encryption for personal
backups.. age isn't competing with this use case i take it?

------
est31
I'm not a big fan of tools that take encrypted data, and decrypt it by
creating a decrypted file on disk. They give you a false sense of security.
Files, even if they get deleted, remain on hard disks. On SSDs they are even
harder to remove, as there is a complicated layer of indirection. Even if you
shred the file before deletion, it's possible that it will keep being stored
by the SSD, maybe even permanently if a block containing the decrypted content
is being decomissioned.

The classical gpg based tools have this very same problem. The classical
response is to suggest ramdisk usage, ideally for the entire OS (like a live
system basically) to avoid getting artifacts onto the disk like clipboard
history, cached thumbnails, or log files. pass for example uses such ramdisks.
I disagree that this is a good solution though. Of course it is more thorough,
but it requires additional intervention/setup, and not everyone has the needed
expertise. Instead, I think the encryption tool itself should take care to
only store the decrypted content in non-paged RAM, and give users read/write
access through a GUI or a TUI. It should be a ready downloadable solution,
similar to the TOR browser bundle. The TOR browser is also trying to not put
anything onto the hard disk.

~~~
baby
What’s the point of decrypting a binary (non-text) file and not putting it on
disk? What if I have to open it with photoshop?

~~~
est31
The functionality should either be built into the OS, or into Photoshop.
Photoshop should support decryption of the file on the fly. It should best be
paired with a "private" mode where it stores nothing about your activities
(most programs store some artifacts of your behaviour e.g. vlc stores last
opened files or kate stores which line you last edited or something like
that).

~~~
baby
> be built into the OS, or into Photoshop

You're already setting yourself up for failure here, there's no way every
single tool you're using will integrate encryption in them.

I agree that the OS should do better, but unfortunately that is not the world
we live in at the moment so user tools are what is needed.

------
labawi
So.. this is using chunked AEAD, without source authentication/signing?

What's the actual use case, and why is it any better than plain stream
encryption? If you wish to stream authenticated decrypted contents, it would
mean 2 layers of chunking.

------
todotask
Is age designed to encrypt large binary files, which seem to increase the file
size by 2KB.

~~~
str4d
Yes. age encrypts large files in 64 kiB chunks with 16 bytes of overhead per
chunk, which strikes a balance between file size overhead and performance
(particularly when seeking).

~~~
todotask
That's interesting and seem to be an alternative to encrypted zip or 7z which
could be used in productions?

------
john_alan
Which crypto primitives does this tool use? x25519+chacha?

~~~
dependenttypes
\+ poly1305 + scrypt

------
tedunangst
Finally! :)

------
galaxyLogic
How can we know there's no backdoor in it?

~~~
pknopf
It's OSS?

~~~
coldtea
Yeah. So all you need is a 10+ year experience in crypto algorithms and weeks
of close inspection of the code to verify it!

~~~
smrq
Sooo you need to trust someone that does have that experience to do the
verification. What alternative are you suggesting? Is there some cool way to
write your crypto so that a layman can successfully verify the integrity of a
binary?

~~~
galaxyLogic
> What alternative are you suggesting?

One solution might be if some big corporation or even a government, or why not
Bill Gates himself, offered a big ongoing bug-bounty for this Open Source
Software.

------
TedDoesntTalk
meh.

[https://stackoverflow.com/questions/16056135/how-to-use-
open...](https://stackoverflow.com/questions/16056135/how-to-use-openssl-to-
encrypt-decrypt-files/16056298#16056298)

With that I'm guaranteed AES, a known-good encryption algorithm. I have no
idea what these guys are doing without reading through their documentation.
Hopefully they didn't roll their own.

~~~
tptacek
That command line doesn't even produce authenticated ciphertext. I'm amazed
that's the check-marked best answer on Stack Overflow.

~~~
wolf550e
I have seen many questions on security stack exchange and /r/crypto where the
correct answer should have been "use age", but because it didn't exist the
correct answer was something bad. openssl CLI is not meant to be used in prod
(both because not AEAD and because the man page tells you not to use it). gpg
is bad. rolling your own CLI tool using libsodium is not for everyone.

~~~
tptacek
[https://twitter.com/pwnallthethings/status/12107355525357527...](https://twitter.com/pwnallthethings/status/1210735552535752705)

I'd be nicer but for the "hopefully they didn't roll their own" at the end.

~~~
TedDoesntTalk
It's possible this is the wrong way to get AES on the command-line; I haven't
done it and no need to right now. But that's missing my point entirely.

~~~
coldtea
The point being?

You've linked to a command that's wrong, from a random internet "everybody
gets to answer a question and everybody gets to vote for the best answer, no
qualifications required" website, and wrote "with that I'm guaranteed AES, a
known-good encryption algorithm" as if that means anything.

