[GH-ISSUE #11] Enhancement: support for PGP (or similar)

kerem commented

2026-02-25 21:33:53 +03:00

Owner

Originally created by @dumblob on GitHub (Jul 30, 2015).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/11

Originally assigned to: @jasonmunro on GitHub.

How much security support is planned for Cypth? There is a growing interest in end-to-end encryption and some new web mail clients try to support PGP (e.g. Mailpile). Roundcube guys have a nice discussion about issues with PGP implementation on http://trac.roundcube.net/wiki/Dev_Encryption and the combined solution seems viable.

Originally created by @dumblob on GitHub (Jul 30, 2015). Original GitHub issue: https://github.com/cypht-org/cypht/issues/11 Originally assigned to: @jasonmunro on GitHub. How much security support is planned for Cypth? There is a growing interest in end-to-end encryption and some new web mail clients try to support PGP (e.g. Mailpile). Roundcube guys have a nice discussion about issues with PGP implementation on http://trac.roundcube.net/wiki/Dev_Encryption and the combined solution seems viable.

kerem

2026-02-25 21:33:53 +03:00

closed this issue
added the
enhancement

imap

new module set

core

smtp
labels

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Jul 30, 2015):

Hm, I'm surprised - there is a pure JS OpenPGP library https://github.com/openpgpjs/openpgpjs . There are some issues, but several larger projects already use it (Mailvelope to name one).

@dumblob commented on GitHub (Jul 30, 2015): Hm, I'm surprised - there is a pure JS OpenPGP library https://github.com/openpgpjs/openpgpjs . There are some issues, but several larger projects already use it (Mailvelope to name one).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Jul 30, 2015):

Security is a huge part of the overall software design, however my focus has been primarily on application and transport level security (http://cypht.org/security.html). I would love to support and end-to-end encryption scheme like PGP. It's been a few years since I thought about PGP in webmail, the main blocker back then being key security. Happy to keep this open and on the list. Thanks for the links - I will check them out when I can!

@jasonmunro commented on GitHub (Jul 30, 2015): Security is a huge part of the overall software design, however my focus has been primarily on application and transport level security (http://cypht.org/security.html). I would love to support and end-to-end encryption scheme like PGP. It's been a few years since I thought about PGP in webmail, the main blocker back then being key security. Happy to keep this open and on the list. Thanks for the links - I will check them out when I can!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Nov 25, 2015):

Recently I found https://keybase.io/ which seems to be worth considering supporting at some point. The purpose is and I quote "The goal of Keybase is to let any security software be powered by usernames instead of offline key exchanges.".

@dumblob commented on GitHub (Nov 25, 2015): Recently I found https://keybase.io/ which seems to be worth considering supporting at some point. The purpose is and I quote "The goal of Keybase is to let any security software be powered by usernames instead of offline key exchanges.".

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dhuyvetter commented on GitHub (Oct 10, 2016):

I'd say Mailvelope: https://www.mailvelope.com/ is the go to browser extension for PGP encryption in webmail. I'm not sure if there is anything needed to make it work with Cypth. I've got Mailvelope and Cypth set up, so I can test and report any issues I come across.

With Mailvelope the advantages of a cloud based web mail solution can be combined with OpenPGP encryption.

I'm not sure what would be the point of implementing PGP on the server, since that would mean you'de have to store your private key server side, which is a huge security risk. Secret keys in the browser are also not too secure, but at least that is on your own computer and not a web facing server.

@dhuyvetter commented on GitHub (Oct 10, 2016): I'd say Mailvelope: https://www.mailvelope.com/ is the go to browser extension for PGP encryption in webmail. I'm not sure if there is anything needed to make it work with Cypth. I've got Mailvelope and Cypth set up, so I can test and report any issues I come across. > With Mailvelope the advantages of a cloud based web mail solution can be combined with OpenPGP encryption. I'm not sure what would be the point of implementing PGP on the server, since that would mean you'de have to store your private key server side, which is a huge security risk. Secret keys in the browser are also not too secure, but at least that is on your own computer and not a web facing server.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Oct 10, 2016):

@dhuyvetter there is one huge issue with Mailvelope - it's a browser extension and thus highly platform dependent. How will I read the email on my Android phone? How about my brother's iPhone? And what about the Ubuntu tablet of my father? Oh and I forgot, my sister moved to Finland, bought a new phone with Sailfish OS and also wants to communicate with me securely through email.

I'm not sure what would be the point of implementing PGP on the server, since that would mean you'de have to store your private key server side, which is a huge security risk. Secret keys in the browser are also not too secure, but at least that is on your own computer and not a web facing server.

The proposal has nothing to do with server side PGP encryption. The proposal is about integrating some JS library and providing platform agnostic client side PGP encryption.

@dumblob commented on GitHub (Oct 10, 2016): @dhuyvetter there is one huge issue with Mailvelope - it's a browser extension and thus highly platform dependent. How will I read the email on my Android phone? How about my brother's iPhone? And what about the Ubuntu tablet of my father? Oh and I forgot, my sister moved to Finland, bought a new phone with Sailfish OS and also wants to communicate with me securely through email. > I'm not sure what would be the point of implementing PGP on the server, since that would mean you'de have to store your private key server side, which is a huge security risk. Secret keys in the browser are also not too secure, but at least that is on your own computer and not a web facing server. The proposal has nothing to do with server side PGP encryption. The proposal is about integrating some JS library and providing platform agnostic client side PGP encryption.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Oct 12, 2016):

Thanks to everyone for the feedback. I used Mailvelope with Cypht today, worked fine. It didn't require any code changes, though the workflow was clunky at best, especially when reading an encrypted message. After reading a few RFCs, I think SMIME would be awesome to support, but WOW that would be hard to get right, especially from a webmail context.

I want to target the minimum required features to get this going, and I also don't want to rely on the presence of a browser extension. I think doing something simple like Mailvelope does but as a module set would do the trick:

Add controls to the compose page to sign/encrypt, and use the gnupg PHP extension to do the work before sending via SMTP. If we felt like this needs to happen in the JavaScript, we could leverage opengpjs.
Add controls to the message view to use opengpjs to view and verify encrypted message parts. This way we never have the private key on the webmail server. We could optionally store it in the browser local session storage (and the key password) while logged in. For security (and simplicity) reading and writing encrypted message parts would only be available for plain text messages.
Simple-as-possible public key management. Maybe public keys can be assigned to contacts, or maybe we store them independently. I'm leaning towards separate storage. We need standard management type stuff + import/export/generate would be nice.

I'm sure there is a lot more I'm not considering, but hopefully this will be enough to get the ball rolling. Additional feedback is always welcome!

@jasonmunro commented on GitHub (Oct 12, 2016): Thanks to everyone for the feedback. I used Mailvelope with Cypht today, worked fine. It didn't require any code changes, though the workflow was clunky at best, especially when reading an encrypted message. After reading a few RFCs, I think SMIME would be awesome to support, but WOW that would be hard to get right, especially from a webmail context. I want to target the minimum required features to get this going, and I also don't want to rely on the presence of a browser extension. I think doing something simple like Mailvelope does but as a module set would do the trick: - Add controls to the compose page to sign/encrypt, and use the gnupg PHP extension to do the work before sending via SMTP. If we felt like this needs to happen in the JavaScript, we could leverage opengpjs. - Add controls to the message view to use opengpjs to view and verify encrypted message parts. This way we never have the private key on the webmail server. We could optionally store it in the browser local session storage (and the key password) while logged in. For security (and simplicity) reading and writing encrypted message parts would only be available for plain text messages. - Simple-as-possible public key management. Maybe public keys can be assigned to contacts, or maybe we store them independently. I'm leaning towards separate storage. We need standard management type stuff + import/export/generate would be nice. I'm sure there is a lot more I'm not considering, but hopefully this will be enough to get the ball rolling. Additional feedback is always welcome!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Oct 12, 2016):

@jasonmunro this whole proposal has low priority, so no hurry.

S/MIME is nice, but still not end-to-end, so it's not worth it IMHO (encryption effectively "disables" searching, so when one want's to torture her/himself with such a constraint, then she/he wants to have it end-to-end and not server-side). By the way, S/MIME encrypted email of yours can be decrypted by all authorities issuing the SSL certificate for you. So it's anyway not secure enough by design.

With regards to your three-point proposal, the biggest question is how to store and work with keys on the client side. There is definitely some standard or at least recommendation from NIST, but I didn't look it up. Will take a look soon (now it's too late at night).

@dumblob commented on GitHub (Oct 12, 2016): @jasonmunro this whole proposal has low priority, so no hurry. S/MIME is nice, but still not end-to-end, so it's not worth it IMHO (encryption effectively "disables" searching, so when one want's to torture her/himself with such a constraint, then she/he wants to have it end-to-end and not server-side). By the way, S/MIME encrypted email of yours can be decrypted by all authorities issuing the SSL certificate for you. So it's anyway not secure enough by design. With regards to your three-point proposal, the biggest question is how to store and work with keys on the client side. There is definitely some standard or at least recommendation from NIST, but I didn't look it up. Will take a look soon (now it's too late at night).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Oct 15, 2016):

Regarding public key management, I looked into how things are nowadays and I was wrong - it's nearly the same nothing as 25 years ago when PGP was invented 😢. Hence the following draft.

Based on the nature of email-centered contacts in address book, we don't have one "abstract" contact having more email addresses and residence addresses etc., but we treat each email as separate contact. And because of the logical PGP scheme, it makes sense to have one and only one public key for one unique email (I also prefer having a separate public key for each unique email of mine as prevention from making any relation between my emails - yes, I'm kinda paranoid 😉).

This assumption simplifies things a lot IMHO. Thus we can step back and put the public key to our address book in the same way as any other additional contact fields (e.g. as "Public GPG key:"). Well, there might be an issue with LDAP as it should support more keys for one contact - see http://superuser.com/questions/358735/public-key-repository-does-this-exist . The solution could be to import the contact as many times as there are public keys - each time with a different public key and a notion in the contact label designating which public key will be used.

