[HN Gopher] Ask HN: In Emacs, is there an alternative to GPG enc...
___________________________________________________________________
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)
Author : timetosleep
Score : 66 points
Date : 2021-06-25 13:50 UTC (9 hours ago)
| olivierestsage wrote:
| A good place to ask questions like this is the (very friendly)
| Emacs subreddit.[1]
|
| [1] https://reddit.com/r/emacs
| eindiran wrote:
| 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.
| stingraycharles wrote:
| 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.
| qbasic_forever wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| philsnow wrote:
| > 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.
| rcgorton wrote:
| yes. Do NOT use Emacs. Perhaps a bit extreme, but Emacs is an OS,
| not an editor. And as such, it has a ton of vulnerabilities
| exikyut wrote:
| Orthogonal question: where can I learn more about Debian
| abandoning GPG?
| dalai wrote:
| 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.
| forgotmypw17 wrote:
| 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.)
| aborsy wrote:
| Yeah, it's weird. And it always comes from the same couple of
| people, with that one obscure hand-wavy blog post.
| creamytaco wrote:
| 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.
| beermonster wrote:
| 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.
| CyberShadow wrote:
| 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/ .
| timetosleep wrote:
| 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.
| ijlx wrote:
| 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.
| unhammer wrote:
| 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.
| ktm5j wrote:
| 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.
| bigdict wrote:
| I've always had trouble getting it to cache the password
| between opening and closing (with symmetric encryption).
| upofadown wrote:
| >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?
|
| * https://articles.59.ca/doku.php?id=pgpfan:agevspgp
| timetosleep wrote:
| 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.
| tptacek wrote:
| 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.
| upofadown wrote:
| 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.
| wolf550e wrote:
| 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.
| upofadown wrote:
| 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.
| tptacek wrote:
| 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.
| upofadown wrote:
| 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).
| wolf550e wrote:
| Do you understand that chacha20 is CTR? A bit flip only
| affects that single bit, does not propagate to any other
| bits?
| upofadown wrote:
| 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.
| hprotagonist wrote:
| come ask on libera in #emacs
| susam wrote:
| 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.
| pama wrote:
| Also, for emacs users, you want to point ERC to
| irc.libera.chat as per:
| https://www.emacswiki.org/emacs/EmacsChannel
| AlexCoventry wrote:
| I haven't really followed the freenode implosion. Is libera
| the canonical replacement server, in some sense?
| neolog wrote:
| Yes. It's run by the original (pre-takeover) Freenode
| staff.
| AlexCoventry wrote:
| Thanks.
___________________________________________________________________
(page generated 2021-06-25 23:01 UTC)