From: David Masterson <email@example.com>
To: Tim Cross <firstname.lastname@example.org>
Subject: Re: org-crypt ?
Date: Sat, 11 Jun 2022 20:07:36 -0700 [thread overview]
Message-ID: <SJ0PR03MB5455257C93F1589298C99C80A2A89@SJ0PR03MB5455.namprd03.prod.outlook.com> (raw)
In-Reply-To: <email@example.com> (Tim Cross's message of "Sun, 12 Jun 2022 10:28:47 +1000")
Tim Cross <firstname.lastname@example.org> writes:
> David Masterson <email@example.com> writes:
>> Tim Cross <firstname.lastname@example.org> writes:
>>> Warning: I have not used org-crypt for many years. These days, I just
>>> use a .org.gpg extensions and symmetrically encrypt the whole file.
>>> However, I think I can probably answer some of your questions -
>> Hmm, two questions that this brings up:
>> 1. Do you access your files on (say) iPhone?
>> 2. Do you store your files in Git (say Github)?
> Well, yes and yes, but I don't tend to need to access encrypted files on
> iphone. I do have encrypted files in github. For example, I have a
> private repository of files I share across computers (Linux and macOS).
> Some of these files are gpg encrypted.
Exactly the system I'm looking for! (or almost)
I am already using (Emacs, Org, MaGit) on Linux, (BeOrg, Working Copy)
on the iPhone, and a Github private repository. This is complicated to
the new user (like me w/ 42yrs [off and on] of Emacs usage), but Git has
saved me a number of times on resyncing if I change things on both
sides. But I would like to use more encryption with this. When it's
secure, I'd like to roll it out on my family's iPhones as well.
> Determining which parts are encrypted isn't hard. However, how do you
> know which key to associate with each bit? The only solution I can see
> is to attempt every known symetric key to each chunk until one works and
> if none of the known ones work, ask for another one. This could be how
> it works, but that seems extremely inefficient and difficult to manage
> to me.
> The other problem is how to prompt for the key. Lets say you have 10
> encrypted items in an org file, each encrypted with a different
> symmetric key. Org has to ask the user for the key for each one. What
> goes into the prompt to give the user an idea which of the 10 different
> keys to enter? I guess it could say "Entger key for chunk 1:" and "Enter
> key for chunk2":, but I'm not sure that is good. The system could use
> the section heading, but I didn't see anything to indicate it would do
> that when scanning the code, but perhaps I missed it.
>> Hmm, you're suggesting you don't use org-(en/de)crypt. The manual
>> doesn't spell out very well how to do that. Where do you put your key
>> for symmetric encryption?
> With symmetric encryhption, there is no 'key' to put anywhere. The key
> is the password/passphrase. You only have a 'key' with asymmetric
> encryption, where you have two files, the private and public key. These
> are managed by gnupg in the .gnupg directory (typically).
Problem with my terminology, I guess.
> One thing which you may find helpful is to look at the 3 separate layers
> involved with org-crypt as they all have their own manual and each layer
> provides some of the information you are after i.e.
> - Encryption/decryption and key management is largely handled by gnupg.
> The documentation associated with gnupg is pretty good and will likely
> answer many of your questions.
> - The interface to gnupg from within Emacs is managed by easyPG, which
> basically consists of two libraries - epa, which provides the Emacs
> interface layer for gnupg and epg, which provides a library that can be
> used by Emacs packages to access gnupg. This is primarily what org-crypt
> uses. The easyPG manual is pretty good and contains some good
> - org-crypt, which is a very light-weight wrapper around the epg
> functions. It provides the basic integration between org and easyPG.
Org-crypt needs more documentation to point to the other two as well as
provide a simple example to help people know if they are on the right
>>> What is your use case where you need multiple symmetric encryption keys
>>> in one file?
>> One broken key doesn't give up the whole file.
> That might be a false sense of security. The big weakness with symmetric
> encryption is they key/passphrase. It suffers from the same problem of
> passwords (which are mostly 'human'). If one of your keys is weak enough
> it has been broken, the odds are pretty high that the others will be as
> well. The likelihood with symmetric encrytion is higher because
> everything is based on the key/passphrase you supply. With asymmetric
> encryption, the key is not related to the passphrase. To breach the key,
> someone needs to either get hold of the private key and the passphrase
> (assuming it has a passphrase, which is normal practice for secure
> setup) or they need to crack the very strong key.
> For that use case, I would use asymmetric rather than symmetric
Hmm. Point taken. I have to work on understanding asymmetric
encryption with org-crypt more.
next prev parent reply other threads:[~2022-06-12 3:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 4:08 org-crypt ? David Masterson
2022-06-11 3:35 ` Tim Cross
2022-06-11 21:29 ` David Masterson
2022-06-12 0:28 ` Tim Cross
2022-06-12 1:37 ` Ihor Radchenko
2022-06-12 3:07 ` David Masterson [this message]
2022-06-12 4:04 ` Tim Cross
2022-06-12 6:19 ` David Masterson
2022-06-12 4:15 ` Ihor Radchenko
2022-06-12 5:55 ` David Masterson
2022-06-14 4:13 ` Ihor Radchenko
2022-06-11 4:17 ` Ihor Radchenko
2022-06-11 21:17 ` David Masterson
2022-06-11 21:46 ` Ignacio Casso
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).