The encryption will be done in JS on the client side. We should postpone loading of the encryption JS library (because of it's size) until the user explicitly selects a check box "Encrypt with PGP" (having caption "Encrypt the email body with Pretty Good Privacy. Body of encrypted emails is NOT searchable!"), because still the vast majority of emails will not be encrypted. Of course, we should load the library only once for the whole session.

Now the hard part comes.

For both encryption, decryption and private key storage we need to take into account any "web page" attack - injecting malicious JS code through compromised servers, cross-side-scripting, etc. It's not easy to sign JS files nor verify the entire document to be trustworthy (certificates involved, etc.).

As dandavis from crypto.stackexchange wrote: with TLS, window.crypto, newer browser features like HTTP CSP and subresource integrity to verify scripts, IIFE to generate the keys and define an interface not available to later-added scripts (or use a sealed Worker to prevent arbitrary code from altering the crypto library code), and user-prompted passwords being bcrypted/scrypted then fed to AES and then stored to localStorage we should obtain really decent trustworthiness.

Generally if we won't show content from other users (which is difficult e.g. because of multipart emails with pictures etc. from other sources), XSS is impossible. Using sanitize function and https for messages, 90% of attack vectors go away. Additionally adding CSP HTTP header to the page, and integrity attributes to any off-site <script> tags should stop clever attacks.

PGP support will of course require two additional fields for each Cypht email account:

"Private GPG key:" (with caption "Associated private GPG key to be stored only locally, and encrypted (scrypt) in the browser storage. Do NOT publish it anywhere!" and being hidden by default to avoid look-at-screen attacks e.g. by quickly taking a photo or recording a video)
"Public GPG key:" (with caption "Associated public GPG key. You should publish this key (e.g. by sending it via email under your signature or having it on your business card).")

Next to these fields might be a button "Regenerate keys" with a modal window warning with steps:

Save the current private and public keys in case someone already knew the public key.
Click on "Proceed to the actual key generation" or "Cancel".
Publish the newly generated public key and notify all users of the current public key about the new one.

All this also means, that PGP encryption will be available only in the newest browsers.

References

https://github.com/bitwiseshiftleft/sjcl (advanced JS crypto library)
http://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi
https://blog.engelke.com/2014/09/19/saving-cryptographic-keys-in-the-browser/ (old and thus not applicable, but just for completeness)

@dumblob commented on GitHub (Oct 15, 2016): Regarding **public key management**, I looked into how things are nowadays and I was wrong - it's nearly the same _nothing_ as 25 years ago when PGP was invented :cry:. Hence the following draft. Based on the nature of email-centered contacts in address book, we don't have one "abstract" contact having more email addresses and residence addresses etc., but we treat each email as separate contact. And because of the logical PGP scheme, it makes sense to have one and only one public key for one unique email (I also prefer having a separate public key for each unique email of mine as prevention from making any relation between my emails - yes, I'm kinda paranoid :wink:). This assumption simplifies things a lot IMHO. Thus we can step back and put the public key to our address book in the same way as any other additional contact fields (e.g. as "Public GPG key:"). Well, there might be an issue with LDAP as it should support more keys for one contact - see http://superuser.com/questions/358735/public-key-repository-does-this-exist . The solution could be to import the contact as many times as there are public keys - each time with a different public key and a notion in the contact label designating which public key will be used. The encryption will be done in JS on the client side. We should postpone loading of the encryption JS library (because of it's size) until the user explicitly selects a check box "Encrypt with PGP" (having caption "Encrypt the email body with Pretty Good Privacy. Body of encrypted emails is NOT searchable!"), because still the vast majority of emails will not be encrypted. Of course, we should load the library only once for the whole session. Now the hard part comes. For both encryption, decryption and private key storage we need to take into account any "web page" attack - injecting malicious JS code through compromised servers, cross-side-scripting, etc. It's not easy to sign JS files nor verify the entire document to be trustworthy (certificates involved, etc.). As `dandavis` from _crypto.stackexchange_ wrote: with TLS, `window.crypto`, newer browser features like HTTP [CSP](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) and [subresource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) to verify scripts, [IIFE](https://en.wikipedia.org/wiki/Immediately-invoked_function_expression) to generate the keys and define an interface not available to later-added scripts (or use a sealed Worker to prevent arbitrary code from altering the crypto library code), and user-prompted passwords being [bcrypted](https://en.wikipedia.org/wiki/Bcrypt)/[scrypted](https://en.wikipedia.org/wiki/Scrypt) then fed to AES and then stored to localStorage we should obtain really decent trustworthiness. Generally if we won't show content from other users (which is difficult e.g. because of multipart emails with pictures etc. from other sources), XSS is impossible. Using [sanitize function](https://gist.github.com/rndme/709b79625af301d76bd432dfb2ad8feb) and https for messages, 90% of attack vectors go away. Additionally adding CSP HTTP header to the page, and `integrity` attributes to any off-site `<script>` tags should stop clever attacks. PGP support will of course require two additional fields for each Cypht email account: - "Private GPG key:" (with caption "Associated private GPG key to be stored only locally, and encrypted (scrypt) in the browser storage. Do NOT publish it anywhere!" and being **hidden by default** to avoid look-at-screen attacks e.g. by quickly taking a photo or recording a video) - "Public GPG key:" (with caption "Associated public GPG key. You should publish this key (e.g. by sending it via email under your signature or having it on your business card).") Next to these fields might be a button "Regenerate keys" with a modal window warning with steps: 1. Save the current private and public keys in case someone already knew the public key. 2. Click on "Proceed to the actual key generation" or "Cancel". 3. Publish the newly generated public key and notify all users of the current public key about the new one. All this also means, that PGP encryption will be available only in the newest browsers. #### References - https://github.com/bitwiseshiftleft/sjcl (advanced JS crypto library) - http://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi - https://blog.engelke.com/2014/09/19/saving-cryptographic-keys-in-the-browser/ (old and thus not applicable, but just for completeness)

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Oct 15, 2016):

wow, thanks for the very thorough work on this, It is greatly appreciated! I have a POC in the works for PGP signing/encrypting on outbound mail already, but it's very rough still. This is super helpful. When I have more time I will respond with my thoughts more completely. Thanks again!

@jasonmunro commented on GitHub (Oct 15, 2016): wow, thanks for the very thorough work on this, It is greatly appreciated! I have a POC in the works for PGP signing/encrypting on outbound mail already, but it's very rough still. This is super helpful. When I have more time I will respond with my thoughts more completely. Thanks again!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 16, 2016):

I'm moving forward with an openpgpjs implementation. @dumblob, in response to the points you raise (in no particular order):

Private keys will be optionally stored in local browser session storage. passphrases will not be stored at all and need to be input on demand. Private keys can also be used on demand only and not stored at all. If a private key is stored in the browser, it will not ever be displayed onscreen.
Public keys will be stored in the user settings (and the server side session). The interface will allow you to upload a key file from your machine, or pull one from a pre-defined list of key servers. openpgpjs will be used to pull the user id from the key which will be stored with it. Public keys and there associated E-mails will be stored independently from contacts for now.
Signing and encrypting outbound mail will be done in the browser with openpgpjs, and the message format will still be text/plain (the same way mailvelope works). This is maybe not the ideal way, but it is the simplest to implement and I think the most widely supported by other clients.
There will be no built in key generation for now, that will come in a phase 2
By design Cypht does not use assets from other domains, so integrity attributes do not apply. We already use all the HTTP headers to help keep things secure (CSP, X-XSS-Protection, etc).
Decrypting messages will happen in the browser, and the results displayed as text only. Even if the encrypted content is html. Outbound messages can only be encrypted/signed when sending plain text - PGP controls will be disabled if you are sending HTML formatted mail.
openpgpjs is about 100KB gzipped. It will be loaded on the compose page and cached for future reloads. If a message part being viewed is a PGP encrypted blob, we will include it on the message view as well.

I think this approach will provide a lot of flexibility and decent usability. It also does not require any server side PGP support. It's almost like a built in (and more usable) mailbvelope process.

@jasonmunro commented on GitHub (Nov 16, 2016): I'm moving forward with an openpgpjs implementation. @dumblob, in response to the points you raise (in no particular order): - Private keys will be optionally stored in local browser session storage. passphrases will not be stored at all and need to be input on demand. Private keys can also be used on demand only and not stored at all. If a private key is stored in the browser, it will not ever be displayed onscreen. - Public keys will be stored in the user settings (and the server side session). The interface will allow you to upload a key file from your machine, or pull one from a pre-defined list of key servers. openpgpjs will be used to pull the user id from the key which will be stored with it. Public keys and there associated E-mails will be stored independently from contacts for now. - Signing and encrypting outbound mail will be done in the browser with openpgpjs, and the message format will still be text/plain (the same way mailvelope works). This is maybe not the ideal way, but it is the simplest to implement and I think the most widely supported by other clients. - There will be no built in key generation for now, that will come in a phase 2 - By design Cypht does not use assets from other domains, so integrity attributes do not apply. We already use all the HTTP headers to help keep things secure (CSP, X-XSS-Protection, etc). - Decrypting messages will happen in the browser, and the results displayed as text only. Even if the encrypted content is html. Outbound messages can only be encrypted/signed when sending plain text - PGP controls will be disabled if you are sending HTML formatted mail. - openpgpjs is about 100KB gzipped. It will be loaded on the compose page and cached for future reloads. If a message part being viewed is a PGP encrypted blob, we will include it on the message view as well. I think this approach will provide a lot of flexibility and decent usability. It also does not require any server side PGP support. It's almost like a built in (and more usable) mailbvelope process.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Nov 16, 2016):

Thank you @jasonmunro, it sounds pretty solid.

Public keys and there associated E-mails will be stored independently from contacts for now.

