Compare and contrast with encpipe

[Brahmasmi]

Namaste,

I am not a cryptographer. I am not a math expert.

Would it be possible for the good volks here to compare and contrast age with encpipe (https://github.com/jedisct1/encpipe), especially for the encrypted backup use case? The signing of the backup will be handled by signify/minisign.

I am trying to decide between age and encpipe. My limited understanding layman comparison tells me that encpipe is written in C, is ISC licenced, and seems simple in terms of complexity. On the other hand, age is written in go, is BSD licenced and seems medium in terms of complexity.

As I said, I am not a cryptographer.

Dhanyavaad.

[FiloSottile]

I can't find a spec for encpipe describing the format, so it's hard to compare the crypto, but I guess that's already a difference, in that age has a format spec, which for backups it might make it easier to decrypt far in the future. It also has multiple implementations.

Judging from the README, encpipe only supports passphrases, while age support public/private keys, which might be what you want for backups if you don't want the machine creating the backups being able to decrypt past ones.

[Fastidious]

Namaste,

I am not a cryptographer. I am not a math expert.

Would it be possible for the good volks here to compare and contrast age with encpipe (https://github.com/jedisct1/encpipe), especially for the encrypted backup use case? The signing of the backup will be handled by signify/minisign.

I am trying to decide between age and encpipe. My limited understanding layman comparison tells me that encpipe is written in C, is ISC licenced, and seems simple in terms of complexity. On the other hand, age is written in go, is BSD licenced and seems medium in terms of complexity.

As I said, I am not a cryptographer.

Dhanyavaad.

It looks like you are not a cryptographer, or a math expert, are you? Compare and contrast sounds like something out of a class assignment, so I assume you are a relatively young student. I recommend you similarly ask @jedisct1, and share his reply.

[FiloSottile]

@Fastidious There's no need to presume the background of people on the issue tracker :) Comparisons are good for end users, they help in assessing what the best tool is for them.

[cyb3rz3us]

@FiloSottie: Awesome response...I for one am really glad you stepped up and made that comment. Absolutely no need for folks to try and flex on others especially when they don't even take the time to fully read what was previously posted...

[jedisct1]

If you need to encrypt data for other people, use age.

If you need to encrypt data for yourself, encpipe may be slightly easier to use, but really, from a practical security standpoint, there are no differences.

[cyb3rz3us]

Just to offer a counterpoint, IMHO, not sure I'd agree that 'encpipe' is easier to use than age for a given task. Not being contentious - just sharing my view that both seem to be of equal difficulty and effort when doing the same function.

Also, at the risk of eliciting some minor irritation, for strictly comparison sake (not intending to kick-off any kind of tool debate here), there's enchive https://github.com/skeeto/enchive and of course scrypt itself.

[Fastidious]

@FiloSottile understood. For what is worth, I read what OP wrote, @cyb3rz3us, and my note was not meant to flex, nor had ill intend. It was more a tongue in cheek reply which, in retrospect, I shouldn't have written. Will not amend, or delete, to serve as a reminder of what not to do.

Cheers!

[jedisct1]

enchive apparently encrypts the file as a single block, and only checks the MAC at the end. If the MAC doesn't match, it doesn't even remove the corrupted/incomplete file. If only for that reason, I wouldn't trust it for backups.

age has the potential to become the de facto standard way to exchange encrypted data, which is a big deal.

For personal use, other tools that don't have that ambition are probably fine as well. And there are plenty of these. Pick whatever you are comfortable with. Also, GPG remains fine if you know how to use it correctly.

[cyb3rz3us]

@jedistct1: Good feedback...FWIW, based on my personal experience here, but GPG + AES is horribly slow as compared to any of the other 4 tools discussed in this thread. I presume at least part of the reason why is due to AES. Again, just noting based on my personal experience only...YMMV...

Re: enchive and 'when to MAC', the author has commented on Reddit a bit about his current design decisions and what he might do differently if building the tool over again.

[Brahmasmi]

Grazie @FiloSottile for your helpful reply.

I find the idea of public/private keys for encrypted backups interesting, and counter-intuitive.

Advantage:

1. Compromise of the public key does not automatically compromise the encrypted backups.
2. Possession of the private key does not allow creation of new backups.

In short, an encrypt-agent can only encrypt, and a decrypt-agent can only decrypt. Compromise of either, limits damage to that privilege. Privilege separation, I think.

Disadvantage:
If I am not wrong, the convention in asymmetric cryptography is:

• private key: used for encryption/signing, safeguarded via passphrases, ideally does not leave the machine/device, ideally used only via ssh-agent/equivalents.
• public key: used for decryption/verification, not safeguarded via passphrases, usually leaves the machine/device, distributed securely to the public.

Now, in age, the public key is actually used for encryption, not decryption. This is counter-intuitive to the convention of using the public key for decryption, and confused me for some considerable time.

Further, in age, the public key should not be distributed publicly. This is counter-intuitive to the convention that a public key is distributed publicly.

Would we all benefit, if we call the keys "encryption/decryption" keys?

[alerque]

@Brahmasmi It sounds to me like you have something scrambled.

Now, in age, the public key is actually used for encryption, not decryption. This is counter-intuitive to the convention of using the public key for decryption, and confused me for some considerable time.

There is not such convention. Public keys are not for decryption, they are for encryption. In this sense age works no different than any other asymmetric cryptography tools. It would be nonsensical to reverse this, and the case of backups is no different. A public key would be used to make backups. The private key would be required to restore them.

Further, in age, the public key should not be distributed publicly. This is counter-intuitive to the convention that a public key is distributed publicly.

Where are you even getting this? You distribute the public key to whoever / wherever an encryption needs to happen that only you with the private key can decrypt. This can be public if your use case is for anybody to be able to send you an encrypted packet. That's why it's called the "public" key.

[Brahmasmi]

@alerque , thank you for your reply. I did have some things scrambled. Please bear with me.

Let us assume, alerque wants to securely exchange messages with others. alerque generates an X25519 public/private key pair using age-keygen.

The private key is safeguarded with a passphrase, has the correct rwx settings such that group and others do not get any rwx access to it. Ideally, the private key does not leave alerque's machine/device.

The public key is distributed securely by alerque to others. This public key is not safeguarded by any passphrase.

Now, when others wish to send a message to alerque such that only alerque can read the message, others use age to encrypt the desired message using the public key that alerque has securely distributed to them. This message, once correctly encrypted using age, can only be decrypted and read by alerque after decrypting it with age using the private key.

In the above case, the public key is used for encryption and is distributed publicly.

Am I correct in my understanding now?

Earlier, I had assumed that the public-key cryptography was to send the message from the keypair holder to others whereas it is to send from others to the keypair holder. This incorrect assumption happened because I extrapolated my understanding from digital signatures. If I am not wrong, in digital signatures, the signing happens with the private key and the verification happens with the public key. I have mentioned this in my understanding as well - "encryption/signing" and "decryption/verification". As I said, I am not a cryptographer.

Now, I am evaluating age and encpipe from the perspective of encrypting backups. From what I have seen, backups are usually encrypted using symmetric keys. It took me a considerable amount of time to wrap my head around the public and private key concept for backups before I understood the nomenclature and the intended use case. And I tried to outline what I understood, where I got confused with the nomenclature and how I found it counter-intuitive - in my mind, there are only encryption and decryption keys.

In the case of backups, I do not think one would ever want to publicly distribute either the public or the private key. In other words, the encryption or the decryption key. If the encryption key is publicly distributed, anyone could generate backups, which would be decrypted successfully. If I am missing something here, and there is a rationale for publicly distributing the encryption key for backups, I would be interested in learning from it.

So, for the use case of encrypted backups, could we call them "encryption/decryption" keys?

And given my publicly evident incorrect understanding of the basics of asymmetric encryption, I hope that volks do not take me to be a cryptographer.

[alerque]

Yes the first section is roughly right now.

Signing is a completely different problem that in many ways is the opposite of what encryption is about, but also has a different threat model and other constraints. Don't try to extrapolate. That's part of why GPG got so complex and unwieldy. In the case of age signing and verification are completely out of scope (and there are other specialty tools recommended for those jobs).

In the case of backups you are right there is no sense in "publicaly distributing" keys. But there might be sense in distributing them to different places. For example if the private key is not on a machine but only the public key, then that machine can back itself up, but a compromise of the machine would not compromise all the existing backups as well. A restore process could be used to inject the private key which could be kept safer than the things being backed up.

In the case of backups yes "encryption" and "decryption" keys makes sense, but changing the names would not be a good idea overall. This is a multi-purpose tool and the whole point of calling them "public" and "private" is to make it obvious what to do with each part and make it harder to make mistakes in key handling.

[cyb3rz3us]

I would add (and please accept my apology up front is this is redundant) but the payload encrypt\decrypt transform used by 'age' is always symmetrical. There is absolutely no encryption\decryption of the actual payload using an asymmetrical algorithm.

This then leads to why we cannot call the payload decrypt\encrypt key an "encryption" or "decryption" key...it is the same key. How it is handled varies based on what the user is doing but regardless, the decrypt\encrypt is always symmetrical...