Use GPG to encrypt journal

[gioele]

Could jrnl use GPG instead of raw AES encryption?

Using the GPG symmetric encryption mode is a better alternative to raw AES, as it is carefully tuned to avoid many classes of bugs that arise from the use of raw AES, see If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong and the comments at https://news.ycombinator.com/item?id=639647.

[maebert]

That's a good suggestions. Although I think the article isn't about AES as such, it's about "don't implement cryptographic primitives yourself".

I'm thinking about switching to cryptography.io for the 2.0 release, which uses OpenSSL on the backend - that also solves a lot of pain people have with running jrnl on Windows. However, that still uses AES at its core.

What specifically would using GPG improve?

[gioele]

Yes, the point is avoiding primitives, but, well, the encryption used by article/conversation as an example of what is supposed to be OK but is in fact broken is the same AES-256-CBC used by jrnl :)

Practically speaking, using GPG means no longer worrying about keychain management (if command line users want encryption you can be used they already have a GPG setup); gaining public-key encryption and signing for free; a standardized format for at-rest messages (no need to have a Manual decryption section, or no need to talk about encryption there); offers many more cyphers to those who prefer other encryption algos.

[maebert]

It's a wildly inaccurate claim that AES in CBC mode is "broken". It's prone to potentially harmful use, I completely agree (and jrnl for example currently uses an inferior key derivation function, which will also change in 2.0).

An important factor in end user cryptography is convenience. This means that

• the crypto libraries must be available on all platforms under permissive licenses
• must be able to be installed along with jrnl at no extra work (ie. user shouldn't have to read a manual on how to use GPG just to use jrnl)
• provide backwards compatibility (after upgrading jrnl, you should always be able to at least import your old jrnl files)

Also, "standardized" format for at-rest messages just means that there's some standard for which there is a manual; the standard I want to implement is Fernet, which addresses all currently known issues in jrnl's encryption scheme and potential pitfalls of AES.

I also don't see how public-key encryption and signing is beneficial to most jrnl users.

I don't mean to just disagree for the sake of it, but I haven't seen a really convincing point for switching from AES go GPG yet.

[maebert]

Closing in favour of OpenSSL in jrnl 2.9

[jonhoo]

I'd be in favor of re-opening this. Offering the option to use gpg encryption and decryption would greatly simplify the life of users who are already using GPG. It eliminates the need to keep and type two passwords (for those users), simplifies tuning encryption preferences, and allows access to the plain text files using standard tools (instead of the documented but unorthodox manual decryption Python script).

[maebert]

Unfortunately, to my knowledge there is no implementation of GPG that can be installed as a dependency on Python, hence GPG would require external libraries. I'm open to this as an option if somebody wants to write the appropriate backend on the 2.0 branch

[jonhoo]

I was imagining GnuPG support to be optional, meaning that you could add an optdepends on python-gnupg, import it only if the config specified to use GPG, and fail with an error if GPG was requested but not installed?

[pv]

The "encryption" in jrnl.sh is anyway easily bruteforceable as it uses a hash function instead of a key derivation function for producing the private key from the password.

[insanerwayner]

Came to look for this feature. I think it would great to have the option to use GnuPG for us users that are already using it. It would definitely be a good way for easy decryption if someday the jrnl project were somehow lost or broken. PGP is a standard that has stood the test of time.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.