How do you envision this storage? I found a note TODO: Fetch public key list from storage in classHm_Output_pgp_compose_controlsmethodoutput()` and then in recent commits I found you're using the MIT Public Key Server.

I'm concerned about any "opened" public key servers as they are IMHO not trustworthy (I can upload there whatever fake identity I want) and second, they do not reflect the possible choice of e.g. email to communicate through. Imagine you have 2 emails: "My Name" <a@a.a> and "My Name" <b@b.b>, each having a corresponding PGP key different from each other; a@a.a is used for private conversations, b@b.b for public conversations; in the MIT PGP Public Key Server I'll have of course only b@b.b; now my boss wants to write to "My Name" an encrypted email and Cypht shows him b@b.b with a PGP key instead of a@a.a with a PGP key like I told him as I can't filter and forward his email to a@a.a because of missing information like e.g. the email address from which will my boss write.

I would probably try to reverse the idea - make the public key servers suggesting the PGP keys, but only in an edit view of a contact, not in the compose window. This solution should emphasize the workflow "add/edit contact" -> "add the PGP key I want" -> "save the edited/added contact" -> "open compose email window" and thus prevent suggesting wrong PGP key, because Cypht will already know what email contact is being worked on.

Actually, I would rather trust only PGP keys for emails with the same domain as the particular SKS server runs on. Or is there any standard (based e.g. on PKI) which proves, that the particular PGP identity provided by the particular SKS server is not a fake? I'm not aware of any 😢.

P.S. It would be nice to add PGP as another search criterion to allow filtering PGP and non-PGP emails 😉.

@dumblob commented on GitHub (Nov 16, 2016): Thank you @jasonmunro, it sounds pretty solid. > Public keys and there associated E-mails will be stored independently from contacts for now. How do you envision this storage? I found a note `TODO: Fetch public key list from storage` in `class`Hm_Output_pgp_compose_controls`method`output()` and then in recent commits I found you're using the MIT Public Key Server. I'm concerned about any "opened" public key servers as they are IMHO not trustworthy (I can upload there whatever fake identity I want) and second, they do not reflect the possible choice of e.g. email to communicate through. Imagine you have 2 emails: `"My Name" <a@a.a>` and `"My Name" <b@b.b>`, each having a corresponding PGP key different from each other; `a@a.a` is used for private conversations, `b@b.b` for public conversations; in the [MIT PGP Public Key Server](https://github.com/jasonmunro/cypht/commit/3ce8d962d4bac51f386be07881485ef1e722ee6b#diff-070ac4337139f6dca2264f71306ad818R102) I'll have of course only `b@b.b`; now my boss wants to write to "My Name" an encrypted email and Cypht shows him `b@b.b` with a PGP key instead of `a@a.a` with a PGP key like I told him as I can't filter and forward his email to `a@a.a` because of missing information like e.g. the email address from which will my boss write. I would probably try to reverse the idea - make the public key servers suggesting the PGP keys, but only in an edit view of a contact, not in the compose window. This solution should emphasize the workflow _"add/edit contact" -> "add the PGP key I want" -> "save the edited/added contact" -> "open compose email window"_ and thus **prevent suggesting wrong PGP key**, because Cypht will already know what email contact is being worked on. Actually, I would rather trust only PGP keys for emails with the same domain as the particular [SKS](https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home) server runs on. Or is there any standard (based e.g. on PKI) which proves, that the particular PGP identity provided by the particular SKS server is not a fake? I'm not aware of any :cry:. P.S. It would be nice to add `PGP` as another search criterion to allow filtering PGP and non-PGP emails :wink:.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@ghost commented on GitHub (Nov 16, 2016):

I have been interested in PGP-enabled email.
ProtonMail.com has a 2-password system that relies heavily on javascript (free & paid email addresses)

Mailvelope was mentioned earlier, I've used it before but switched to a command line PGP client as I wasn't sure of mailvelope's security.

https://www.mailpile.is/ MailPile is another client that was mentioned, I had this short-listed.

Thank you for working on PGP support in Cypht, I look forward to testing it!

👍

@ghost commented on GitHub (Nov 16, 2016): I have been interested in PGP-enabled email. ProtonMail.com has a 2-password system that relies heavily on javascript (free & paid email addresses) Mailvelope was mentioned earlier, I've used it before but switched to a command line PGP client as I wasn't sure of mailvelope's security. https://www.mailpile.is/ MailPile is another client that was mentioned, I had this short-listed. Thank you for working on PGP support in Cypht, I look forward to testing it! :+1:

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 16, 2016):

@dumblob The idea of the public key server access within Cypht is that you could have a an easy way to import keys to your settings, not as a definitive source, just a resource. I'm not as versed in PGP as you are, so I can't speak to the validity of these sources. My plan was to allow a by email search of the defined key servers, from which you could import a key based on the extracted user ids associated with it (name and email). Also ultimately the list of key servers is configurable, so you can allow import from private/better sources. You can always just upload trusted public keys from a file as well. There is no reliance on the public key servers.

I did some testing on the MIT key server, so I know there is a LOT of what appears to be crap keys there :)

So my plan is very much in line with what you are saying. Key servers are available as a source to import a key, but not relied on for anything else. They will be controllable at a site level as well, so you can exclude any that are undesirable or include ones that are not public.

@jasonmunro commented on GitHub (Nov 16, 2016): @dumblob The idea of the public key server access within Cypht is that you could have a an easy way to import keys to your settings, not as a definitive source, just a resource. I'm not as versed in PGP as you are, so I can't speak to the validity of these sources. My plan was to allow a by email search of the defined key servers, from which you could import a key based on the extracted user ids associated with it (name and email). Also ultimately the list of key servers is configurable, so you can allow import from private/better sources. You can always just upload trusted public keys from a file as well. There is no reliance on the public key servers. I did some testing on the MIT key server, so I know there is a LOT of what appears to be crap keys there :) So my plan is very much in line with what you are saying. Key servers are available as a source to import a key, but not relied on for anything else. They will be controllable at a site level as well, so you can exclude any that are undesirable or include ones that are not public.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 16, 2016):

@manasb Thanks for the feedback. My understanding is that Proton Mail encryption only works with other Proton Mail users, please correct me if I'm wrong about that. I want to provide a universal solution compatible with as many clients as possible. I'm also not sure of mailvelopes security, though I think it uses the same underlying lib we are (openpgpjs) which I have been impressed with so far.

@jasonmunro commented on GitHub (Nov 16, 2016): @manasb Thanks for the feedback. My understanding is that Proton Mail encryption only works with other Proton Mail users, please correct me if I'm wrong about that. I want to provide a universal solution compatible with as many clients as possible. I'm also not sure of mailvelopes security, though I think it uses the same underlying lib we are (openpgpjs) which I have been impressed with so far.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dhuyvetter commented on GitHub (Nov 17, 2016):

