Bug 3129 - No offline encryption/signing is possible
Summary: No offline encryption/signing is possible
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.8.1
Hardware: PC All
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2014-03-28 18:41 UTC by exit
Modified: 2016-01-31 20:40 UTC (History)
0 users

See Also:


Attachments

Description exit 2014-03-28 18:41:14 UTC
In order to improve the security of the PGP email encryption scheme, it is often recommended to store private keys offline. However, this strategy is currently not possible with the PGPinline and PGPmime plugins. The reason:

The PGP plugins sign and encrypt messages immediately before delivery. Therefore, access to private keys is necessary in a situation where the box has to be online.

Remediation: sign and encrypt messages at the time they are queued (by pressing "send later").
Comment 1 exit 2014-03-28 18:43:44 UTC
Actually only the signing of messages is the problem, since encryption does not need private keys...
Comment 2 Ricardo Mones 2014-03-28 19:52:39 UTC
That's not true since you can have a local SMTP server which receives the Claws Mail message while you're offline and delivers it to a smarthost when you go online again. Between both you can remove your private key (presumably in a removable device) from the computer at any point.
Comment 3 exit 2014-04-24 15:04:46 UTC
True, you can in principle use a store-and-forward SMTP proxy. Actually, there is not even an obvious candidate software for such a proxy, at least not for the unix world.

Since Claws mail _does_ in principal support SMTP and allows the user to enter the SMTP login data, the most natural solution is to have the mail sent directly from the mua. By the way, thunderbird/iceweasel _does_ allow offline encryption&signing.
Comment 4 Colin Leroy 2014-04-24 15:15:45 UTC
Actually, Claws Mail does sign the mail when queuing (Send Later).

I don't see what's missing then? Closing INVALID, please reopen if I'm wrong.

(Encryption is done just before sending to allow re-edition.)
Comment 5 exit 2014-05-12 20:21:00 UTC
You're right, offline signing is possible, offline encryption not. I overlooked this possibility and therefore didn't check this possibility when issuing the request.

"Encryption is done just before sending to allow re-edition." This only makes partially sense since re-edition requires the renewal of the signature which involves a hash of the plain text message.

I still think that the requested feature (offline encryption and signing) makes sense and is security-relevant.

I have in mind the following use case: There are two independent systems S1 and S2 of which S1 is regularly online, whereas S2 is always or mostly offline. S1 is used for sending and receiving encrypted emails. S2 is used for reading and composing encrypted emails. To make this possible, the INBOX is regularly moved from S1 to S2, whereas the QUEUE is moved from S2 to S1. (Alternatively, the mail folders reside on a shared disk).

The assumption behind this design is that S1 may be compromised by remote attacks from which S2 is protected by the air gap. All messages pass through S1 in an encrypted state. Both the secret key and the plain texts are accessible in the offline system only.

In the current design, the above security setting is only partially fulfilled: received pass through S1 only in an encrypted state, and the secret key is accessible only in S2, protecting it from being stolen. However, messages to be sent pass through S1 in a signed, but unencrypted state.

For the mentioned reasons, I have reopened the issue.

Anyway I want to say THANK YOU to the developer's team of claws-mail which is a wonderful piece of software I use for more than a decade!!!
Comment 6 exit 2014-05-12 20:22:35 UTC
reopened
Comment 7 Andrej Kacian 2016-01-31 20:40:13 UTC
This has been fixed in 3.12.0 - messages placed into queue are encrypted, and to re-edit them, you need to decrypt them first (if you have the "encrypt to self" option enabled, of course).

See also bug #2965.

Note You need to log in before you can comment on or make changes to this bug.