Encryption: Use OpenPGP to de/encrypt files, with Markor compatibility

[lamyergeier]

General information

• App version: 2.7.0
• System: Android 11

Description

Since markor can decrypt AES256 files. I can use GPG instead of the jpencconverter as the output should be compatible.

To encrypt a.md to a.md.gpg I do:

gpg --symmetric --cipher-algo AES256 --output "a.md.gpg" "a.md"

Compatibility with OpenPGP

Could you please tell us if markor expects files to be compatible with Openpgp?

Compression Algorithm

By default gpg uses zip for compression. And whether Markor expects the encrypted file to be uncompressed or zip or zlib compressed?

File naming convention

Also, what extension of encrypted file is supported my Markor? If you can tell me this then I could use same file naming convention with gpg. Or is it that the encrypted file should also be called as a.md (above example)?

Note

I am unsuccessful in using GPG encrypted file with Markor, if you could tell me the above I might be able to use same settings with GPG.

[lamyergeier]

gpg is just a software. If the same encryption algorithm (with same parameters) is used with any tool that should generate the same result. Isn't it?

[opensource21]

You can't encrypt/decrypt the files directly with gpg, because it's an container format, described here. So before the encrypted bytes there is always some bytes with further information to enable different encryptions.
However what is the motivation to do it with gpg?

[lamyergeier]

@opensource21 I saw the link, that you quoted but isn't that describes the file format of your encryption client? (I didn't get it, as you said it describes Gpg format)

Motivation

Gpg is already available in most Linux
The Software has wider userbase and is stable so it is less likely to contain bugs and there are many people who can support it

[opensource21]

As I said it's a container format. So it contains some metadata which different from gpg. It doesn't work out of the box.
I we want to use gpg we must install a lot of extra libs which blow up markor. This was one limitation as I start the implementation.

About security: Both gpg and aes can be used in an unsecure way (U001 is weaker for exampl). That was the reason why I studied twice all recommendations about encryption. I'm unsure if symmetric use gpg will end in a weaker encryption. However, it's possible to use gpg for the encryption part of the container format (We must define a V002 or G001). Then the whole stuff can be done with default linux-tools, but I don't see the advantage so that it's fine to increase the size of the program.
Another approach would be to find out how to use the same algorithm for password derived key and then for encryption. Perhaps this doable, but I won't waste my time to analyse gpg just to do the work with a different tool. Would be much nicer to finish #1375, but I don't know if you would except PR for it.

[gsantner]

Some input from me:

• We don't plan to add another type of encryption currently. One type/format is enough for people, and Markor not has the ressources to support everything people want.
• As said, Markor uses AES256, with some header bits of metadata. If you want to decrypt with whatever software (GPG client, OpenSSL client)... you need to strip those bits. If you need to encrypt data, use AES256 with parameters from above. You also need to generate and prepend the metadata at the file to be readable at Markor.

[acronymy]

Much of this discussion is admittedly over my head but users come with different abilities so will comment and ask here anyway.
I find it disappointing that Markor needs this obscure jpencconverter to encrypt and decrypt files, is it cli for desktop only?
I also think it would be awesome to be able to symmetric encrypt a file that I could decrypt using Openkeychain on Android and gnupg on Linux.
Markor question:
If I create an encrypted file in Markor and then change my password in Markor settings, is the password to decrypt the same as the first one or is it now the second one?

[clach04]

@acronymy if you want a "common" format, you'll need to implement that yourself. My 2 cents, it's easy to misuse complex crypto software like GPG. The advantage of the current format is that it is extremely easy to use with little risk of misuse.

RE https://github.com/open-keychain/open-keychain - be aware it's not actively maintained.

I share your concern over having other tools that are compatible, so I wrote my own ;-) Which I use on desktop (Windows and Linux) in the command line.

My only critic / concern I would have over the jenc format today is that the KDF uses 10000 iterations. OWASP recommends more than that today - see https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#using-work-factors (as of today 210,000 iterations is the recommendation for PBKDF2-HMAC-SHA512, i.e. an extra 200K!).

@opensource21 and @gsantner where is a good place to discuss changes to KDF? I think the current KDF is fine, but we ought to consider a new format version (V002?) same as the current v001 but with a higher iteration count.

As always, thank you @gsantner for such an awesome tool 🙏

[clach04]

Opened #2471 as a follow-up.

[gsantner]

Thanks for your reply, I responded at that thread