Implement new age1tag1.../p256tag and age1tagpq1.../p256mlkem768tag recipients

[FiloSottile]

The spec at C2SP/C2SP#156 should be stable at this point, but before merging it I wanted to check with the downstream plugins.

Both recipient types will be natively supported in the age CLI, and p256tag should allow you to replace the stanza you are using without updating identities. I'd love it if you could prototype it and confirm that.

There is also an age-plugin-tag binary that can replace your recipient side for older versions of age, if you want.

The PQ hybrid instead is meant to hybridize software ML-KEM with hardware P-256. You'd store the ML-KEM seed either in the identity encoding, or in the SE if possible (or both). I'm curious to hear what works best for the plugin's UX (e.g. do you need to / can you regenerate the identity from hardware, or is it already irreplaceable?) and SE capabilities (is there a way to store a secret? does it require double user interaction?).

[remko]

AFAIK, the secure enclave doesn't have storage, but uses encrypted blobs as keys for its operations. The SDK seems to have support for MLKEM768 keys.

That said, unless I am missing something, neither of both HPKE cipher suites seems to currently be offered by CryptoKit: there are no P256 ones with ChaChaPoly, and the MLKEM768 doesn't even have a combination with P-256. I don't know how Apple decides which suites to offer, and whether they plan to extend these.

I don't know enough to comment about using the uncompressed P-256 curve point; the P256 SDK only works with compressed representation AFAIK, but maybe this would be different for an HPKE API.

[FiloSottile]

Oh, awesome, you can do ML-KEM directly on the SE!

You can reimplement the narrow slice of HPKE we use from the key exchange, ChaCha20Poly1305 and HKDF, it's not hard, and you don't have to think about it as "HPKE". Here's how I did it in JavaScript: https://github.com/FiloSottile/typage/pull/45/changes#diff-9d06e6f01ea3cd3abad9e83340dec049f1939bbc2825e624c8d14b1ae8a20f08R148-R205

https://developer.apple.com/documentation/cryptokit/p256/keyagreement/publickey seems to allow you to export both uncompressed ("raw" or "compact", not sure) and compressed.

The main interop question is: given your current identity encoding, can you match on the tag without requesting user input (unless the tag is indeed a match)? (What is your current identity encoding?)

[FiloSottile]

The main interop question is: given your current identity encoding, can you match on the tag without requesting user input (unless the tag is indeed a match)? (What is your current identity encoding?)

Did a bit of digging, and I see you already are doing interaction-less matching on the older version of p256tag, so the new slightly tweaked version should work just as well. Also, since you were using the same piv-p256 stanza as age-plugin-yubikey, the same upgrade path should work.

Sounds like the new spec will work for age-plugin-se! Also, very excited about hardware-bound hybrids, when you'll have time to implement them.

[FiloSottile]

C2SP/C2SP#156 and FiloSottile/age#651 are merged!

[remko]

You can reimplement the narrow slice of HPKE we use from the key exchange

Aha, I see, thanks for the pointer!

The tag recipient is now available on main behind a --recipient-type=tag flag:

$ brew install --head age-plugin-se
$ age-plugin-se keygen --recipient-type=tag -o key.txt
Public key: age1tag1qvrpj2tqsz8zaj6fkqkfx07vhdtja3t26m30pskl7mpd0mkgy2jmuu6e6r8

$ echo 'hello, world' | age --encrypt -r age1tag1qvrpj2tqsz8zaj6fkqkfx07vhdtja3t26m30pskl7mpd0mkgy2jmuu6e6r8 -o hello.age

$ age -i key.txt --decrypt hello.age 
hello, world

Recipients for existing identities can be generated using the recipients subcommand:

$ age-plugin-se recipients -i old_key.txt --recipient-type=tag
age1tag1qd5lsl0l0uxwlqmmdzdk44959za5j6pzfnyvn4vp3950t0dsh7qfx89e0w9

Once age support is more widely available, I'll document the flag and switch it to default to tag.

I'll play around with MLKEM soon.

[FiloSottile]

Works great, thank you!

Once age support is more widely available, I'll document the flag and switch it to default to tag.

Alternatively, you can ship age-plugin-tag with your packages, so you can be sure that—at least locally—users will have support for the new recipients even with an old version of age.

Also, you might want to make the tag recipient the default for identity-as-recipient encryption (e.g. age -i key.txt -e), since it's basically guaranteed the decryption will happen with the same plugin version.

[remko]

I added support for the mlkem768p256 recipient, and tested it against age.

Both decapsulations happen on the SE, and only seem to require one interaction. 🙌🏼

I just need to add some tests and make this run on older macOS systems before I merge it into main.

[FiloSottile]

Awesome!

How does the single interaction work? Does the SE let you batch unlimited decapsulations across keys, or are these two keys bundled? Can an attacker decrypt many files with a single touch?

[remko]

The keys aren't bundled.

The authentication state is managed by an Authentication Context object that is passed around, and as such allows batching operations by sharing that object across calls. There might be a grace period after which authentication state is invalidated for the same object, but I haven't been able to hit it after a few minutes in a quick test at least.

So, I guess it's up to the app to limit the batching (and the user to trust the app that prompts to limit the batching).

[FiloSottile]

That's pretty unfortunate, my main use case for hardware wrapping is knowing that even if someone compromised my laptop, they couldn't get more than one or two secrets out because I need to tap the YubiKey for every single decryption.

This way, the attacker can just replace age-plugin-se with a different binary that just decrypts all secrets and extracts them, right? Or is there something tying these keys to age-plugin-se (presumably codesigned by you)?

[remko]

You mean the attacker replaces the binary, you then run the compromised binary, and then tap touch ID? Then yes, that will extract everything. Constraints on keys are listed here, but there doesn't seem to be anything that protects against your attack.

My binary isn't code-signed. I don't think the SE has special support for binding keys to codesigned binaries.

[FiloSottile]

Ouch :( that almost erases the benefit of hardware keys for me: there is little difference between the attacker extracting the key, and the attacker extracting all the secrets I have encrypted with the key.

Is there really no way to prevent that?