Ask HN: In Emacs, is there an alternative to GPG encryption in Org Mode?
It's GPG is starting to show it's age, Debian abandoning it for signing packages and it's general lack of usage.
Was wondering how one could probably use https://github.com/FiloSottile/age or something.
(Not an emacs pro, so sure don't know some of the trivial ways to use this) A good place to ask questions like this is the (very friendly) Emacs subreddit.[1] The problem with everyone having moved from forums over to subreddits is that in order to interact with the community/ask qiuestions/whatever, you need to have a Reddit account and deal with Reddit's dark patterns, data collection and general disrespect for their users. Compared to the current status quo of the likes such as Facebook, LinkedIn and Google, I think Reddit is relatively mild. Also, keep in mind that HN is actually fairly similar a forum, and with that in mind, it’s very reasonable to point them into the direction of Reddit. >Debian abandoning it for signing packages and it's general lack of usage. This is not true. There was a proposal near the start of the year. That proposal has been almost entirely ignored. Would age provide any advantage over GnuPG to make it worth the bother to switch to a new message format? There is a live proposal right now, by one of the Debian apt developers, who was just here a couple days ago talking about it. I agree, it's not clear what's happening yet, but signify-style apt signatures are not a past-tense thing right now. I don't want to reopen a can of worms on that very weird age vs. PGP thing you wrote (Debian isn't going to use age) but again, I think you should correct it, because it openly advocates for malleable unauthenticated encryption, which beclowns the rest of the points it tries to make. If you want to recover from single (or multiple) bit errors in your ciphertext, you don't relax authentication of your ciphertext; you forward-error-correct it. The proposal has no place to go at this point. It may come back in the future, but right at the moment it is effectively dead. If you are doing FEC then you need to decide how many bits you are going to be able to correct. That determines the amount of redundancy you need. Media problems generally come in physical media sized chunks, often adjacent. Hundreds, thousands or millions of bits might be involved. FEC is not a magic bullet for data loss, particularly in this case. Usually the best you can do is to recover the good parts and age deliberately prevents you from doing that. You can run chacha20-poly1305 decryption without verifying the MAC, and accept that an adversary can accurately bitflip any and all bits they want. Normal tools don't have command line flags for that, but a recovery tool can do that no problem using the same exact code as age. If that were true, would that then mean that age would be malleable by flipping around and deleting and duplicating blocks? How does it ensure continuity without preventing recovery of blocks subsequent to the bad one? I have not dug into the age code to figure out how the encryption works so I am guessing here. I'm not sure you understand what the previous commenter was suggesting. They're saying the receiver of an `age` message could, in theory, skip authenticating the ciphertext. They would have to do so deliberately (so deliberately that the code to do it doesn't exist), and the entire point of doing so would be to defeat message security in an attempt to do data recovery. I think you should probably dig into the age code before writing posts about why PGP is better than age. The question of whether adversaries can modify age messages in transit is a pretty basic one. The actual damaged 64K age blocks would likely be unrecoverable after the start of the damage unless the chacha20-poly1305 ended being self synchronizing as it was used (as opposed to the CFB that OpenPGP specifies). The question I can't answer is if the undamaged 64K age blocks would then be recoverable. There might be just a counter, but you could instead (also) make a particular block dependent on the previous one(s). Do you understand that chacha20 is CTR? A bit flip only affects that single bit, does not propagate to any other bits? From that can I get that an age recovery utility would need to detect missing data and would then need to insert dummy blocks (or the equivalent)? I guess there would have to be an minor element of brute force involved as there would be no easy way to distinguish bad blocks from the blocks after the missing chunk. The major concern is only about long term stability, with people starting to talk about stopping things, some paranoia kicked in. 'age' is still quite beta, so not sure if it's entirely worth the switch. But yeah I guess the long-term archival is something that I hope to have. If you have gnupg installed, emacs can just open foo.org.gpg files directly. It decrypts on load and re-encrypts on save. Probably you would get better answers about Emacs on https://emacs.stackexchange.com/ or https://www.reddit.com/r/emacs/ . I really dig https://www.emacswiki.org/emacs/EasyPG It lets you encrypt/decrypt files or regions of a text file and is pretty easy to use. I've always had trouble getting it to cache the password between opening and closing (with symmetric encryption). I am just considering the fact after 10-15 yrs would it be possible to still read those files?
I use it (gnupg) for some of the data in my org files. It's just long term use, I'm concerned about. If your concern is in the long term, wouldn't you want to put your trust in the most mature and long lasting project today (i.e. gpg)? Nobody can see the future, but given that gpg is open source and has been actively developed for over 20 years I feel comfortable trusting it to continue to exist. That phenomenon has a name and a Wikipedia page (probably called "X's Law") but I forget what it's called. But the point is: the longer something has been around, the longer you can expect it to be around (given that you know nothing else about it). Cf. the age of a mountain vs an individual butterfly and your prediction of how long you expect it to be around for. It's called Lindy Effect. It is applicable to some non-perishable things, where mortality rate decreases with time. GPG isn't going anywhere and Debian is not abandoning it. EasyPG is very mature in Emacs, makes using GPG a breeze and is integrated really well. Age doesn't even support signing and has no Emacs integration. Have Debian abandoned it? Official reference to that fact if you have it would be nice. I’m aware of the wiki article but that’s not any official position. In the very least anyone can edit that wiki. Why not keep the notes in a VeraCrypt/TrueCrypt drive/partition? You can sidestep all the gpg complexity, and you get a little better protection since note filenames won't even be visible (and if you're really paranoid you can entirely obfuscate and hide the encrypted drive in unused partition space). Or just tick on the full disk encryption option in your OS (assuming it's a modern one like Win 10, recent Ubuntu, etc.). It's just as good at keeping your data protected at rest as any other encryption option you can run in userspace, and there's less chance of some file operation snafu accidentally unencrypting or leaking your data. > Why not keep the notes in a VeraCrypt/TrueCrypt drive/partition? Because in this case you have to backup the whole encrypted disk, instead of syncing a couple of encrypted files. Also, setting up gpg in Emacs is very easy task. I am using selective encryption of orgmode entries with a specific tag, this case is covered in documentation. That is often good, but it does leave mounted volumes accessible to other programs, where GPG files can be decrypted only inside EMACS. Whether this matters depends on your threat model. If you can’t trust the applications running on your system, then I’d say it’s game over. If you need to worry about that kind of thing then you need some kind of workload isolation. One way to solve that is Qubes OS. Here are some other FOSS alternatives: https://fly.io/blog/sandboxing-and-workload-isolation/ > GPG files can be decrypted only inside EMACS To get this you have to sacrifice the convenience of using gpg-agent, though, right? Otherwise any other program that can open your gpg agent socket can use your gpg keys. GPG-PGP works well, has tooling on pretty much every platform, is a mature, well-established product. The complicated features are optional. Using something like age, with one reference implementation in Go, not supported by most languages, nor time-tested, is just asking for trouble, like surprise exploits or bitrot making your data unusable. I am perplexed by the frequency of "PGP/GPG is old, let's replace it with something new and untested" posts on HN... In software development, OLD is GOOD. (As a side note, I don't think Debian has been at the forefront of rational decisionmaking for a while, so I wouldn't watch them too closely.) Yeah, it’s weird. And it always comes from the same couple of people, with that one obscure hand-wavy blog post. come ask on libera in #emacs The #emacs channel on Libera Chat (irc.libera.chat:6697) is indeed a very friendly and fun channel. For those you are new to IRC and want to take a quick glance at the channel without choosing clients and configuring them, here is a web-based interface to connect to the #emacs channel:https://web.libera.chat/#emacs Here is the Matrix bridge for it accessible via Element's web interface: https://app.element.io/#/room/#emacs:libera.chat . The Matrix bridge could be useful for those who want their nick to stay connected to the channel even after closing the browser without having to set up an IRC bouncer for themselves. Also, for emacs users, you want to point ERC to irc.libera.chat as per: https://www.emacswiki.org/emacs/EmacsChannel I haven't really followed the freenode implosion. Is libera the canonical replacement server, in some sense? Yes. It's run by the original (pre-takeover) Freenode staff. Thanks. Orthogonal question: where can I learn more about Debian abandoning GPG? I was also looking for this, I guess here: https://wiki.debian.org/Teams/Apt/Spec/AptSign I doubt this will happen any time soon. Ah, thanks for reply, and for the info. Just noticed now, woops.