From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id baw+JbU/pWLpRgEAbAwnHQ (envelope-from ) for ; Sun, 12 Jun 2022 03:21:57 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id QCJmI7U/pWLizQAAG6o9tA (envelope-from ) for ; Sun, 12 Jun 2022 03:21:57 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0E6E7230A for ; Sun, 12 Jun 2022 03:21:57 +0200 (CEST) Received: from localhost ([::1]:39404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0CId-0007am-Ow for larch@yhetil.org; Sat, 11 Jun 2022 21:21:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0CHv-0007aT-5a for emacs-orgmode@gnu.org; Sat, 11 Jun 2022 21:21:12 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:37735) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0CHs-0003gq-D0 for emacs-orgmode@gnu.org; Sat, 11 Jun 2022 21:21:10 -0400 Received: by mail-pf1-x42e.google.com with SMTP id bo5so2747642pfb.4 for ; Sat, 11 Jun 2022 18:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=fCmTKhKKjiAnYQ60Zn8ZrgBej2GioM+X1lVmgCkS4+Y=; b=BCAkZkLp8Y7lHMhOfRd7KwCyVJeyrTZQYoSIineBmSBikjHwBktxacjAXmVBVSpZWw G0oDyQP02xxlvzlRkCeF7JaADdELT2mT8HkEG3G6K6xPL0GRaUprt1EpLCSKHm4vi8Hq R0x1uYi9QnT0vyNVY2RimEclnGkCA98g/rW3xLStpfrTRqJ+5KPoHdr6AKBsbvN+MIfB V3ra0qd2TH39V9qvEH5U9uwJXGtVpNuDHw1eAQeuhGMHhzCdYvGIE+wLB+KntKUFI3eY FCV08yPmxLb/Qo1mXj7yCbhCmIEkbRh7pwLb9aPZy3Uoa2YsKQpUhsSs+Q53ClcRxnsA bK5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=fCmTKhKKjiAnYQ60Zn8ZrgBej2GioM+X1lVmgCkS4+Y=; b=cEK+53y7d4gYzaRk1B2MZhhIIGOneb6wxI6cXE50ElQLbnZbEgVUCs2zctKhLuU4+O ZzILKFSxBT1cg5heB/I/0yg3XqLuplRVNgmw10Pbq3oWZpOXBZYUPZ4luH+bbtWu1Qhg DxfLqfJzullviI2vcfNnS0I7HZAETBbvwv5Nubx98ZoPUvSA78tAZ31IoDInoFutUcRY 3sIjRpEDKt8tsvF8CS1CxWtHT0MG0hRTtC9PhBmhlar8PcQwwmv1vOBqvFiJVpEK+7MS SXcpdZh3vBTTAmEKyrNWQnzHKfX21X2jFOfhOQQoHxeIZOIAtNmKnohTQ1rJKILm/CFG TBDg== X-Gm-Message-State: AOAM531tjQSDSy8ps8HEl01gKOXCtqzPT4DvMIu7u/v3wyJKkFt5Aj1b YA/kOOYmYbgkuqW2l1j99UGkL022zu4= X-Google-Smtp-Source: ABdhPJxk/VlXFjWqx1kyNPb+FSG76FLwt5ifq4Qyku6xZQZBCERB3A0sMDmVYl4HPrPP2Dqe2LFMwA== X-Received: by 2002:a05:6a00:230d:b0:4f6:ec4f:35ff with SMTP id h13-20020a056a00230d00b004f6ec4f35ffmr53210640pfh.53.1654996866189; Sat, 11 Jun 2022 18:21:06 -0700 (PDT) Received: from dingbat (2001-44b8-31f2-bb00-63fa-329c-dbc6-d47e.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:63fa:329c:dbc6:d47e]) by smtp.gmail.com with ESMTPSA id 1-20020a621901000000b00518e1251197sm2264295pfz.148.2022.06.11.18.21.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jun 2022 18:21:05 -0700 (PDT) References: <871qvvesqh.fsf@gmail.com> User-agent: mu4e 1.7.27; emacs 28.1.50 From: Tim Cross To: David Masterson Cc: emacs-orgmode@gnu.org Subject: Re: org-crypt ? Date: Sun, 12 Jun 2022 10:28:47 +1000 In-reply-to: Message-ID: <871qvuy8vn.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654996917; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=fCmTKhKKjiAnYQ60Zn8ZrgBej2GioM+X1lVmgCkS4+Y=; b=DXCuAzhuZeAvXpP+0uIBPM+yOMhEm9pe6J99ta+f3pGWypq4RELUEZcshUfWZbTmnrgyks YwS7hMPGm/4Wosi9nUbYdTEE+RF5+b35ebbEQgduf1EGZwoE7RuEmmrt+RU2S/X8cXCDsv Wt6VpsfJb/AtTf7dufKs/KuJCiarLWDYzgEVeIqH9yuZZtRyKBR08FaIIiW9XyfLzU7XV2 5b6BZJoJdaij79zmyOIsvljOfmAzg/6NCLf44YhfFJnqddRs9plGMtePWuptdmU4TU13JF Y5Hkz1W857uimxVH9Y/DD76lKX6Ah9FBUSMDFTJbBDO/3fjUNCEmZwHtpuvd/A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654996917; a=rsa-sha256; cv=none; b=pceIbGtSkukoweY0ypDQjJrcjbuDm8A22fj24K4VBOXU8WqHH7gO+3JsoLRRHKY6MBv7yj tEzCp/RGzostWJN/pFmOXX156XDXr/NXV2y3x48qbxbrBLaG4LylqP8S3ilwGEDAIJUqNf pJhhIDrZe32jQGtFJ1vdI1W9N21ERIJcTmRw2dqetIV5rprpuEAtRKmLqtb3j78ZwJNzTx dRaNRy2dWKje8AKVplfY275cRxLzyle1dZqF1tFEd/+g0DUZ9Ho+JDppKx8CF1XG2WfuiS 3pJhHj/udXLKgMYF8uIGrdjtErtlUCtTO+zvc3vg/hSMlnuIZ+SiL1uOHwCJYg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BCAkZkLp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.98 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BCAkZkLp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 0E6E7230A X-Spam-Score: -2.98 X-Migadu-Scanner: scn1.migadu.com X-TUID: dWNTwfHCeXGj David Masterson writes: > Tim Cross writes: > >> David Masterson writes: >> >>> I think I've gotten org-crypt working, but I think some things are not >>> making sense (it might be just me): >>> >>> 1. I've set org-crypt-key to nil (symmetric encryption). >>> 2. Can I use a different encryption key for each encrypted paragraph? >>> 3. Does org-encrypt only ask for the key the first time? >>> 4. Does org-decrypt only ask for the key the first time? >>> 5. How do they know where to get the password when they don't ask? >>> 6. Shouldn't org-crypt docs in org manual have examples? >>> Does this make sense -- I think I'm messing something up. >> >> 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. >>> 2. Can I use a different encryption key for each encrypted paragraph? >> >> According to the manual - >> >> No, not with symmetric encryption. I think this can only work with >> asymmetric encryption. > > This needs to be spelled out better. Ihor's response to this indicates I'm incorrect here. As I stated earlier, it has been a long time since I used org-crypt, so I'd trust his advice more. However, from a technical perspective, I don't understand how gnupg or org-crypto can prompt to get the different keys and know which chunk to apply which key to, but that is my limited technical expertise more than anything else. With asymmetric encryption, you specify the key name, so it knows which key belongs with each encrypted chunk. I don't see in the code how this is handled for symmetric encryption where no key name is specified. With symmetric encryption, the key is really just the passphrase. GnuPG asks you for the key (passpharase) and it uses that to encrypt/decrypt the data. With asymmetric, there is a public and private pair and an associated 'name'. When encrypting, it knows or asks for the key name and uses the public key and for decrypting, the private key, which most often (but not always) has a passphrase used to unlock it. > >> If your using symmetric encryption, you typically just have one key for >> all the data within the file. From the gnuPG perspective, this is just >> encrypted text. It does not 'know' about different paragraphs. To have >> different encryption with each paragraph, you would need to specify >> different keys and there is no mechanism to do that with symmetric >> encryption only asymmetric. > > org-(en/de)crypt ?? 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). 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, whihc 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 information. - org-crypt, which is a very light-weight wrapper around the epg functions. It provides the basic integration between org and easyPG. >> 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 encryuption. >>> 6. Shouldn't org-crypt docs in org manual have examples? >> >> Probably, though I don't know what else you would put in there which >> isn't already there. Feel free to supply a PR or patch once you have >> worked it out. However, as noted in the commentary section, org-crypt.el >> is really a very light-weight wrapper around functions in epg.el, so >> likely the first place to start when looking for documentation and >> examples is the epa/epg/easyPG manual > > Not good at writing these days, buy I'll consider. Please do. Often the best documentation comes from end users rather than developers. The developer is often too close to the code, which makes it harder for them to appreciate what users don't understand/know. For a user, the challenges they encounter are often 'fresher' and puts them in a better place to explain things. People on the list will provide feedback to help clarify and improve what you write. I would highly recommend looking at the easyPG and gnuPG documentation. It is quite likely all that needs to be done to improve the documentation is add some appropriate links to the documentation for those two projects.