remko
Help understanding encryption safety
Hey, need some help to understand what exactly is encrypted and where. For example
Would it be safe to keep an identity encrypted with my current-biometry in a public repo? I'm assuming noone could actually use it unless they both have access to my laptop AND my biometry.
Or of course, if there is some vulnerability in the encryption algorithm itself
Not sure if this is the best medium to ask, but thanks in advance
This is probably the best medium to ask.
age-plugin-se uses SecureEnclave.P256.KeyAgreement.PrivateKey to construct private keys. The age identity is an encoding of the dataRepresentation of the private key. Unfortunately, there currently doesn't seem to be any detailed description of what the properties of these private keys and their data representation are (or I haven't found it at least), so all I can give is anecdotal evidence.
I'm assuming noone could actually use it unless they both have access to my laptop AND my biometry.
That seems to correspond to my assumption. Moreover, it seems that a private key without any protection (biometry or passcode) is also not usable on the same machine as a different user. I don't know what happens to the key's validity if you wipe your machine and restore it from backup.
That said, I tend to keep my secret keys private.
If someone can find a more definitive answer with pointers to documentation, that would be very welcome.
So the "private key" output to the file is not actually a private key but the private key is stored in the SE?
@CodeWithShreyans No, that doesn't sound correct. No private keys are stored in the SE, otherwise storage could run out when generating keys. The SE generates a private key, encrypts it, and outputs the encrypted data. Only that specific SE can decrypt the private key and use it for operations.
@CodeWithShreyans Right, that confirms what I said.
Also, from this article:
When you protect a private key with the Secure Enclave, you never handle the plain-text key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create and encode the key, and later to decode and perform operations with it.
I too am curious about the encryption design used in this software. It looks like exactly what would help me (I wanted to use a solution based on https://github.com/maxgoedjen/secretive with https://github.com/Sets88/ssh-crypt but they have no crypto algorithms in common).
The way I thought this would work is that keygen would create a key pair with the private key only accessible via the Secure Enclave mechanism. Then it would also create (or derive) a symmetric key for use with AES, or the like, that is actually used to encrypt the data requiring secrecy. So I presume the example file key.txt contains that key encrypted by the public key, and thus only accessible via the SE mechanism (hence the 'binding' to the SE you describe).
I didn't think asymmetric keys were usable for encrypting arbitrary data as the size becomes computationally infeasible once it is bigger than the key modulus (256 bits in the case of P-256 as here, or 2048 bits in the case of RSA).
So in your example, is the contents of key.txt the key for symmetric encryption encrypted by the public key? Otherwise I don't grasp how the mechanism can work.
I tried tracing the source code but am not sufficiently familiar with swift, or macOS development in general.
Many thanks.
@LRvKochel key.txt is not a key for symmetric encryption. It contains a key that can (only) be used for DH Key Exchange with another P256 key.
What the key in key.txt is exactly shouldn't matter conceptually: it could be the ID of a P256 private Key stored in the Secure Enclave, or it could be a blob of configuration data encrypted with the single 'master' key in the Secure Enclave. Either way, the key is indistinguishable from random, only usable to do DH Key Exchange using the SecureEnclave.P256.KeyAgreement CryptoKit API with another P256 key, only usable with the Secure Enclave it was created with, and only usable with the constraints given at creation time (code, biometry, ...).
As for the actual design of the encryption, see the age spec and the age-p256 spec.