Files received for encryption with PGP are first stored in cleartext and encrypted only at a later stage #672

Closed
fpietrosanti opened this Issue Oct 13, 2013 · 3 comments

Projects

None yet

2 participants

@fpietrosanti
Contributor

Files received for encryption with PGP are first stored in cleartext and encrypted only at a later stage.

This means that a cleartext version of the file (to be later encrypted) is saved in clear-text temporarly, until.

This ticket is to evaluate a solution to this problem, that means not storing files unencrypted on disk if all the receiver need to have encryption.

This is to be considered also while fixing #604

@fpietrosanti
Contributor

There are several possible solutions, each of them with different effort/risks/drawback:

a) Use OpenPGP Client side encryption
This is a major implementation that will introduce a privacy-leak because multi-key encryption leak to Receiver-A that the file has been encrypted with the key of the Receiver-B

b) Use of secure delete functionality for the clear-text file
This is something that's useful but will not fix the problem, because also a secure wipe could leave trace of the file into the filesystem

c) Use a temporary, volatile key to store that "clear-text" file to the filesystem
This is a quick solution, storing a volatile key to ramdisk, but it will have as a drawback that due to the volatile (ram only) key if globaleaks server is rebooted before all the pgp encryption operation has been done, it will not be possible to process this file. The likelyhood that this is going to happen is quite low. In presence of encrypted disk, it's possible to avoid storing the temporary key to ramdisk.

d) Use disk encryption for all it's operation like ticket #159
This is a medium effort solution that fix only partially the problem, by providing additional encryption functionalities using Linux Luks. This make the storage of the temporary, volatile key more secure than ramdisk.

IMHO the right order of implementation would be:
1' "b"
2' "c"
3' "d"

@evilaliv3 evilaliv3 was assigned Oct 13, 2013
@fpietrosanti fpietrosanti added the crypto label Feb 6, 2014
@evilaliv3
Contributor

during the 2.54 hackaton we implemented the following solution to the issue:

  • the file encrypted always in streaming using AES with a temporary key stored in ramdisk
  • the file is then decrypted in streaming fo each receiver and encrypted in streaming using receiver PGP key
  • the file is saved in cleartext only if some receivers do not support PGP.
  • the key is currently generated by globaleaks at start and reused against globaleaks restarts (it obviously not survive against server reboot)
@evilaliv3
Contributor

closing the ticket. eventually we may open an enhancement ticket where describe a possible configuration option to avoid file delivery for receivers not enabled for PGP.

/cc @fpietrosanti @vecna

@evilaliv3 evilaliv3 closed this Feb 18, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment