Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.
This is an archived project. Repository and other project resources are read-only.
Based on the conversation had last night, I wanted to record it here.
Craftguy and I were able to exchange gpg excrypted messages over MMS through Chatty. It was a manual intensive process, but it worked (use a CLI program to import keys, encrypt manually, save to a file, send the file via MMS)! Upon further discussion, the actual protcol over which the gpg message works doesn't matter too much, as it gpg (seems to be) text based, so one could send gpg messages over SMS/MMS (being aware of the limitations, like size), Matrix, or any other protocol that Chatty supports.
It would be really neat if there was a way to transparently support gpg encryption to contacts. So if I wanted to send Craftyguy or kyle a message, I could have their gpg key preloaded and it could automaticaly encrypt and send the message encrypted/signed, and on the receiving end, it would recognize the PGP preamble and auto decrypt/sign. This could be transport medium agnostic as well.
There could also be a way to trust/verify it offline/in person/some other way? Signal does this, you can view the key fingerprint and verify it in person.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
What I like about this is that in combination with the OpenPGP smart card reader in the Librem 5, it could mean you all encryption/decryption could happen on the smart card w/ keys that never leave the smart card.
@kop316 Please can you publish the "manual intensive process" you mentioned ? I already use GnuPG to encrypt my emails and I'd like to do the same for some of my SMS. Currently, I have to encrypt and decrypt it in command line, which is doable but tedious.
Maybe I can store the associations between contacts and public keys into a table or a property file (or even in a dedicated field in the contacts, KEY in the Virtual Contact File format for example) and create a rudimentary command line tool to drive things easier in the meantime.
So I finally got around to getting the openPGP card working on my L5, so I wanted to circle back to this idea.
Off the top of my head, Chatty would need to:
Retrieve keys for me and my contacts (not sure how that would be done?)
Have a way to import a key
Have a UI option to encrypt/sign a message (not hard I would think, just needs to detect the presence of the appropriate keys)
send it.
I looked in GNOME Contacts, it doesn't look like there is a way to store the PGP key directly? Perhaps in the comments section.... Or maybe it associates the email of the person with the PGP key.
I would think since this is all UI, it could be neutral to the actual protocol (SMS would be maybe the only limit, as I discussed above).
It works with the OpenPGP card on the L5. I only implemented signing, but it should work with all PGP functions. It's also very janky, as I only wanted to make a PoC.
So I suppose the first thing to do is integrate this a bit more in Chatty?
Key exchange and trust on first use / automatic key retrieval is something that needs to be solved with the UI, and also is a question of how do we want the flow to work.
For now, !1208 (merged) only does text, so fragmentation shouldn't be an issue yet, but I agree, it should be something we look at when file support is added.
Ok, after some work, I have all of the lower level APIs in place for in !1208 (merged)
* encryption* signature verification* key exchange* trust on first use / automatic key retrieval
In reference to fragmentation of longer messages / reassembly, I think that makes sense is depending on the protocol, restrict to only sending messages (i.e. for SMS, don't allow for files to be attached). I think assuming that, it likely isn't necessary.
I think !1202 (merged) is happening sooner than later, so I don't think it makes sense to work on the actual GUI bits until that is merged.
So !1208 (merged) is complete for the lower level APIs. However like I said before, it would be nice to get some input on what the GUI should look like. I think to start out, I should focus on SMS/MMS.
One of the main questions I have is where should I store the user ID (email) of the other person?
@evangelos.tzaras asked me to comment here, my experience from both a design and real-life usage perspective is that that adding GPG to existing plain text protocols is basically never a good idea. The value of email or SMS over a more modern protocol is the network effect, but GPG email doesn't have that because it has even fewer users than something like Signal or Matrix.
Having SMS/MMS is important from a legacy compatibility perspective, but there's no good reason to invest resources into fancy features on top of that, which only work with other clients that support them (i.e. only other people using Chatty, which is basically nobody). For those few people it makes a lot more sense to just switch to a different protocol than add encryption to SMS. Chatty even supports some of them, in the same app...
I don't fully agree with you @tobias.bernard. SMS/MMS indeed rely on an old protocol but they are simple, work out of the box and are universal. So they are widely used and will remain so until something else becomes at least as simple and universal. SMS remains the best and only way to message anyone anytime anywhere.
Now, even if "nobody" is using Chatty, we Do care about people using Chatty. Especially as Chatty is the default SMS messaging application on the Librem 5. So giving Librem 5 customers the ability to send SMS encrypted messages between each other (anytime anywhere or just because SMS is simple) is a good idea in my opinion.
User here, @tobias.bernard : I'm using SMS a lot, because it costs money. Yes, you read it right :). I prefer receiving SMS from the majority of people, because they have to pay for it and because of that tend to keep there unfinished thoughts to themselves.
The idea of integrating PGP on top of SMS/MMS from my point of view is brilliant: I could even tell people wanting to reach me with confidential information that they can do that via SMS/MMS by encrypting the messages.
To advanced users I could send encrypted SMS/MMS knowing that they'll be able to cut'n'paste the encrypted information and decrypt it manually.
I'm looking forward to having a little How-to generate an encrypted SMS/MMS compatible with chatty.
One of the main questions I have is where should I store the user ID (email) of the other person?
I think you also want to store key id's and TOFU.
/cc @francois.techene can someone from the design team help here? Shouldn't we want it by default it could be an optional plugin or similar. For the chatty's "small group pattern I think having a way to communicate over those fallbacks encrypted would make sense.
I am sure we can find a way to make Chatty to Chatty SMS encryption pretty transparent to the user. We don't need to worry about other SMS clients at this point. Most of them are running on non respectful platforms anyway.
For 1 to 1 we could have a simple flow where one sends an invite to another Chatty user through the top menu of the conversation. On the other side, Chatty would then display an "Accept" button within the conversation. From there, after exchanging the required keys, new messages can be send encrypted (or in clear with a "lock" button toggle in the text box).
For small groups it may be more complicated if some members are not running Chatty. Not sure how that could work.
In that case, if messages are sent in clear to at least one member, I see no point in encrypting for the other.
Still pretty nice to be able to encrypt for private 1:1 conversations.
I think this makes sense! I also think it makes sense to have a UI menu to ask for the default key to use for signing/encryption. in chatty-pgp, I am reusing the libcamel infrastructure, and as a consequence, a user can reuse GPG keys that are known in seahorse. This way, if I already had e.g. Guido's GPG key for his email, it would be nice to reuse that for Chatty communication rather than trust a different key.
For small groups it may be more complicated if some members are not running Chatty. Not sure how that could work.
Personally, I think the flow can be the same. One use can request a key exchange in a group chat, and the rest can reply.
In that case, if messages are sent in clear to at least one member, I see no point in encrypting for the other.
I agree, I don't think adding the option makes any sense if everyone does not have the ability.
The request I think can be in-band too (i.e. Chatty sends an SMS/MMS to the recipients, and Chatty replies with an SMS/MMS). This way other chat apps can adopt the protocol if they so choose.
I like the idea of reusing an existing gpg key if it exists. For others the process of creating and exchanging keys should be as transparent as possible. Most people don't know what keys are about and that would make them reluctant to use the feature.
Anyway, thank you so much for the great work you have done @kop316 ! That's very much appreciated!
They have an icon up top that is a padlock, and when you click it, it send an SMS for key exchange. (I don't know what the contents are exactly, I assume a public key).
Anyway, thank you so much for the great work you have done @kop316 ! That's very much appreciated!
Yes, a padlock in the top bar to toggle encryption is a good idea. What could work is that the lock is open by default. If you click it to start using encryption and if no keys have been exchanged with the other side, a dialog appears that proposes to send the encryption invitation to the other side letting you know that it can only work with another Chatty app. The padlock stays open until the invitation is accepted. Then, you get a message saying that encryption can be used and that you can click the padlock.
After that, the padlock can be toggled through a simple click on it.
Having a single button (padlock) to handle the entire flow would be very smart and convenient!
I agree! I think also we can include a panel in the settings for GPG key management. So by default, we don't generate a key, but we can give the user an option to generate a key or ask to use an existing key.
I agree! I think also we can include a panel in the settings for GPG key management. So by default, we don't generate a key, but we can give the user an option to generate a key or ask to use an existing key.
...or point to seahorse for gpg key generation (which already has UI for that).
...or point to seahorse for gpg key generation (which already has UI for that).
I agree with this entirely for advanced users (hence the place to reference an existing key), but one thing I think @francois.techene desires is:
For others the process of creating and exchanging keys should be as transparent as possible. Most people don't know what keys are about and that would make them reluctant to use the feature.
In this case, would it make sense to have a menu that can create it, or you still think pointing to Seahorse makes the most sense? I also don't think Chatty (or anything else) depends on Seahorse by default, so if we did do this by default, we would have to make Seahorse a dependency.
Indeed. If we involve the users in key creation, non technical ones will skip it which is a shame as we want privacy for everyone. One of the beauties of Matrix is that it handles key creation and key sharing for you. We should get some inspiration from that.
Those UIs look good to me. However, would everyone need to go through that step? Manually generating keys would discourage most people who don't know what keys are about. Couldn't it be like Matrix where one uses a toggle "encrypt this conversation" and keys are generated automatically? Automatic generated keys could be stored in the Chatty's config folder so one could easily retrieve them from copying their Chatty data from one device to another.
There could be a way, but the PGP key needs to have some representation of who it belongs to. If Chatty can pull the phone number, that could be auto filled, but I would think having a name attached to the phone number makes sense. I would think having a pop up that just asks for their name and phone number (or have that auto-filled) isn't that big of a hassle?
I also personally like having an "advanced" menu for anyone that wants to do something like attaching an already generated key, like in the above example, if I have a PGP key on the PGP card and others trust it already, I want to use it in Chatty. (I also like this also to show that there is "nothing up my sleeve" in how the encryption works on Chatty)
Your idea sounds very good to me @kop316. Having a simple box that asks for the phone number and the name would work. Especially as I guess it would be asked only once when setting up the first encrypted conversation.
It would need to have an understandable text with it that explains that this data is only required to protect the encryption keys and that it won't leave the device.
Having an advanced menu for PGP "experts" to use their own keys is great too!
Having a simple box that asks for the phone number and the name would work. Especially as I guess it would be asked only once when setting up the first encrypted conversation.
Sounds good! yeah that's what I was trying to set up, so we have a UI we can point to once this is set up.
It would need to have an understandable text with it that explains that this data is only required to protect the encryption keys and that it won't leave the device.
So the it won't leave the device part confuses me?
The Full Name and signing ID would be so that whomever is trusting the key can map it to someone, so by definition, those would have to leave the device. However, if you are exchanging information with another individual, they would likely have that information anyways (since you are communicating over SMS/MMS, and presumably the other person knows your name.
Are you trying to say something more like it isn't being transmitted to a server or something?
Yes. what I mean is that people's data should not be stored on a server. If the phone number and name is to go out to be stored on a server, that may be a privacy issue that most people will want to avoid.
So it's good to make it clear that filling the form with this private information won't arm people's privacy and that the data will remain safe.