encrypt then mac

[rain-1]

Write HMAC(key, plaintext).

It is advised to encrypt then mac. this is doing mac then encrypt.

source: https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac

[skeeto]

You're right, that's what I should have done. Unfortunately I had realized this myself too late, but fortunately it's harmless in this instance. I don't want to change the file format at this point, so it will remain mac-and-encrypt.

[taoeffect]

"I don't want to change the file format at this point" means you are not serious about security, and people should avoid this tool.

[skeeto]

I am serious about security — that's why I wrote Enchive in the first place — but I'm also serious about other important goals. Security is not absolute. It's a trade-off against other values, and, as such, it's not always worth the cost. In this case the cost is supporting, forever, two different input file formats, but the increase to security would be effectively zero. That's not worth it. While Encrypt-then-MAC would have been a better choice, MAC-and-Encrypt is not automatically broken. For example, SSH still uses it. If someone showed that Enchive's use of M&E is broken then I would definitely fix it with an update to the format. Until then there's no reason for it to change. If I ever have to update the format for some other reason, I'd also take the opportunity to switch to Encrypt-then-MAC since there would be no additional cost to do so.

[taoeffect]

In this case the cost is supporting, forever, two different input file formats, but the increase to security would be effectively zero. That's not worth it.

I'm not understanding why you would need to support two different input formats.

AFAIKT you just released this utility. I doubt it would cause anyone any upset if you were to release a major update that wasn't backwards compatible, but greatly improved the security guarantees of the app with respect to potential attack vectors.

SSH still uses it. If someone showed that Enchive's use of M&E is broken then I would definitely fix it with an update to the format

I don't know the technical details of SSH, but MAC-then-Encrypt has resulted in serious problems in other tools and protocols. It intuitively makes sense why that would be. You're willingly allowing data to be tampered with and for that tampering to go unnoticed. That's a serious problem. Why risk that at all if you could choose to not take such an unnecessary risk?

The app itself doesn't seem to be much better than GPG in terms of security (or even usability), and yes, I did read your blog post, and also this comment on it.

[taoeffect]

BTW, I do want to emphasize that a big part of the reason why I sound so frustrated and upset is that I really want to use this tool, and I really love the thought and work that you've put into other areas of the project. While it would've been even better had you chosen to write it in Rust, it's still really great, for example, how this program has zero dependencies. And it's always great to see new encryption tools and utilities being implemented. I just wish they really pushed the envelope forward more is all. :-\

[nico202]

AFAIKT you just released this utility. I doubt it would cause anyone any upset if you were to release a major update that wasn't backwards compatible, but greatly improved the security guarantees of the app with respect to potential attack vectors.

I have now lots of enchive files; a format change will be quite a pain indeed

[taoeffect]

Well, it's a shame that @rain-1 chose to close this issue that he opened, so I re-opened it myself here: #22

I have now lots of enchive files; a format change will be quite a pain indeed

@nico202 Could you explain what would prevent you from continuing to use enchive 1.x with your enchive files should @skeeto choose to improve the security of enchive in a 2.x that supported Encrypt-then-MAC?

[nico202]

@taoeffect it's not that i wont use it. But if enchive 2.x does not support both files format, that would mean that I'd have to do something like

enchive -v # 1.x
find ./ -iname "*.enchive" -exec enchive extract {} \; > extracted
# upgrade to enchive 2.x
while read line; do
enchvie archive "$line"
done < extracted

or something like that. BUT some of those are on 1 computer, some on one other, some on extrernal unconnected drives. Some are on nextcloud, some might be on some third party storage system that I cannot remember. And the one that are available are on a raspberry pi, so that would take days. If the way to go is something like:

• try the new format
• if fail:
• try the old one
• fail

then I would just not upgrade the files format

[taoeffect]

@nico202 You would not believe what I’ve had to do, how many shell scripts I’ve had to rewrite or convert into completely different languages, in order to benefit from new technologies and security improvements.

Never once in my life though, have I ever felt it acceptable to make other people less secure because I felt it would be too much of an inconvenience for to me to do so.

[nico202]

Well if somebody using enchive and just upgrades, s/he will (temporarily) might loose access to his/her files. I don't know how many people we are talking about, but if it's the three of us it might be fine. But enchive is already in various repositories, so IMHO the only feasible way is something like supporting both formats and issuing a warning for old format files (printing the command needed to convert it in place to the new format). But dropping the support is like: "ok this program is supposed to help you to store file securely for later use (but this later means one year)". Given that those encrypted files are supposed to contain sensitive information, loosing them is not the best thing to do. And yes, you can always go back in time with git, recompile, decrypt, compile, encrypt. But still it depends on the number of people actively using enchive. That said, if we want to move change the memory-hard function (as suggested in the other issue) those both might go together and a format change might be required. Still I find it to be important to tell the user the last "working" version they might try.

