age/age.go

273 lines
8.9 KiB
Go
Raw Normal View History

// Copyright 2019 The age Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Package age implements file encryption according to the age-encryption.org/v1
// specification.
//
2025-05-10 12:59:20 +00:00
// 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
// use the filippo.io/age/agessh package.
//
2022-07-02 14:07:19 +00:00
// age encrypted files are binary and not malleable. For encoding them as text,
// use the filippo.io/age/armor package.
//
2023-08-05 17:19:26 +00:00
// # Key management
//
2022-07-02 14:07:19 +00:00
// age does not have a global keyring. Instead, since age keys are small,
2022-01-01 13:02:58 +00:00
// textual, and cheap, you are encouraged 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
// files can be parsed with ParseIdentities.
//
// 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.
//
2023-08-05 17:19:26 +00:00
// # Backwards compatibility
//
// Files encrypted with a stable version (not alpha, beta, or release candidate)
// of age, or with any v1.0.0 beta or release candidate, will decrypt with any
// later versions of the v1 API. This might change in v2, in which case v1 will
// be maintained with security fixes for compatibility with older files.
//
// If decrypting an older file poses a security risk, doing so might require an
// explicit opt-in in the API.
package age
import (
"crypto/hmac"
"crypto/rand"
"errors"
"fmt"
"io"
2023-08-05 17:19:26 +00:00
"sort"
"filippo.io/age/internal/format"
"filippo.io/age/internal/stream"
)
2025-05-10 12:59:20 +00:00
// An Identity is passed to [Decrypt] to unwrap an opaque file key from a
// recipient stanza. It can be for example a secret key like [X25519Identity], a
// plugin, or a custom implementation.
type Identity interface {
2025-05-10 12:59:20 +00:00
// Unwrap must return an error wrapping [ErrIncorrectIdentity] if none of
// the recipient stanzas match the identity, any other error will be
// considered fatal.
//
// Most age API users won't need to interact with this method directly, and
// should instead pass [Identity] implementations to [Decrypt].
Unwrap(stanzas []*Stanza) (fileKey []byte, err error)
}
2025-05-10 12:59:20 +00:00
// ErrIncorrectIdentity is returned by [Identity.Unwrap] if none of the
// recipient stanzas match the identity.
var ErrIncorrectIdentity = errors.New("incorrect identity for recipient block")
2025-05-10 12:59:20 +00:00
// A Recipient is passed to [Encrypt] to wrap an opaque file key to one or more
// recipient stanza(s). It can be for example a public key like [X25519Recipient],
// a plugin, or a custom implementation.
type Recipient interface {
2025-05-10 12:59:20 +00:00
// Most age API users won't need to interact with this method directly, and
// should instead pass [Recipient] implementations to [Encrypt].
Wrap(fileKey []byte) ([]*Stanza, error)
}
2025-05-10 12:59:20 +00:00
// RecipientWithLabels can be optionally implemented by a [Recipient], in which
// case [Encrypt] will use WrapWithLabels instead of [Recipient.Wrap].
2023-08-05 17:19:26 +00:00
//
// Encrypt will succeed only if the labels returned by all the recipients
// (assuming the empty set for those that don't implement RecipientWithLabels)
// are the same.
//
// This can be used to ensure a recipient is only used with other recipients
// with equivalent properties (for example by setting a "postquantum" label) or
// to ensure a recipient is always used alone (by returning a random label, for
// example to preserve its authentication properties).
type RecipientWithLabels interface {
WrapWithLabels(fileKey []byte) (s []*Stanza, labels []string, err error)
}
// A Stanza is a section of the age header that encapsulates the file key as
// encrypted to a specific recipient.
//
2025-05-10 12:59:20 +00:00
// Most age API users won't need to interact with this type directly, and should
// instead pass [Recipient] implementations to [Encrypt] and [Identity]
// implementations to [Decrypt].
type Stanza struct {
Type string
Args []string
Body []byte
}
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
// Encrypt encrypts a file to one or more recipients.
//
// 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.
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)
if _, err := rand.Read(fileKey); err != nil {
return nil, err
}
hdr := &format.Header{}
2023-08-05 17:19:26 +00:00
var labels []string
for i, r := range recipients {
2023-08-05 17:19:26 +00:00
stanzas, l, err := wrapWithLabels(r, fileKey)
if err != nil {
return nil, fmt.Errorf("failed to wrap key for recipient #%d: %v", i, err)
}
2023-08-05 17:19:26 +00:00
sort.Strings(l)
if i == 0 {
labels = l
} else if !slicesEqual(labels, l) {
return nil, fmt.Errorf("incompatible recipients")
}
for _, s := range stanzas {
hdr.Recipients = append(hdr.Recipients, (*format.Stanza)(s))
}
}
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)
if _, err := rand.Read(nonce); err != nil {
return nil, err
}
if _, err := dst.Write(nonce); err != nil {
return nil, fmt.Errorf("failed to write nonce: %v", err)
}
return stream.NewWriter(streamKey(fileKey, nonce), dst)
}
2023-08-05 17:19:26 +00:00
func wrapWithLabels(r Recipient, fileKey []byte) (s []*Stanza, labels []string, err error) {
if r, ok := r.(RecipientWithLabels); ok {
return r.WrapWithLabels(fileKey)
}
s, err = r.Wrap(fileKey)
return
}
func slicesEqual(s1, s2 []string) bool {
if len(s1) != len(s2) {
return false
}
for i := range s1 {
if s1[i] != s2[i] {
return false
}
}
return true
}
2025-05-10 12:59:20 +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
2025-05-10 12:59:20 +00:00
// calls it made. They all wrap [ErrIncorrectIdentity].
Errors []error
}
func (*NoIdentityMatchError) Error() string {
return "no identity matched any of the recipients"
}
// Decrypt decrypts a file encrypted to one or more identities.
//
// It returns a Reader reading the decrypted plaintext of the age file read
// from src. All identities will be tried until one successfully decrypts the file.
2025-05-10 12:59:20 +00:00
//
// If no identity matches the encrypted file, the returned error will be of type
// [NoIdentityMatchError].
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: %w", err)
}
stanzas := make([]*Stanza, 0, len(hdr.Recipients))
for _, s := range hdr.Recipients {
stanzas = append(stanzas, (*Stanza)(s))
}
errNoMatch := &NoIdentityMatchError{}
var fileKey []byte
for _, id := range identities {
fileKey, err = id.Unwrap(stanzas)
if errors.Is(err, ErrIncorrectIdentity) {
errNoMatch.Errors = append(errNoMatch.Errors, err)
continue
}
if err != nil {
return nil, err
}
break
}
if fileKey == nil {
return nil, errNoMatch
}
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)
if _, err := io.ReadFull(payload, nonce); err != nil {
return nil, fmt.Errorf("failed to read nonce: %w", err)
}
return stream.NewReader(streamKey(fileKey, nonce), payload)
}
// multiUnwrap is a helper that implements Identity.Unwrap in terms of a
// function that unwraps a single recipient stanza.
func multiUnwrap(unwrap func(*Stanza) ([]byte, error), stanzas []*Stanza) ([]byte, error) {
for _, s := range stanzas {
fileKey, err := unwrap(s)
if errors.Is(err, ErrIncorrectIdentity) {
// If we ever start returning something interesting wrapping
// ErrIncorrectIdentity, we should let it make its way up through
// Decrypt into NoIdentityMatchError.Errors.
continue
}
if err != nil {
return nil, err
}
return fileKey, nil
}
return nil, ErrIncorrectIdentity
}