search

evpo / EncryptPad

Minimalist secure text editor and binary encryptor that implements RFC 4880 Open PGP format: symmetrically encrypted, compressed and integrity protected. The editor can protect files with passwords, key files or both.
https://evpo.net/encryptpad
Other
437 stars 63 forks source link

key file format #77

Closed medoomi closed 6 years ago

medoomi commented 6 years ago

Love the EncryptPad project. Thanks for all the work that has gone into it!

Quick Q/feature request: Is there a way to be able to use keyfiles made up of non-standard file formats eg. jpg, doc, iso, etc. mainly so that an attacker searching for "*.key" doesn't know immediately which file could potentially unlock an encrypted file.

eg. back when truecrypt was maintained, I believe it simply drew a keyfile from the first however many bits of a file's structure (this could be any file format for obfuscation of the key).

I wasn't sure from reading the documentation of EncryptPad, but am I right in thinking that when I save a file in the *.epd format and select a persistent key location, that they key location is encrypted only by the passphrase (i.e. an intruder would need to guess the passphrase before they could read the persistent key location... but that the corollary of this is also true, that setting a persistent key location makes it possible to locate & so use a key if & when an attacker should guess the passphrase)?

evpo commented 6 years ago

Thanks.

You are correct regarding the *.epd format. The name and location of the key are encrypted. In addition to your scenario, the key can be downloaded from a remote server (https for example) with CURL. The URL can be kept secret.

Currently the code reading keys requires the base 64 format. This will prevent JPG etc from being used as keys. Saying that, if the validation was removed, I don't see why it would not work.

You probably know that you don't have to use the *.key extension. You can rename the key file to anything. You can also pipe a jpg through base64. This will make a valid key:

cat image.jpg | base64 > image_b64.jpg

In the given scenario the attacker will need to test each file for base64 format instead of decrypting each file. Decryption is more expensive but it's not that far away.

I suspect that changing the extension and the size of the key may provide a similar "security through obscurity" solution. What do you think?

medoomi commented 6 years ago

I suspect that changing the extension and the size of the key may provide a similar "security through obscurity" solution. What do you think?

Indeed, that does seem to obtain obscurity better. Thanks so much for your reply & thanks again for your work on the project!