(Sidenote/theoretical question that does not apply: would you rather loose forever your files or keep them in a way that maybe somebody will be able to bruteforce them?)

[taoeffect]

But enchive is already in various repositories, so IMHO the only feasible way is something like supporting both formats and issuing a warning for old format files (printing the command needed to convert it in place to the new format). But dropping the support is like: "ok this program is supposed to help you to store file securely for later use (but this later means one year)". Given that those encrypted files are supposed to contain sensitive information, loosing them is not the best thing to do. And yes, you can always go back in time with git, recompile, decrypt, compile, encrypt. But still it depends on the number of people actively using enchive. That said, if we want to move change the memory-hard function (as suggested in the other issue) those both might go together and a format change might be required. Still I find it to be important to tell the user the last "working" version they might try.

That sounds perfectly reasonable to me, and if it were me I would do exactly that.

(Sidenote/theoretical question that does not apply: would you rather loose forever your files or keep them in a way that maybe somebody will be able to bruteforce them?)

If your files are brute-forceable or if there is some bug that's discovered in the current format, well, then you didn't really lose them in the first place, did you? You and others will be able to decrypt them regardless of what future versions of the program do.

I will share an anecdote from my own personal experience in the decade that Espionage has been around. Espionage went through 3 major rewrites, which included fundamental changes to some of the file formats it used. We did provide an upgrade path to ensure users did not lose their data, so hopefully that answers your question.

[skeeto]

AFAIKT you just released this utility. I doubt it would cause anyone any upset if you were to release a major update that wasn't backwards compatible

Enchive is packaged by FreeBSD and it has 337 stars on GitHub. So I estimate there are maybe a couple hundred real users out there, who potentially have files up to 1.5 years old. I can't really know. But that's enough that I don't want to break anything. Stability is as important to me as security. https://www.freshports.org/security/enchive/ If/when the format is updated, the old format would still be supported for reading indefinitely, so you can always decrypt your old data. It would be designed such that Enchive could unambiguously determine which format the file is in despite the format having to distinguishing marks. For example, that's why the format version number is currently mixed into the header. When the output format changes, Enchive's major version number will increment to 4. It's at 3 right now because there were already two previous formats, both from before I announced the project. Those formats were only used for testing by a few beta testers, so they're not supported. For Enchive 3.x and later, any format Enchive writes will be supported forever. Because of this, I don't want to add a new format lightly. There must be a good reason for it. Regarding the link in the other thread, very shortly after I announced Enchive several people pointed out the doom principle, and I realized my mistake. However, as I pointed out, MAC-and-Encrypt isn't _automatically_ broken, it's just something that can fail badly. Fortunately it doesn't actually break Enchive's security, and I don't intend to change things unless someone shows that it does. Proving such a vulnerability is _much_ harder than normal because Enchive is only used in the most boring circumstances: offline on static data. I chose verbs specifically to narrow it to this particular scope ("archive", "extract"). It isn't a network protocol and attackers cannot interact with it willy-nilly. There are no chosen plaintext attacks, nor are there attacks that require 2^N ciphertexts. The attack surface is minuscule. The MAC is there so that someone with write access to your archives (e.g. your backup host) cannot easily mess with your data. However, this isn't even necessarily a strong guarantee due to an intentional design trade-off: You don't need access to the secret key to encrypt data — e.g. you don't need to enter a protection passphrase when using the "archive" command. That's because the MAC doesn't incorporate the secret key. Anyone who has access to your public key and write permissions to your archives could overwrite your files with entirely new data, and the MAC would validate. I think I explained this somewhere in my writing about Enchive, but this was motivated by a desire to encrypt data on systems I don't necessarily trust with my secret key. On those systems, Enchive serves as a one-way black hole where I can dump sensitive data (and then delete it) to secure it. This is a core feature and is not subject to change. Again, Enchive is an archival tool, and you're not encouraged to send your public key to other people, including your backup host. It's not really "public" in the normal sense. This helps mitigate the issue, but it still means the MAC really isn't so vital anyway. If there is a new format someday — perhaps due to problems arising with Curve25519 or ChaCha20, or due to quantum computers — it would include at least these changes: * Encrypt-then-MAC. * The MAC would also cover the header, IV, and (probably?) ephemeral key. * Different MAC and encryption keys. * Random IV, not derived from the shared secret. * Shared secret would be run through a KDF before keying the cipher. * Chunked authentication so that there is never unauthenticated output, but arbitrarily large data could be processed with fixed-sized memory. (My Blowpipe project does this.) Right now it's risky to pipe the output directly into, say, tar.