cryptee / web-client

Cryptee's web client source code for all platforms.
https://crypt.ee
Other
444 stars 22 forks source link

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

Open dhda opened 4 years ago

dhda commented 4 years ago

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.

johnozbay commented 4 years ago

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

johnozbay commented 4 years ago

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)

dhda commented 4 years ago

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 😆

johnozbay commented 4 years ago

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