As you might know the MIT keyserver is known to be bad (see comments here: http://cryptome.org/2013/07/mining-pgp-keyservers.htm), which probably makes it a good one to test against, because if it works there it probably works elsewhere too. But if you were to set a default key server to look up in, http://hkps.pool.sks-keyservers.net/ is a better one.

Dimitri

On 17/11/2016 00:16, Jason Munro wrote:

@dumblobhttps://github.com/dumblob The idea of the public key server access within Cypht is that you could have a an easy way to import keys to your settings, not as a definitive source, just a resource. I'm not as versed in PGP as you are, so I can't speak to the validity of these sources. My plan was to allow a by email search of the defined key servers, from which you could import a key based on the extracted user ids associated with it (name and email). Also ultimately the list of key servers is configurable, so you can allow import from private/better sources. You can always just upload trusted public keys from a file as well. There is no reliance on the public key servers.

I did some testing on the MIT key server, so I know there is a LOT of what appears to be crap keys there :)

So my plan is very much in line with what you are saying. Key servers are available as a source to import a key, but not relied on for anything else. They will be controllable at a site level as well, so you can exclude any that are undesirable or include ones that are not public.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/jasonmunro/cypht/issues/11#issuecomment-261089982, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AATvSABQ0hCg1-ZsyQJsGQKjNjkiEUvuks5q-4CsgaJpZM4Fi7Jl.

Dimitri
https://dhuyvetter.eu

This email and its contents are subject to an email legal notice that can be viewed at: http://www.naspers.com/disclaimer Should you be unable to access the link provided, please email us for a copy at csc@optinet.net
Hierdie e-pos en sy inhoud is onderhewig aan 'n regskennisgewing oor elektroniese pos wat gelees kan word by http://www.naspers.com/disclaimer 'n Afskrif kan aangevra word by csc@optinet.net

@dhuyvetter commented on GitHub (Nov 17, 2016): As you might know the MIT keyserver is known to be bad (see comments here: http://cryptome.org/2013/07/mining-pgp-keyservers.htm), which probably makes it a good one to test against, because if it works there it probably works elsewhere too. But if you were to set a default key server to look up in, http://hkps.pool.sks-keyservers.net/ is a better one. Dimitri On 17/11/2016 00:16, Jason Munro wrote: @dumblobhttps://github.com/dumblob The idea of the public key server access within Cypht is that you could have a an easy way to import keys to your settings, not as a definitive source, just a resource. I'm not as versed in PGP as you are, so I can't speak to the validity of these sources. My plan was to allow a by email search of the defined key servers, from which you could import a key based on the extracted user ids associated with it (name and email). Also ultimately the list of key servers is configurable, so you can allow import from private/better sources. You can always just upload trusted public keys from a file as well. There is no reliance on the public key servers. I did some testing on the MIT key server, so I know there is a LOT of what appears to be crap keys there :) So my plan is very much in line with what you are saying. Key servers are available as a source to import a key, but not relied on for anything else. They will be controllable at a site level as well, so you can exclude any that are undesirable or include ones that are not public. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/jasonmunro/cypht/issues/11#issuecomment-261089982, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AATvSABQ0hCg1-ZsyQJsGQKjNjkiEUvuks5q-4CsgaJpZM4Fi7Jl. ## Dimitri https://dhuyvetter.eu This email and its contents are subject to an email legal notice that can be viewed at: http://www.naspers.com/disclaimer Should you be unable to access the link provided, please email us for a copy at csc@optinet.net Hierdie e-pos en sy inhoud is onderhewig aan 'n regskennisgewing oor elektroniese pos wat gelees kan word by http://www.naspers.com/disclaimer 'n Afskrif kan aangevra word by csc@optinet.net

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Nov 17, 2016):

@jasonmunro thanks a lot! The outlined solution suits me.

@dhuyvetter currently on http://hkps.pool.sks-keyservers.net/ seems to be less crap than on the MIT key server. But it's just a matter of time and the amount of publicity (which Cypht will eventually support 😉) to be as well polluted to such a great extent or more.

@dumblob commented on GitHub (Nov 17, 2016): @jasonmunro thanks a lot! The outlined solution suits me. @dhuyvetter currently on http://hkps.pool.sks-keyservers.net/ seems to be less crap than on the MIT key server. But it's just a matter of time and the amount of publicity (which Cypht will eventually support :wink:) to be as well polluted to such a great extent or more.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@conspacer commented on GitHub (Nov 23, 2016):

@jasonmunro Let me know when you need Beta testers for any proposed module... I use a lot of GPG communications (both public key server based and privately exchanged keyfiles). I would love toy help out on this.
Cypht rox!!!

@conspacer commented on GitHub (Nov 23, 2016): @jasonmunro Let me know when you need Beta testers for any proposed module... I use a lot of GPG communications (both public key server based and privately exchanged keyfiles). I would love toy help out on this. Cypht rox!!!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@ghost commented on GitHub (Nov 24, 2016):

@jasonmunro

Yes, you are correct. ProtonMail is open-source but it has been written specifically for ProtonMail.com use. It could probably be forked to support arbitrary networks, but that's besides the point :)
https://protonmail.com/blog/protonmail-secure-email-open-source/

I found Mailvelope clunky to use as well. The location of my private key matters to me, I'm not sure if I can use a PGP frontend like Kleopatra, GPA etc. together with Cypht. Is this possible?

This page has many other frontends, https://www.gnupg.org/related_software/frontends.html

Thought I'd also share this: a Tor-based forward secret email for Raspberry Pi https://github.com/last-box/LookingGlass

@ghost commented on GitHub (Nov 24, 2016): @jasonmunro Yes, you are correct. ProtonMail is open-source but it has been written specifically for ProtonMail.com use. It could probably be forked to support arbitrary networks, but that's besides the point :) https://protonmail.com/blog/protonmail-secure-email-open-source/ I found Mailvelope clunky to use as well. The location of my private key matters to me, I'm not sure if I can use a PGP frontend like Kleopatra, GPA etc. together with Cypht. Is this possible? This page has many other frontends, https://www.gnupg.org/related_software/frontends.html --- Thought I'd also share this: **a Tor-based forward secret email for Raspberry Pi** https://github.com/last-box/LookingGlass

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 30, 2016):

@manasb I will have to check those front-ends out to let you know. The location of your private key matters to me as well :) My plan would give you two options:

Your private key is held in session only local storage while you are logged in. Your passphrase could be optionally stored here as well
Your private key is not stored by Cypht at all, and you have to supply it for every operation you want to perform that requires it.

@jasonmunro commented on GitHub (Nov 30, 2016): @manasb I will have to check those front-ends out to let you know. The location of your private key matters to me as well :) My plan would give you two options: - Your private key is held in session only local storage while you are logged in. Your passphrase could be optionally stored here as well - Your private key is not stored by Cypht at all, and you have to supply it for every operation you want to perform that requires it.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 1, 2017):

