Aren't age's public-key and passphrase encryption the same from the key's security requirements standpoint, when more than confidentiality is required?

[luczsoma]

Hi there,

I'm a happy age user, encrypting backups and other sensitive files with passphrases. I'd like to start a discussion about the following use case, hoping it would be a fruitful one: Alice sends an asymmetrically encrypted file to Bob.

The use case and its required security

Let's consider a common use case where Alice (A) wants to send a file (M as in Message) to Bob (B) with the following security guarantees:

• S1 (Confidentiality): The content of M is confidential against third parties (“secret”, i.e., cannot be read).
• S2 (Integrity): The content of M is integrity-protected against third parties (“authenticated”, i.e., cannot be modified).
• S3 (Sender identity verification): B can verify for himself that the received M was sent by A (but does not need to prove this to third parties).
• S4 (Receiver identity verification): A can verify for herself that M is being sent indeed to B (but does not need to prove this to third parties).

So, B generates an age key pair specifically for the purpose of receiving this one file from A, and sends his public key PK to A by some means. A encrypts M with PK, sends M to B, then B decrypts M with his secret key SK.

How age helps achieving the security guarantees above

S1 (Confidentiality)

The content of M is confidential against third parties (“secret, i.e., cannot be read by third parties”).

✔️ This is achieved, as long as B is the only one knowing the SK whose PK was used for encrypting M: age cryptographically guarantees that only B can read M.

S2 (Integrity)

The content of M is integrity-protected against third parties (“authenticated, i.e., cannot be modified”).

✔️ (❌ not by age itself) This is achieved as well, as long as A and B are the only ones knowing PK that was used for encrypting M: age cryptographically guarantees, that the file was not modified (replaced), as the input key material used to deriving the file's encryption key includes PK (see a question about the “why?” on this below).

S3 (Sender identity verification)

B can verify for himself that the received M was sent by A (but does not need to prove this to third parties).

✔️ (❌ not by age itself) This is where it gets shaky. As age is an encryption tool, not an authentication tool, so this isn't even included in its security target, but this is achieved the same way as S2.

S4 (Receiver identity verification)

A can verify for herself that M is being sent indeed to B (but does not need to prove this to third parties).

✔️ (not by age itself ❌) By itself, age does not help with this (but why should it?). Thus, when acquiring PK, A needs to make sure on its own that PK indeed belongs to B. But since A needs to acquire PK in a secret, integrity-protected, and identity-verified way from B whatsoever, she can make sure during this procedure about the identity of B.

Wait, isn't keeping PK secret basically the same as Bob forwarding a secret key to Alice?

So, to summarize, PK needs to be kept secret by both parties, and it should be acquired by A in a secret (i.e., confidential, i.e., encrypted) AND integrity-protected AND identity-verified (i.e., A knows that she acquires the key from B) way even for achieving S2 (which then infers S3). But this also infers S4, since A acquires PK in an identity-verified way.

So, my question is basically this: what is the exact public-key use case, in which age gives its users more than requiring them to exchange a secret, integrity-protected, identity-verified value?

In my understanding, age, without keeping PK secret (and integrity-protected after acquiring it in an identity-verified way), fundamentally can only provide confidentiality, but neither integrity nor identity verification. For the latter guarantees A and B need some kind of signing (but this introduces the exact same problem (among other problems) of how would A verify that she received the PK for encryption indeed belongs to B = how would B verify the PK that M is signed by indeed belongs to A? – but these can be solved, if the keys can be public). Or they just need to exchange PK in a secret, tamper-resistant, and identity-verified way, which is basically the same of exchanging a shared secret, i.e., symmetric key / passphrase .

The public key needs to be public and private at the same time

PK needs to be public, so it is publicly verifiable

If PK is public and publicly verifiable (e.g., published on a website, facebook, etc.), then S4 can be easily fulfilled. But even if it's not public, it needs to get to the sender (A in the example above) in an integrity-protected and identity-verified way, so they can check not to send secrets to a random person.

PK needs to be secret, so adversaries shouldn't be able to produce an age file that will decrypt with a given identity

