2019-10-07 03:16:20 +00:00
|
|
|
// Copyright 2019 Google LLC
|
|
|
|
|
//
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file or at
|
|
|
|
|
// https://developers.google.com/open-source/licenses/bsd
|
|
|
|
|
|
2020-06-28 00:36:02 +00:00
|
|
|
// Package age implements file encryption according to the age-encryption.org/v1
|
|
|
|
|
// specification.
|
|
|
|
|
//
|
|
|
|
|
// For most use cases, use the Encrypt and Decrypt functions with
|
|
|
|
|
// X25519Recipient and X25519Identity. If passphrase encryption is required, use
|
|
|
|
|
// ScryptRecipient and ScryptIdentity. For compatibility with existing SSH keys
|
2020-06-28 03:47:17 +00:00
|
|
|
// use the filippo.io/age/agessh package.
|
2020-06-28 00:36:02 +00:00
|
|
|
//
|
2020-09-20 10:17:15 +00:00
|
|
|
// Age encrypted files are binary and not malleable. For encoding them as text,
|
2020-06-28 01:08:42 +00:00
|
|
|
// use the filippo.io/age/armor package.
|
2020-09-20 10:17:15 +00:00
|
|
|
//
|
|
|
|
|
// Key management
|
|
|
|
|
//
|
|
|
|
|
// Age does not have a global keyring. Instead, since age keys are small,
|
|
|
|
|
// textual, and cheap, you are encoraged to generate dedicated keys for each
|
|
|
|
|
// task and application.
|
|
|
|
|
//
|
|
|
|
|
// Recipient public keys can be passed around as command line flags and in
|
|
|
|
|
// config files, while secret keys should be stored in dedicated files, through
|
|
|
|
|
// secret management systems, or as environment variables.
|
|
|
|
|
//
|
|
|
|
|
// There is no default path for age keys. Instead, they should be stored at
|
|
|
|
|
// application-specific paths. The CLI supports files where private keys are
|
|
|
|
|
// listed one per line, ignoring empty lines and lines starting with "#". These
|
2020-09-20 10:42:43 +00:00
|
|
|
// files can be parsed with ParseIdentities.
|
2020-09-20 10:17:15 +00:00
|
|
|
//
|
|
|
|
|
// When integrating age into a new system, it's recommended that you only
|
|
|
|
|
// support X25519 keys, and not SSH keys. The latter are supported for manual
|
|
|
|
|
// encryption operations. If you need to tie into existing key management
|
|
|
|
|
// infrastructure, you might want to consider implementing your own Recipient
|
|
|
|
|
// and Identity.
|
2019-10-07 01:19:04 +00:00
|
|
|
package age
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"crypto/hmac"
|
|
|
|
|
"crypto/rand"
|
|
|
|
|
"errors"
|
|
|
|
|
"fmt"
|
|
|
|
|
"io"
|
|
|
|
|
|
2019-12-07 04:00:57 +00:00
|
|
|
"filippo.io/age/internal/format"
|
|
|
|
|
"filippo.io/age/internal/stream"
|
2019-10-07 01:19:04 +00:00
|
|
|
)
|
|
|
|
|
|
2020-05-18 06:53:37 +00:00
|
|
|
// An Identity is a private key or other value that can decrypt an opaque file
|
|
|
|
|
// key from a recipient stanza.
|
|
|
|
|
//
|
2021-01-17 11:09:07 +00:00
|
|
|
// Unwrap must return an error wrapping ErrIncorrectIdentity for recipient
|
|
|
|
|
// stanzas that don't match the identity, any other error will be considered
|
|
|
|
|
// fatal.
|
2019-10-07 01:19:04 +00:00
|
|
|
type Identity interface {
|
2020-06-27 23:44:26 +00:00
|
|
|
Unwrap(block *Stanza) (fileKey []byte, err error)
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
|
2019-11-25 00:15:53 +00:00
|
|
|
var ErrIncorrectIdentity = errors.New("incorrect identity for recipient block")
|
|
|
|
|
|
2020-05-18 06:53:37 +00:00
|
|
|
// A Recipient is a public key or other value that can encrypt an opaque file
|
|
|
|
|
// key to a recipient stanza.
|
2019-10-07 01:19:04 +00:00
|
|
|
type Recipient interface {
|
2020-06-27 23:44:26 +00:00
|
|
|
Wrap(fileKey []byte) (*Stanza, error)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// A Stanza is a section of the age header that encapsulates the file key as
|
|
|
|
|
// encrypted to a specific recipient.
|
|
|
|
|
type Stanza struct {
|
|
|
|
|
Type string
|
|
|
|
|
Args []string
|
|
|
|
|
Body []byte
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
|
age: mitigate multi-key attacks on ChaCha20Poly1305
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.
2020-09-19 16:18:59 +00:00
|
|
|
const fileKeySize = 16
|
|
|
|
|
const streamNonceSize = 16
|
|
|
|
|
|
2020-09-20 10:42:43 +00:00
|
|
|
// Encrypt encrypts a file to one or more recipients.
|
2020-05-18 06:53:37 +00:00
|
|
|
//
|
2020-09-20 10:42:43 +00:00
|
|
|
// Writes to the returned WriteCloser are encrypted and written to dst as an age
|
|
|
|
|
// file. Every recipient will be able to decrypt the file.
|
|
|
|
|
//
|
|
|
|
|
// The caller must call Close on the WriteCloser when done for the last chunk to
|
|
|
|
|
// be encrypted and flushed to dst.
|
2019-10-07 01:19:04 +00:00
|
|
|
func Encrypt(dst io.Writer, recipients ...Recipient) (io.WriteCloser, error) {
|
|
|
|
|
if len(recipients) == 0 {
|
|
|
|
|
return nil, errors.New("no recipients specified")
|
|
|
|
|
}
|
|
|
|
|
|
age: mitigate multi-key attacks on ChaCha20Poly1305
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.
2020-09-19 16:18:59 +00:00
|
|
|
fileKey := make([]byte, fileKeySize)
|
2019-10-07 01:19:04 +00:00
|
|
|
if _, err := rand.Read(fileKey); err != nil {
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-26 16:53:15 +00:00
|
|
|
hdr := &format.Header{}
|
2019-10-07 01:19:04 +00:00
|
|
|
for i, r := range recipients {
|
|
|
|
|
block, err := r.Wrap(fileKey)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to wrap key for recipient #%d: %v", i, err)
|
|
|
|
|
}
|
2020-06-27 23:44:26 +00:00
|
|
|
hdr.Recipients = append(hdr.Recipients, (*format.Stanza)(block))
|
age: remove Type method from Recipient and Identity interfaces
The Type() method was a mistake, as proven by the fact that I can remove
it without losing any functionality. It gives special meaning to the
"0th argument" of recipient stanzas, when actually it should be left up
to Recipient implementations to make their own stanzas recognizable to
their Identity counterparts.
More importantly, there are totally reasonable Identity (and probably
Recipient) implementations that don't know their own stanza type in
advance. For example, a proxy plugin.
Concretely, it was only used to special-case "scrypt" recipients, and to
skip invoking Unwrap. The former can be done based on the returned
recipient stanza, and the latter is best avoided entirely: the Identity
should start by looking at the stanza and returning ErrIncorrectIdentity
if it's of the wrong type.
This is a breaking API change. However, we are still in beta, and none
of the public downstreams look like they would be affected, as they only
use Recipient and Identity implementations from this package, they only
use them with the interfaces defined in this package, and they don't
directly use the Type() method.
2021-01-04 00:08:42 +00:00
|
|
|
|
|
|
|
|
if block.Type == "scrypt" && len(recipients) != 1 {
|
|
|
|
|
return nil, errors.New("an scrypt recipient must be the only one")
|
|
|
|
|
}
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
if mac, err := headerMAC(fileKey, hdr); err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to compute header MAC: %v", err)
|
|
|
|
|
} else {
|
|
|
|
|
hdr.MAC = mac
|
|
|
|
|
}
|
|
|
|
|
if err := hdr.Marshal(dst); err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to write header: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
age: mitigate multi-key attacks on ChaCha20Poly1305
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.
2020-09-19 16:18:59 +00:00
|
|
|
nonce := make([]byte, streamNonceSize)
|
2019-10-07 01:19:04 +00:00
|
|
|
if _, err := rand.Read(nonce); err != nil {
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
2019-12-26 16:53:15 +00:00
|
|
|
if _, err := dst.Write(nonce); err != nil {
|
2019-10-07 01:19:04 +00:00
|
|
|
return nil, fmt.Errorf("failed to write nonce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-26 16:53:15 +00:00
|
|
|
return stream.NewWriter(streamKey(fileKey, nonce), dst)
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
|
2021-01-17 11:09:07 +00:00
|
|
|
// NoIdentityMatchError is returned by Decrypt when none of the supplied
|
|
|
|
|
// identities match the encrypted file.
|
|
|
|
|
type NoIdentityMatchError struct {
|
|
|
|
|
// Errors is a slice of all the errors returned to Decrypt by the Unwrap
|
|
|
|
|
// calls it made. They all wrap ErrIncorrectIdentity.
|
|
|
|
|
Errors []error
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (*NoIdentityMatchError) Error() string {
|
|
|
|
|
return "no identity matched any of the recipients"
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-20 10:42:43 +00:00
|
|
|
// Decrypt decrypts a file encrypted to one or more identities.
|
|
|
|
|
//
|
|
|
|
|
// It returns a Reader reading the decrypted plaintext of the age file read
|
2020-05-18 06:53:37 +00:00
|
|
|
// from src. All identities will be tried until one successfully decrypts the file.
|
2019-10-07 01:19:04 +00:00
|
|
|
func Decrypt(src io.Reader, identities ...Identity) (io.Reader, error) {
|
|
|
|
|
if len(identities) == 0 {
|
|
|
|
|
return nil, errors.New("no identities specified")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hdr, payload, err := format.Parse(src)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to read header: %v", err)
|
|
|
|
|
}
|
|
|
|
|
if len(hdr.Recipients) > 20 {
|
|
|
|
|
return nil, errors.New("too many recipients")
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-17 11:09:07 +00:00
|
|
|
errNoMatch := &NoIdentityMatchError{}
|
2019-10-07 01:19:04 +00:00
|
|
|
var fileKey []byte
|
|
|
|
|
RecipientsLoop:
|
|
|
|
|
for _, r := range hdr.Recipients {
|
|
|
|
|
if r.Type == "scrypt" && len(hdr.Recipients) != 1 {
|
|
|
|
|
return nil, errors.New("an scrypt recipient must be the only one")
|
|
|
|
|
}
|
|
|
|
|
for _, i := range identities {
|
2020-06-27 23:44:26 +00:00
|
|
|
fileKey, err = i.Unwrap((*Stanza)(r))
|
2021-01-04 15:56:22 +00:00
|
|
|
if errors.Is(err, ErrIncorrectIdentity) {
|
2021-01-17 11:09:07 +00:00
|
|
|
errNoMatch.Errors = append(errNoMatch.Errors, err)
|
2021-01-04 15:56:22 +00:00
|
|
|
continue
|
|
|
|
|
}
|
2019-11-25 00:15:53 +00:00
|
|
|
if err != nil {
|
|
|
|
|
return nil, err
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
2019-11-25 00:15:53 +00:00
|
|
|
|
|
|
|
|
break RecipientsLoop
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if fileKey == nil {
|
2021-01-17 11:09:07 +00:00
|
|
|
return nil, errNoMatch
|
2019-10-07 01:19:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if mac, err := headerMAC(fileKey, hdr); err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to compute header MAC: %v", err)
|
|
|
|
|
} else if !hmac.Equal(mac, hdr.MAC) {
|
|
|
|
|
return nil, errors.New("bad header MAC")
|
|
|
|
|
}
|
|
|
|
|
|
age: mitigate multi-key attacks on ChaCha20Poly1305
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.
2020-09-19 16:18:59 +00:00
|
|
|
nonce := make([]byte, streamNonceSize)
|
2019-10-07 01:19:04 +00:00
|
|
|
if _, err := io.ReadFull(payload, nonce); err != nil {
|
|
|
|
|
return nil, fmt.Errorf("failed to read nonce: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return stream.NewReader(streamKey(fileKey, nonce), payload)
|
|
|
|
|
}
|