By the way we should mention in documentation an overview of threats which a web-based PGP solution has - refer e.g. to the Google's analysis of a threat model (look for the string mitiga to find out how they mitigate described attack vectors; some vectors might be though missing on the wiki...). At least the threats which can't be mitigated at all (see the end of the Google's analysis of a threat model).

It would also be nice to have some independent security audit of Cypht at some point in the future. I think Mozilla has a grant program for such things.

@dumblob commented on GitHub (Mar 1, 2017): By the way we should mention in documentation an overview of threats which a web-based PGP solution has - refer e.g. to the Google's analysis of a [threat model](https://github.com/google/end-to-end/wiki/Threat-model ) (look for the string `mitiga` to find out how they mitigate described attack vectors; some vectors might be though missing on the wiki...). At least the threats which can't be mitigated at all (see the end of the Google's analysis of a threat model). It would also be nice to have some independent security audit of Cypht at some point in the future. I think Mozilla has a grant program for such things.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 2, 2017):

thanks for the link, I will check it out. I agree we need to be very up front about PGP + webmail and what that could mean from an attack vector point of view. Insofar as a security audit, I would LOVE that. I think we will do pretty well because of the module set design that forces better practices WRT user input (all user input must be whitelisted and typed). At one point I was in touch with the guy who runs pargonie (I noticed a problem with there website and reported it). He suggested he would check out Cypht, but it never happened.

@jasonmunro commented on GitHub (Mar 2, 2017): thanks for the link, I will check it out. I agree we need to be very up front about PGP + webmail and what that could mean from an attack vector point of view. Insofar as a security audit, I would LOVE that. I think we will do pretty well because of the module set design that forces better practices WRT user input (all user input must be whitelisted and typed). At one point I was in touch with the guy who runs pargonie (I noticed a problem with there website and reported it). He suggested he would check out Cypht, but it never happened.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 2, 2017):

... pargonie ...

You mean paragonie.com? That would be awesome.

By the way consider contacting Mozilla Grants as in my opinion there would be a high chance of success if we asked for a grant to fund an independent open audit. I know few people closely cooperating with Mozilla in person and I'm prepared to get my hands dirty with supporting an audit initiative.

Hm, there is only one thing left before an audit should take place. Namely a firm versioning scheme of Cypht. I would strongly recommend sticking with Semver for this purpose. The release schedule might be totally irregular, but the versioning scheme must be in place. Or are there any "blockers" for a first alpha release (we can open a new issue to discuss this in case there are some things to discuss).

@dumblob commented on GitHub (Mar 2, 2017): > ... pargonie ... You mean par**a**gonie.com? That would be awesome. By the way consider contacting [Mozilla Grants](https://www.mozilla.org/en-US/grants/ ) as in my opinion there would be a high chance of success if we asked for a grant to fund an independent open audit. I know few people closely cooperating with Mozilla in person and I'm prepared to get my hands dirty with supporting an audit initiative. Hm, there is only one thing left before an audit should take place. Namely a firm versioning scheme of Cypht. I would strongly recommend sticking with [Semver](http://semver.org/) for this purpose. The release schedule might be totally irregular, but the versioning scheme must be in place. Or are there any "blockers" for a first alpha release (we can open a new issue to discuss this in case there are some things to discuss).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 2, 2017):

Yep, I meant paragonie. Unfortunately that conversation was 6 months ago, so I doubt I will hear from them again. I will check out Mozilla grants, thanks for the tip. I just read over the Semver docs, and while it's more geared toward APIs, I think it's a good foundation for versioning. I think we are in pretty good shape for an alpha (beta even) release, so maybe a 0.1.0 release for now. I need to read up on doing releases with github, this will be my first time :)

@jasonmunro commented on GitHub (Mar 2, 2017): Yep, I meant paragonie. Unfortunately that conversation was 6 months ago, so I doubt I will hear from them again. I will check out Mozilla grants, thanks for the tip. I just read over the Semver docs, and while it's more geared toward APIs, I think it's a good foundation for versioning. I think we are in pretty good shape for an alpha (beta even) release, so maybe a 0.1.0 release for now. I need to read up on doing releases with github, this will be my first time :)

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 2, 2017):

I think we are in pretty good shape for an alpha (beta even) release, so maybe a 0.1.0 release for now.

Just a nitpick - according to Semver we shouldn't use 0. major number for such release as Semver says:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

@dumblob commented on GitHub (Mar 2, 2017): > I think we are in pretty good shape for an alpha (beta even) release, so maybe a 0.1.0 release for now. Just a nitpick - according to Semver we shouldn't use `0.` major number for such release as Semver says: > 4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 2, 2017):

Yep, I saw that. Just seems weird to jump to a 1.0.0 release :)

@jasonmunro commented on GitHub (Mar 2, 2017): Yep, I saw that. Just seems weird to jump to a 1.0.0 release :)

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 2, 2017):

From Mozilla grants page:

If we're not intimately familiar with your project and already consider it to be tied to the Mozilla mission, we are unlikely to make a grant, however worthy the cause.

:(

@jasonmunro commented on GitHub (Mar 2, 2017): From Mozilla grants page: > If we're not intimately familiar with your project and already consider it to be tied to the Mozilla mission, we are unlikely to make a grant, however worthy the cause. :(

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 2, 2017):

From Mozilla grants page: ...

Don't worry. It's not that bad 😉 (you know, business speak to discourage potentially abusive use). Cypht is more than enough tied to the Mozilla mission (web, security, user friendliness, high quality content filtering, ...). You can also check already funded projects - some have basically nothing to do with Mozilla and the only denominator is just a similar mission.

@dumblob commented on GitHub (Mar 2, 2017): >From Mozilla grants page: ... Don't worry. It's not that bad :wink: (you know, business speak to discourage potentially abusive use). Cypht is more than enough tied to the Mozilla mission (web, security, user friendliness, high quality content filtering, ...). You can also check already funded projects - some have basically nothing to do with Mozilla and the only denominator is just a similar mission.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 2, 2017):

Can't hurt to ask I guess :) I will shoot them an email and let you know what I find out!

@jasonmunro commented on GitHub (Mar 2, 2017): Can't hurt to ask I guess :) I will shoot them an email and let you know what I find out!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 2, 2017):

Yep, I saw that. Just seems weird to jump to a 1.0.0 release :)

I wouldn't say so. If it feels too weird, then it's still alpha. But if it should be beta, then 1.0.0 shouldn't feel weird (that's exactly the purpose why it's defined exactly that way in Semver).

