web-client icon indicating copy to clipboard operation
web-client copied to clipboard

[Change] Don't use aead_protect for ECD exports / imports

Open dhda opened this issue 4 years ago • 4 comments

Cryptee uses Openpgpjs's aead_protect mode: https://github.com/cryptee/web-client/blob/51cd8bc43216f18a612a9cdab0a40a4dd146fa28/source/js/main.js#L1103

This is not a standardized PGP feature: https://github.com/openpgpjs/openpgpjs/blob/c6ed05d2c34828fe8d3249e74c6afc4ba5c8eed0/src/config/config.js#L48-L50

Other implementations don't support it, and different versions of openpgpjs aren't even guaranteed to have consistent support for it. I understand that there can be performance benefits in using this mode, but when I'm exporting docs I care about data portability above all else. I want to be able to decrypt the exported docs using gpg from the command line. With docs encrypted using aead_protect, this isn't possible–they're basically useless without figuring out how to get my own openpgpjs running. It took me a while to figure out why it wasn't working–GnuPG 2.2.20 (newest) fails silently and the only indication of the failure comes through directly inspecting all the packets.

So my request is that exported ECDs be encrypted using only fully standards-compliant PGP modes, regardless of what Cryptee is using internally.

dhda avatar Jun 16 '20 11:06 dhda

That's a fantastic suggestion, and I'll start building towards this right away for ECD exports & imports! 👍🏻

johnozbay avatar Jun 16 '20 14:06 johnozbay

P.S. – as far as portability goes, AES GCM (Galois/Counter Mode) isn't a part of OpenPGP standard, and may not be in future versions of OpenPGP itself, but that doesn't mean AES GCM itself isn't future-proof or any less usable. In fact it's one of the 6 different authentication modes standardized in ISO/IEC 19772:2009.

You should be able to open ECD files using any cryptographic toolkit that supports AES GCM, as far as portability is concerned. So you actually don't need PGP per-se.

And for now we don't use any asymmetric encryption, since we still haven't enabled any of the sharing features yet – but eventually we will, and that's the reason why we've been using OpenPGPjs with Cryptee.

Back when I started building Cryptee, browsers' built in crypto wasn't great, so having a library like OpenPGPjs was a great way to polyfill on some browsers. Nowadays browsers have great native crypto support (albeit most browsers are still not that great at parallel threading it using workers) – so in theory, we could get rid of OpenPGP altogether, and technically use just AES GCM once browsers get better at native crypto in workers and resource consumption on low end devices.

(at least until we enable sharing features – then that's a whole different story)

johnozbay avatar Jun 16 '20 14:06 johnozbay

P.S. – as far as portability goes, AES GCM (Galois/Counter Mode) isn't a part of OpenPGP standard, and may not be in future versions of OpenPGP itself, but that doesn't mean AES GCM itself isn't future-proof or any less usable. In fact it's one of the 6 different authentication modes standardized in ISO/IEC 19772:2009.

You should be able to open ECD files using any cryptographic toolkit that supports AES GCM, as far as portability is concerned. So you actually don't need PGP per-se.

I don't have enough time in my life to de-armor the pgp message, manually parse the packets, and manually feed them into another tool that supports AES-GCM, though 😆

dhda avatar Jun 18 '20 09:06 dhda

Hahah that's all super fair! I'm going to make this happen as quickly as possible! 👍🏻

johnozbay avatar Jun 18 '20 12:06 johnozbay