If PK is secret, then adversaries cannot produce a forged age file, since the input key material of the HKDF producing the file key includes PK. A sentence from the already referenced article: “For example, if you upload backups to cloud storage, simply make sure you don't upload the recipient string along with them.”

• Why is the recipient an input to the file key's KDF? Even without this, the adversary couldn't forge a valid file key (and thus a file that decrypts) under ECIES, if they don't know the recipient. Or could they?
• Also, I really cannot see why I would upload backups to a cloud encrypted with my own public key, I just would use a secret key.

PK necessarily needs to get outside of one's hands in an A to B scenario (i.e., PK of B gets to A), so it is not a secret any more (or it must be an integrity-protected encrypted secret for age's properties to hold, which essentially could be just a symmetric key).

But if PK is an integrity-protected, identity-verified secret, it could just be a shared secret key

Sharing a secret, symmetric key between the sender and the recipient would immediately check all S1-S4. The precautions for PK are exactly the same as they would be for this secret, symmetric key, if the goal is checking all S1-S4. Therefore, I cannot really see what more age actually gives to its users in a public-key setting than the requirement of sharing PK as a secret value in an integrity-protected and identity-verified way, which easily could be a symmetric key providing equivalent (if not stronger) security guarantees.

---

Any thoughts on this, @FiloSottile? Don't get me wrong, I am a big fan of the project, and I'm really happy that you introduced a solution to the past-century file encryption mess of gpg. But in lack of a comprehensive security target, I cannot answer these questions myself. I honestly hope this will be a fruitful and informative debate!

(Feedback on age-authkey-plugin: I could be happy with the flag + encrypt-side plugin, but I would really like to see a comprehensive security target before taking these next steps.)

[peter021]

"S2 (Integrity)
The content of M is integrity-protected against third parties (“authenticated, i.e., cannot be modified”)."
This is in fact guaranteed anyway through use of the AEAD algo ChaCha20-Poly1305.

"S3 (Sender identity verification)"
age cannot provide this proof. Age does not sign and there is no way of telling how Bob sending his PK was compromised.

"S4 (Receiver identity verification)"
Age cannot provide this proof. Age encrypts to "a key". It is guaranteed that only the holder of SK can encrypt it, but age has no means of verifying or tracking vérifications(trust levels), or detecting if the stored key was manipulated somehow .

"question is basically"
Your question is valid, and it does not, but age is a simple encryption tool it is not a full fledged replacement for gnupg at this time. Perhaps the best use case at this time is as a local encryption tool, where the symmetric key is stored in a keyring.

"but neither integrity"
yes it does, through the use of the AEAD algo ChaCha20-Poly1305.

[luczsoma]

I’m aware that age preserves the integrity of the ciphertext by the usage of ChaPoly as an underlying primitive (and by incorporating the public key into the file’s encryption key). But it only does so if the public key used to encrypt a) is kept secret, b) is initially sent to the other party in an authenticated way. (Otherwise nothing would stop an adversary from a) capturing and replacing a sent message with a new, forged one, b) capturing the initially sent public key itself and replacing it with their own, so the other party ultimately encrypts to the adversary’s public key.) This is sort of the same as pre-sharing (or agreeing on) a symmetric secret key, then using that for sharing files; in the public-key age the public key is this “secret key”.

The age docs (in my opinion, very sensibly) never mentions age being authenticated in a public-key setting, but Filippo wrote about it in his excellent newsletter some time ago.

Please note that I do not really argue with either the encryption solution or the docs that age provides (although I would still very much like to see its security model defined), but with the fact whether it is a good thing that age can be authenticated in a public-key setting (as it can be, if the public key is kept secret and initially sent in an authenticated way).

What I fail to see is this (even though it is not a defined goal of age per se). Why would a multi-party group needing authenticated encryption use a public-key encryption scheme with keeping the public key secret and sending it in an authenticated way – instead of using a well-defined, well-scrutinized symmetric AEAD with keeping the, well, secret key, secret, and sending it in an authenticated way? Isn’t making authenticated encryption possible via this undocumented “secret public key” scheme a possibility of misuse, which cryptography engineers are all very sensitive to?

[peter021]

I agree with you. I think this "secret public key"-scheme could possibly be an unfortunate mistake.