@dumblob commented on GitHub (Mar 2, 2017): >Yep, I saw that. Just seems weird to jump to a 1.0.0 release :) I wouldn't say so. If it feels too weird, then it's still alpha. But if it should be beta, then `1.0.0` shouldn't feel weird (that's exactly the purpose why it's defined exactly that way in Semver).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 2, 2017):

Can't hurt to ask I guess :) I will shoot them an email and let you know what I find out!

Exactly! You can point them also to this discussion, so that I can get in touch with them eventually.

@dumblob commented on GitHub (Mar 2, 2017): >Can't hurt to ask I guess :) I will shoot them an email and let you know what I find out! Exactly! You can point them also to this discussion, so that I can get in touch with them eventually.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 14, 2017):

@dumblob I reached out to Mozilla shortly after we talked about this (forgot to link them to this thread however). I received a nice reply saying they would see what they could do, and that it would take a week or 2 to get back to me. Have not heard anything yet. As you also noticed, I created a branch and tag for our first release candidate (woot!). Also on the security front, I just pushed some changes to allow us to use libsodium for encryption if the PHP extension is installed. This is backwards compatible so you can update to using libsodium without losing any existing data.

@jasonmunro commented on GitHub (Mar 14, 2017): @dumblob I reached out to Mozilla shortly after we talked about this (forgot to link them to this thread however). I received a nice reply saying they would see what they could do, and that it would take a week or 2 to get back to me. Have not heard anything yet. As you also noticed, I created a branch and tag for our first release candidate (woot!). Also on the security front, I just pushed some changes to allow us to use libsodium for encryption if the PHP extension is installed. This is backwards compatible so you can update to using libsodium without losing any existing data.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Mar 14, 2017):

So many important news at once. Perfect! I'm curious how this everything will evolve...

@dumblob commented on GitHub (Mar 14, 2017): So many important news at once. Perfect! I'm curious how this everything will evolve...

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Apr 3, 2017):

@dumblob it's been almost 4 weeks since I sent a message to Mozilla - still no response since the initial "thanks for writing" reply. I have been checking out some other avenues for financial support of the project, if any pan out I will let you know.

@jasonmunro commented on GitHub (Apr 3, 2017): @dumblob it's been almost 4 weeks since I sent a message to Mozilla - still no response since the initial "thanks for writing" reply. I have been checking out some other avenues for financial support of the project, if any pan out I will let you know.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Apr 4, 2017):

That's kinda sad they didn't respond. Anyway, could you please ping them? I'll ping them as well.

@dumblob commented on GitHub (Apr 4, 2017): That's kinda sad they didn't respond. Anyway, could you please ping them? I'll ping them as well.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Apr 4, 2017):

Ok, I got a response that there is some more information on the MOSS wiki. It's said there, that applications are processed in batches every 3 months and the next processing happens on 30. April 2017, so Cypht might be in this one.

Also, did you take a look at https://wiki.mozilla.org/MOSS/Secure_Open_Source or even sent an email to the address in the section https://wiki.mozilla.org/MOSS/Secure_Open_Source#How_To_Apply or filled the application form linked from there?

@dumblob commented on GitHub (Apr 4, 2017): Ok, I got a response that there is some more information on the [MOSS wiki](https://wiki.mozilla.org/MOSS#Selection_Committee ). It's said there, that applications are processed in batches every 3 months and the next processing happens on 30. April 2017, so Cypht might be in this one. Also, did you take a look at https://wiki.mozilla.org/MOSS/Secure_Open_Source or even sent an email to the address in the section https://wiki.mozilla.org/MOSS/Secure_Open_Source#How_To_Apply or filled the application form linked from there?

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Apr 4, 2017):

Just got a response from Gervase Markham:

The suggestion form[0] states:

"we do not commit to replying directly to the submitter of every SOS
audit suggestion, so please do not expect to hear back from us."

You aren't the first person to misunderstand this, so I've edited the
top of the form to make it even more clear.

Hope that helps :-)

@dumblob commented on GitHub (Apr 4, 2017): Just got a response from Gervase Markham: >The suggestion form[0] states: > >"we do not commit to replying directly to the submitter of every SOS audit suggestion, so please do not expect to hear back from us." > >You aren't the first person to misunderstand this, so I've edited the top of the form to make it even more clear. > >Hope that helps :-)

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Apr 4, 2017):

@dumblob thanks for the follow up! All I did was send a message to the E-mail address at the bottom of the grants page. I can fill out the form from the wiki as well if we think that will help our cause. I assumed the lack of a response was processing time and or rejection, which is fine - I don't expect them to respond to everyone, and I fully understand if they are not interested in funding our request.

@jasonmunro commented on GitHub (Apr 4, 2017): @dumblob thanks for the follow up! All I did was send a message to the E-mail address at the bottom of the grants page. I can fill out the form from the wiki as well if we think that will help our cause. I assumed the lack of a response was processing time and or rejection, which is fine - I don't expect them to respond to everyone, and I fully understand if they are not interested in funding our request.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Apr 4, 2017):

@jasonmunro let's wait for the 30. April + 1 week to get some response. Then we should ask directly the commitee members. Mozilla is open, so it's not either-or, but rather an open process and we not only can ask, but even should 😉. So no step backs before we get a clear "no" or "yes" (this is based on my experience with Mozilla).

@dumblob commented on GitHub (Apr 4, 2017): @jasonmunro let's wait for the 30. April + 1 week to get some response. Then we should ask directly the commitee members. Mozilla is open, so it's not either-or, but rather an open process and we not only can ask, but even should :wink:. So no step backs before we get a clear "no" or "yes" (this is based on my experience with Mozilla).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Apr 4, 2017):

@dumblob sounds good, thanks for the info!

@jasonmunro commented on GitHub (Apr 4, 2017): @dumblob sounds good, thanks for the info!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@Fauxil-Fox commented on GitHub (Jun 12, 2018):

Any update?

@Fauxil-Fox commented on GitHub (Jun 12, 2018): Any update?

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Sep 25, 2018):

Quick summary of the issues on this thread:

PGP module set is still on the radar. I would put it near the top of my todo list
Mozilla funding for a security audit is a no-go
Spoke with Paragonie about a security audit. They have an encryption only audit that is cheaper, and a full app security audit that is ... more. Both are outside what I can afford to spend right now.
I think the top priority for Cypht right now is a new release - the latest release code is ancient. Considering how important it is to get PGP right, I don't want to rush it in, so my plan is new release first, PGP support very soon after (if not in parallel with release candidates).

