It's possible to craft ChaCha20Poly1305 ciphertexts that decrypt under
multiple keys. (I know, it's wild.)
The impact is different for different recipients, but in general only
applies to Chosen Ciphertext Attacks against online decryption oracles:
* With the scrypt recipient, it lets the attacker make a recipient
stanza that decrypts with multiple passwords, speeding up a bruteforce
in terms of oracle queries (but not scrypt work, which can be
precomputed) to logN by binary search.
Limiting the ciphertext size limits the keys to two, which makes this
acceptable: it's a loss of only one bit of security in a scenario
(online decryption oracles) that is not recommended.
* With the X25519 recipient, it lets the attacker search for accepted
public keys without using multiple recipient stanzas in the message.
That lets the attacker bypass the 20 recipients limit (which was not
actually intended to defend against deanonymization attacks).
This is not really in the threat model for age: we make no attempt to
provide anonymity in an online CCA scenario.
Anyway, limiting the keys to two by enforcing short ciphertexts
mitigates the attack: it only lets the attacker test 40 keys per
message instead of 20.
* With the ssh-ed25519 recipient, the attack should be irrelevant, since
the recipient stanza includes a 32-bit hash of the public key, making
it decidedly not anonymous.
Also to avoid breaking the abstraction in the agessh package, we don't
mitigate the attack for this recipient, but we document the lack of
anonymity.
This was reported by Paul Grubbs in the context of the upcoming paper
"Partitioning Oracle Attacks", USENIX Security 2021 (to appear), by
Julia Len, Paul Grubbs, and Thomas Ristenpart.
Move the SSH recipient types out of the main package to declutter the
godoc. This also allows us to drop the x/crypto/ssh build dependency
entirely from the age package import tree.
The caller can take care of the armor. For consistency move the
responsibility to close the armor to the caller, and make the stream
Writer not propagate Close.
This also will also allow us to spin the armor implementation out into
its won package that imports format, without getting an import loop from
format.Parse magically invoking armor decoding.
Less magic in the API, more magic in the CLI.
Since Homebrew now works on linux (https://docs.brew.sh/Homebrew-on-Linux), you can use the same installation steps for Linux as you would for macOS. I tested this on Ubuntu 19.10.
This way every recipient is labeled with the version.
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IHNjcnlwdCBSbmw2ellyQ1VFK25rVkwx
TkF0SklnIDE4CjlZL2RKb2FOcjFrM0MwSVZqS1BzMUFLeVF5Y1RaMEwvQlRLMWwv
Q0xJbEEKLS0tIEJ1STZCbFh5Vjdsam5nSEFGTVZUY1BxcVVIek04ZUVrOGR4L3ph
NkYzS28KucY25ejFefMDMtKvsAEofDQLsYF41NPrSPITpoxuVWMMZ1ldm+lDh09q
RzCIZAhLN8jaqdeVdCEutqiniJ/9qv4=
-----END AGE ENCRYPTED FILE-----
Password: lies
It's with a heavy heart that I admit using the ASCII header as part of
the armor was clever, and you know what we think about being clever
around here.
Still, PEM is so lax, we target a subset without headers, and without
garbage before and after the markers.
-----BEGIN AGE ENCRYPTED FILE-----
VGhpcyBpcyBhIGZpbGUgZW5jcnlwdGVkIHdpdGggYWdlLXRvb2wuY29tLCB2ZXJz
aW9uIDEKLT4gWDI1NTE5IGozWWtNTWtaVGNDc0tKVGtMN29aam9NT2FUaGpBTVdU
Y1k5ZHVNdWJhUlkKb0F5d2N4ZW1lSTM1SkZiWHIxcHRFWW0rMjNzK3RuOTg1OHpN
L0ZkVzNCTQotLS0gQWZqdXFFaXNhbmYxbGpPRVZsSS9QM0wyM0RrTHRWWElsQnFu
ejFmRW4zdwq1FMc+yjVJBDuBUZSPMi0nCAtELIObQOHHQlQnvhk6BCITceOD5DbN
S7b6oumB8i/hEJvTtsOLgTBofzqzB90iAQ==
-----END AGE ENCRYPTED FILE-----
AGE-SECRET-KEY-1Y77J4M9R7GEKMZHR6YFDLDWV74VK2YQV4C7SR2H7SSVVJ05HQS4Q7NNMS3
