GNOME Bugzilla – Bug 325803
Symmetric file encryption (without keypair)
Last modified: 2016-08-02 15:16:58 UTC
It's already possible to decrypt files encrypted with symmetric encryption by double-clicking on them and enter the passphrase. It would be nice to also be able to encrypt files in the same manner.
Right click and select "Encrypt..." from the context menu. You should then be presented with a dialog asking for the intended recipients. I'm closing this, but if you don't have "Encrypt..." in your nautilus context menu, check to make sure seahorse is installed in the same prefix as the rest of your GNOME install. Also try running mime-database-update. Please reopen the bug if none of the above works with details of your distribution and GNOME version.
I'm talking about _symmetric_ encryption. Right-clicking works fine in Nautilus, but I can only choose to encrypt using a key. What I meant above was that the Decrypt command when double-clicking on an encrypted file is capable of decrypting both symmetrical and assymetrical (private/public key) encryption. seahorse should be capable of also encrypting without a keypair. Reopening. If I'm still not making sense, I'll try to do some more research and come up with a better explanation. :)
OK, I looked at the gpg man page and think I understand what you're getting at. I'm afraid this might confuse a lot of users who aren't familiar with encryption. Under the principle of sensible defaults, this might be a good thing to make enableable in the preferences, but not by default. Is this something you would want to choose between symmetric/pulic key encryption on the fly? If so that would require a different sort of UI to use this feature.
Symmetric encryption is effective when dealing with file encryption. You can use this to password protect files that you don't want unauthorized users to access. It's more convenient than assymetric encryption, since you don't need to keep any secret or public keys safe. You just need to remember the passphrase. The encrypted data is not meant to be sent over the net and shared with another people. Asymmetric (the normal keypair) encryption, on the other hand, is perfect for communication between two or more persons. From a security point of view, this is like handing out your secret key to people: they will be able to decrypt your data if (and only if) they know the passphrase. Basically, the key is "built in" when using symmetric encryption. So that's the rationale and use case. About the user confusion, I can only speak of my own experiences with this, and I must say I find asymmetric encryption with public and private keys much harder to grasp than a simple password protection. :) Yes, choosing between normal asymmetric and symmetric encryption should be selectable from the dialog that pops up when you right-click a file and select Encrypt. However, the terms shouldn't be exposed, as they're only confusing. A simple checkbox under the list of available keys to encrypt to should be enough. That checkbox, if ticked, should disable the listbox to visually inform the user that the option is mutually exclusive with the keys encryption. The label of the checkbox would be something like this: "Encrypt data using passphrase only." If you looked at the man page, you know that something along the lines of 'gnupg -c' should be used.
I like that idea. Put the option in the 'Key Selection' dialog. Something like: o Encrypt using a simple password o Encrypt to the recipients selected below: This only makes sense for the nautilus extension though. This may also be a bit more difficult to implement because GPGME (at least last time i looked) didn't support symmetric encryption. But I think this does make sense for users.
Created attachment 56795 [details] Simple mockup of changed UI Here's an example of how the UI could look like. I tried to show that the list of available keys should be grayed out, but I'm not sure if the picture does it justice. Gimp and I don't play well together.
I second the request. Understanding public/private key encryption is harder than understanding passphrase-only encryption and in a lot of use cases the latter is sufficient. Unfortunately, passphrase-only encryption is less secure. This should be made clear to the user on the GUI. The GUI should look like this: +-------------------------------------------------------------+ |[] Choose encryption method [X] | +-------------------------------------------------------------+ | (*) Choose recipients who will be able to decrypt the file: | | ___________ __________ | | [All_keys__v] Search for: [__________] | | | | +--+---------------------------------------+----------+ | | | | Name | Key ID | | | +--+---------------------------------------+----------+ | | |[] Blahblah <blah@blah.com> ABCDEFGH | | | |[] ugugugug <ugug@blah.com> BCDEFGHI | | | | | | | +-----------------------------------------------------+ | | _________________ | | ( ) Use passphrase only : [_________________] | | | | Note: Everybody knowing or guessing your password | | will be able to decrypt the file. Thus, | | security only depends on the strength of the | | chosen password. This method is less secure | | than using the option above. | | ---------------------------------------------------------- | | _______________________________________ | | Sign message as: [_None_(Don't_Sign)____________________v] | | | +-------------------------------------------------------------+ | +----------+ +---------+ | | | X Cancel | | <-' OK | | | +----------+ +---------+ | +-------------------------------------------------------------+ Sorry for the ugly ascii art ;) Using radio buttons should make clear that these options are mutually exclusive. Choosing passphrase-only encryption would gray out/disable the controls above.
The option for _symmetric_ encryption is absolutely vital. KGPG and many Win32 front-end for GnuPG have already implement this feature via their GUIs. As the only front-end for GunPG on Gnome which integrates with Nautilus, Seahorse should really consider this enhancement. +-------------------------------------------------------------+ |[] Choose encryption method [X] | +-------------------------------------------------------------+ | (*) Choose recipients who will be able to decrypt the file: | | ___________ __________ | | [All_keys__v] Search for: [__________] | | | | +--+---------------------------------------+----------+ | | | | Name | Key ID | | | +--+---------------------------------------+----------+ | | |[] Blahblah <blah@blah.com> ABCDEFGH | | | |[] ugugugug <ugug@blah.com> BCDEFGHI | | | | | | | +-----------------------------------------------------+ | | _________________ | | ( ) Use passphrase only : [_________________] | | | | Note: Everybody knowing or guessing your password | | will be able to decrypt the file. Thus, | | security only depends on the strength of the | | chosen password. This method is less secure | | than using the option above. | | ---------------------------------------------------------- | | _______________________________________ | | Sign message as: [_None_(Don't_Sign)____________________v] | | | +-------------------------------------------------------------+ | +----------+ +---------+ | | | X Cancel | | <-' OK | | | +----------+ +---------+ | +-------------------------------------------------------------+
I've just noticed that Seahorse (as of version 1.0.1) has support for decrypting symmetrically-encrypted files, so hopefully the backend code is already in place.
(In reply to comment #9) > I've just noticed that Seahorse (as of version 1.0.1) has support for > decrypting symmetrically-encrypted files, so hopefully the backend code is > already in place. > The back end is gnupg, so yes it's already in place. The problem, I guess, is no one's working on the front end.
Hi! Is there any news on this one? Do you plan on targetting this for 2.26? Thanks.
I'd be interested as well. Symmetric encryption is very useful to me, sometime I must copy files on USB key, CD-R or others storage who could be lost or stolen and access to those files from machines where I can't or don't want to have a copy of my private key.
(In reply to comment #10) > (In reply to comment #9) > > I've just noticed that Seahorse (as of version 1.0.1) has support for > > decrypting symmetrically-encrypted files, so hopefully the backend code is > > already in place. > > > > The back end is gnupg, so yes it's already in place. The problem, I guess, is > no one's working on the front end. > It's not just the "front end", a new gpgmex_op_ function needs to be written to support symmetric encryption by calling gpg directly since it isn't supported by gpgme. Much of the proposed UI is fine for encryption of files, although the proposed dialogs may be too large for small screens. The kicker is that that dialog comes from libcryptui and is used across all of the users (mostly other seahorse plugins) which a symmetric option probably doesn't make sense. Some effort needs to be taken to properly extend the UI in a manner that doesn't lead to function/argument creep.
(In reply to comment #13) > It's not just the "front end", a new gpgmex_op_ function needs to be written to > support symmetric encryption by calling gpg directly since it isn't supported > by gpgme. gpgme supports symmetric encryption through gpgme_op_encrypt(): If recp is NULL, symmetric rather than public key encryption is performed. Symmetrically encrypted cipher text can be deciphered with gpgme_op_decrypt. (source: http://pyme.sourceforge.net/doc/gpgme/Encrypting-a-Plaintext.html#Encrypting-a-Plaintext)
In that case it's pretty easy to implement since I've been wanting to finish bug 415268 - "Always include myself as a recipient" should mark key in encryption dialog. Then if you just unselect yourself as a recipient and hit encrypt, seahorse-agent ought to take care of prompting for the passphrase to encrypt with. No extra UI needed (maybe a radio button, we'll see), but an entry in the manual will need to be made.
*** Bug 658368 has been marked as a duplicate of this bug. ***
The idea of having it only perform symmetric encryption when a user is not selected keeps the functionality completely opaque from the user. Infact the user may not in fact even realised what has happened. A user not in the know and selecting "Encrypt..." for the first time is more likely to expect symmetric rather an assymetric as it's more likely to be familiar to them from Windows. Both options should be presented in a clear way in the UI.
I can provide a "first time user" anecdote: tl/dr: this is a really good idea. I just became interested in encryption. I'm young, but starting to fill out a lot of legal papers (taxes/banks/etc). I often need my SSN or SIN but can never remember it. I've started to keep a text file called "numbers" in an obscure folder on my hdd with this type of information. Obviously this type of "hiding" would cause nerd-rage, but it's what a lot of people do (I think it's equivalent to hiding a box in the attic - the only type of "encryption" people are born knowing). It didn't take long to learn "gpg -c" from Google, but I had (have?) no idea what "symmetric" means, other than it's not "asymmetric". Anyway "gpg -c" does exactly what I want, as long as I open the terminal every time I want to read or edit the file. Thinking there must be an easier, non-terminal way, I come across seahorse-plugins. Find a PPA (I'm on Ubuntu) and great! Now I can decrypt my "numbers.gpg" by just clicking. I open it, edit it, right click and "Encrypt..." It just didn't work. Do some more research...blah blah...create a public/private key using seahorse. This is not something my dad would be able to do. Now Encrypt/Decrypt work from Nautilus but there's a number of things wrong: -I'm not prompted to enter my password to decrypt a file. Doesn't exactly scream "secure". Maybe you only need to be logged in to decrypt? That's bad because my login password (an album name) is easy and known to a few of my friends. The password I want to encrypt and decrypt with is known to me only and is 12+ characters without any words and with symbols all over the place. -I have no idea what the "name" "email" and "comment" are for. I'd guess it's for emailing things to people, but I will never email this file to people. -What happens if I want to open this file from a different computer (i.e. Windows)? I have no idea if I can. -I have no idea what these "keys" are, but they're really long, I can't remember them, and what happens if I lose them? Again, I have no idea. -I tell my girlfriend some things about what to do if I were dead or unconscious and needed help - things like "I'm an organ donor". With her (my?) life dependent on it, I couldn't trust her to figure out all this private/public key sh*t...especially if she was trying to open "numbers" on her Mac. As a home user, I find no reason not to _default_ to symmetric encryption, but clearing this bug is certainly the first step.
FWIW, GPGME now appears to support symmetric encryption, by passing NULL as a set of recipients to gpgme_op_encrypt. See here: http://www.fifi.org/cgi-bin/info2www?(gpgme)Encrypting+a+Plaintext
Created attachment 246541 [details] [review] Add symmetric encryption as a choice in "choose recipients" dialog Patch for libcryptui
Created attachment 246542 [details] [review] Add cryptui_need_to_get_keys_or_symmetric() Patch for libcryptui.
Created attachment 246543 [details] [review] Add support for symmetric encryption in seahorse-tool Patch for seahorse-nautilus.
The three attached patches (two for libcryptui and one for seahorse-nautilus) implement symmetric encryption in seahorse-tool. The visual design is close to the mockup in comment #8 except that the passphrase is asked on subsequent windows (by the default libcryptui handler). We also handle the case where no public key is available and offer symmetric encryption as an alternative to create/import public keys.
When I apply this patch, I get the following error: [stef@stef seahorse-nautilus]$ tool/seahorse-tool --encrypt README ** ERROR:seahorse-vfs-data.c:183:vfs_data_open_done: assertion failed: (ah->operation == VFS_OP_OPENING) Aborted (core dumped) I selected the passphrase encrypt radio option. FWIW, the design doesn't look that great (even though I was the one who recommended it long, long ago). It's hard to associate the two radio buttons since they're so far apart. Moving the Passphrase option first, might solve that problem well enough to commit the patches, although would still look rather awkward.
Review of attachment 246541 [details] [review]: Thanks for working on this, by the way. A bit of code review... This needs work related to the design, noted above. ::: libcryptui/cryptui-key-chooser.c @@ +173,3 @@ + + g_signal_connect (radio_public_key, "toggled", + gint indicator_spacing = 0; Missing space. @@ +244,3 @@ + gtk_container_add (GTK_CONTAINER (vbox), scroll); + gtk_box_set_child_packing (GTK_BOX (vbox), scroll, + TRUE, TRUE, 0, GTK_PACK_START); Spacing, and similar on function calls below. @@ +248,3 @@ + if (support_symmetric) { + margin_box = gtk_box_new (GTK_ORIENTATION_HORIZONTAL, indicator_size + indicator_spacing); + gtk_container_add (GTK_CONTAINER (margin_box), gtk_label_new (" ")); This seems strange. Why not use a GtkAlignment? ::: libcryptui/cryptui.c @@ +163,3 @@ * @title: Window title for presented GtkWindow * @signer: Variable in which to store the key of the signer if one is selected + * @symmetric: Variable in which to store if symmetric encryption is requested Need to document the side effect that passing NULL here disables possibility to select symmetric encryption. FWIW, it seems like an awkward way to represent the flag.
Review of attachment 246542 [details] [review]: Is this function actually used by anything?
Review of attachment 246542 [details] [review]: Scratch that, I see that it is used by seahorse-tool. Looks good to be committed once other patches are ready.
Review of attachment 246543 [details] [review]: Looks good, but seems to cause problems with the abort() noted in an earlier comment. ::: tool/seahorse-tool.c @@ +161,2 @@ gchar *signer; May want to "g_assert (symmetric != NULL);" as a clear indication of how this function is expected to be called.
Created attachment 247317 [details] [review] Add support for symmetric encryption in seahorse-tool (v2) Assertion added in prompt_recipients().
Created attachment 247321 [details] [review] Add cryptui_need_to_get_keys_or_symmetric() (v2) Fix a whitespace issue.
Created attachment 247322 [details] [review] Add symmetric encryption as a choice in "choose recipients" dialog (v2) Whitespace issues should have been fixed. I have replaced the extra margin_box by simply using gtk_widget_set_margin_left(). The margin calculation are probably saner as well. NULL behaviour for the symmetric argument of cryptui_prompt_recipients() has been documented.
(In reply to comment #24) > When I apply this patch, I get the following error: > > [stef@stef seahorse-nautilus]$ tool/seahorse-tool --encrypt README > ** > ERROR:seahorse-vfs-data.c:183:vfs_data_open_done: assertion failed: > (ah->operation == VFS_OP_OPENING) > Aborted (core dumped) > > I selected the passphrase encrypt radio option. I am not able to reproduce this. :( Could you describe more of your test environment? > FWIW, the design doesn't look that great (even though I was the one who > recommended it long, long ago). It's hard to associate the two radio buttons > since they're so far apart. Moving the Passphrase option first, might solve > that problem well enough to commit the patches, although would still look > rather awkward. I've done that in this second version. UI design takes many experiments. :)
Pushed patches to libcryptui, with some fixes. There were critical warnings when opening the chooser dialog. In addition the tests did not build.
Oops, I didn't apply the seahorse-nautilus patches because the issue there remains with the patch: $ tool/seahorse-tool --encrypt /tmp/tmpOMA0DO.d ** ERROR:seahorse-vfs-data.c:183:vfs_data_open_done: assertion failed: (ah->operation == VFS_OP_OPENING) Aborted (core dumped)
Stef, could you please describe your test environment to me? I am unable to reproduce your issue. When trying again on my own (Debian sid) I run into another set of issues though. The most problematic looks related to a race between the GLib main loop and gpgme. I see: (seahorse-tool:2390): GLib-WARNING **: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly. And then the encrypted file is never created. If I replace `gpgme_op_encrypt_start` by `gpgme_op_encrypt` in `encrypt_sign_start`, the file gets encrypted as it should. Any thoughts? Another problem I only spotted now is related to Seahorse agent. When using symmetric encryption, it still calls open_password_prompt() in Gcr and so I'm prompted to "unlock a key", instead of simply entering a passphrase. Pretty confusing. Would you also have an idea about this?
Ok so there's an unrelated issue to this patch. seahorse-tool --encrypt does not work with glib >= 2.35.2 (due to changes introduced in commit ce0022933).
Watch out: specifying symmetric encryption and a signing will only work with gpgme >= 1.4.2. Stef, any suggestion on the best way to handle this?
(In reply to comment #37) > Watch out: specifying symmetric encryption and a signing will only work with > gpgme >= 1.4.2. Stef, any suggestion on the best way to handle this? Lets bump the dependency. Do the latest released versions of most common distros have gpgme 1.4.2 or later?
(In reply to comment #37) > Watch out: specifying symmetric encryption and a signing will only work with > gpgme >= 1.4.2. Stef, any suggestion on the best way to handle this? Actually just checked and Fedora 19 (for example) only has gpgme 1.3.2. Is there any way to make it work with at least some earlier versions? (In reply to comment #36) > Ok so there's an unrelated issue to this patch. > > seahorse-tool --encrypt does not work with glib >= 2.35.2 (due to changes > introduced in commit ce0022933). This is being tracked by bug #697895
(In reply to comment #39) > (In reply to comment #37) > > Watch out: specifying symmetric encryption and a signing will only work with > > gpgme >= 1.4.2. Stef, any suggestion on the best way to handle this? > > Actually just checked and Fedora 19 (for example) only has gpgme 1.3.2. Is > there any way to make it work with at least some earlier versions? For symmetric + signature, we would need to bypass gpgme and spawn gpg directly. I'm not sure that would fit in how seahorse-nautilus currently works… What could be probably done is to detect that gpgme is too old and disable the signature controls when symmetric encryption is selected. What do you think about it?
(In reply to comment #40) > (In reply to comment #39) > > (In reply to comment #37) > > > Watch out: specifying symmetric encryption and a signing will only work with > > > gpgme >= 1.4.2. Stef, any suggestion on the best way to handle this? > > > > Actually just checked and Fedora 19 (for example) only has gpgme 1.3.2. Is > > there any way to make it work with at least some earlier versions? > > For symmetric + signature, we would need to bypass gpgme and spawn gpg > directly. > I'm not sure that would fit in how seahorse-nautilus currently works… > > What could be probably done is to detect that gpgme is too old and disable > the signature controls when symmetric encryption is selected. What do you think > about it? I guess so, but lets try to do it without #ifdefs, rather compiling as much code as possible in both cases, but just setting a flag if it's not supported by the gpgme we're running on. It's fine to use configure time detection, as long as we don't compile completely different code in both cases.