@jasonmunro commented on GitHub (Sep 25, 2018): Quick summary of the issues on this thread: - PGP module set is still on the radar. I would put it _near_ the top of my todo list - Mozilla funding for a security audit is a no-go - Spoke with Paragonie about a security audit. They have an encryption only audit that is cheaper, and a full app security audit that is ... more. Both are outside what I can afford to spend right now. - I think the top priority for Cypht right now is a new release - the latest release code is _ancient_. Considering how important it is to get PGP right, I don't want to rush it in, so my plan is new release first, PGP support very soon after (if not in parallel with release candidates).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Oct 10, 2018):

Believe it or not I have some news around PGP support! We now have the ability to add/delete public keys, and encrypting outbound mail works :) I decided to drop key server support for phase 1, so you need to upload keys from files. Phase 2 will include key servers and maybe a textarea to paste a key into. Also server side public key verification requires the Gnugpg PECL extension for now. I might allow a fallback to a more simplistic "does this look like a public key" type of verification so it's not required but we will see.

I have some of the private key related bits working as well, but need to deal with passphrase handling, signing, and finally decrypting. Hope to get some more time tonight to get some of that knocked out!

@jasonmunro commented on GitHub (Oct 10, 2018): Believe it or not I have some news around PGP support! We now have the ability to add/delete public keys, and encrypting outbound mail works :) I decided to drop key server support for phase 1, so you need to upload keys from files. Phase 2 will include key servers and maybe a textarea to paste a key into. Also server side public key verification requires the Gnugpg PECL extension for now. I might allow a fallback to a more simplistic "does this look like a public key" type of verification so it's not required but we will see. I have some of the private key related bits working as well, but need to deal with passphrase handling, signing, and finally decrypting. Hope to get some more time tonight to get some of that knocked out!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Oct 10, 2018):

That's great news! It lead me to read this whole thread once more thoroughly through and I would like to add one more nice to have feature. It's called Autocrypt and is the wannabe-world-standard for email opportunistic encryption. E.g. Mailpile has it on its roadmap and several other bigger email clients (desktop ones or web based ones) as well.

Also we should be really pedantic with encryption implementation to prevent even "subtle" attacks like EFAIL. E.g. by never allowing absolutely any external content nor any browser-managed HTML rendering etc. - this means parsing it safely first e.g. by DOMParser and then whitelisting just a small subset of allowed tags to avoid events, scripts, etc. to run - imagine e.g. <img src="//" onerror="console.log(\'You are pwned!\')" /> (borrowed from https://stackoverflow.com/a/37554728 ).

@dumblob commented on GitHub (Oct 10, 2018): That's great news! It lead me to read this whole thread once more thoroughly through and I would like to add one more *nice to have* feature. It's called [Autocrypt](https://autocrypt.org/ ) and is the wannabe-world-standard for email opportunistic encryption. E.g. Mailpile has it on its roadmap and several other bigger email clients (desktop ones or web based ones) as well. Also we should be really pedantic with encryption implementation to prevent even "subtle" attacks like [EFAIL](https://efail.de/ ). E.g. by **never** allowing absolutely any external content nor any browser-managed HTML rendering etc. - this means parsing it safely first e.g. by [DOMParser](https://developer.mozilla.org/en-US/docs/Web/API/DOMParser#Browser_compatibility ) and then whitelisting just a small subset of allowed tags to avoid events, scripts, etc. to run - imagine e.g. `<img src="//" onerror="console.log(\'You are pwned!\')" />` (borrowed from https://stackoverflow.com/a/37554728 ).

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Oct 10, 2018):

@dumblob I believe we have an open request for Autocrypt already. I have glanced at the spec but not much more than that. Insofar as EFAIL type attacks - I'm limiting both encrypting outbound and decrypting to plain text. Even if the payload is HTML (hiding in a text plain part), it will be rendered as text only.

With that said, the initial version of phase 1 features are pushed!

add/delete public keys with an associated E-mail address
add/delete private keys. These never leave the browser and are destroyed on logout/browser close
sign/encrypt/both for outbound mail. This is only available for plain text outbound message types
decrypt on message read. If the message part is recognized as PGP encrypted text, it will provide controls to decrypt it. As mentioned whatever the content is it will be rendered as plain text.
passphrases are never stored - they must be entered anytime an action is being performed with a private key (sign, decrypt).

So far it's working pretty well I think! I wish I had updated openpgpjs before starting, since once I did I had to refactor a bunch of stuff since the interface changed.

@jasonmunro commented on GitHub (Oct 10, 2018): @dumblob I believe we have an open request for Autocrypt already. I have glanced at the spec but not much more than that. Insofar as EFAIL type attacks - I'm limiting both encrypting outbound and decrypting to plain text. Even if the payload is HTML (hiding in a text plain part), it will be rendered as text only. With that said, the initial version of phase 1 features are pushed! - add/delete public keys with an associated E-mail address - add/delete private keys. These never leave the browser and are destroyed on logout/browser close - sign/encrypt/both for outbound mail. This is only available for plain text outbound message types - decrypt on message read. If the message part is recognized as PGP encrypted text, it will provide controls to decrypt it. As mentioned whatever the content is it will be rendered as plain text. - passphrases are never stored - they must be entered anytime an action is being performed with a private key (sign, decrypt). So far it's working pretty well I think! I wish I had updated openpgpjs before starting, since once I did I had to refactor a bunch of stuff since the interface changed.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Oct 11, 2018):

I believe we have an open request for Autocrypt already.

Yeah, you got me - I didn't follow Cypht thoroughly for quite some time and completely forgot I even reacted to the Autocrypt proposal 😉.

Thanks for the first version of end-to-end encryption - it'll be a big thing for the new Cypht release.

@dumblob commented on GitHub (Oct 11, 2018): >I believe we have an open request for Autocrypt already. Yeah, you got me - I didn't follow Cypht thoroughly for quite some time and completely forgot I even reacted to the [Autocrypt proposal](https://github.com/jasonmunro/cypht/issues/241 ) :wink:. Thanks for the first version of end-to-end encryption - it'll be a big thing for the new Cypht release.

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Nov 29, 2018):

Since the MVP for this is implemented, I'm going to close this issue. If anyone has specific requests or finds bugs please open a new issue with the details. Thanks!

@jasonmunro commented on GitHub (Nov 29, 2018): Since the MVP for this is implemented, I'm going to close this issue. If anyone has specific requests or finds bugs please open a new issue with the details. Thanks!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@marclaporte commented on GitHub (Aug 8, 2022):

For the record: https://github.com/jasonmunro/cypht/tree/master/modules/pgp

@marclaporte commented on GitHub (Aug 8, 2022): For the record: https://github.com/jasonmunro/cypht/tree/master/modules/pgp

kerem referenced this issue

2026-02-25 21:35:35 +03:00

[GH-ISSUE #1411] 🐛 [Bug] Error when forwarding mail with attachment #650

Rows
Columns

[GH-ISSUE #11] Enhancement: support for PGP (or similar) #9

References