@purism how is the USA edition project coming along ? is that to arrive earlier for evergreen or later ?
1 Like
When a call is received there is a line above the buttons saying “the call is not encrypted”. My question is when is a call encrypted? What is needed to make and receive encrypted calls? And how is this done?
2 Likes
? Not using the mobile phone network to make the call but instead placing a data call (internet) and using any one of a number of encrypted calling platforms.
Good question though as to how the dialler would actually know when the call over the internet is encrypted and when it is not.
2 Likes
As Calls is FLOSS you can review it’s source code. Doing so it seems that there is a property switching between showing encrpyted or unenctypted calls but I did not find any logic where it would trigger the function to show a call is encrypted. (https://source.puri.sm/Librem5/calls/blob/master/src/calls-encryption-indicator.c)
As kieran wrote with a data call (SIP or Matrix) it is possible to encrypt calls. The librem 5 advertised to be a “IP-Native Communication First” and “first ever Matrix-powered smartphone”, so in some future to me it seems plausible to implement such things.
2 Likes
Looking at the video I wondered about this:
- All the big data collecting companies are there: Google, Facebook, Microsoft. Only Apple is missing or is it off the screen on the list?
- Sort order? By importance?
- Giving people a choice? Maybe. Nudging them in the direction Purism stands for? Not really, yet.
5 Likes
there is “encrypted” and then there is the marketing term “end-to-end-ecrypted”
i say marketing term because even though what that means and how that is to be implemented is clearly documented and claimed to be already working by several service providers there is yet to be established a reliable and reproducible METHOD of PROVING that the said service functions and will CONTINUE to function as described …
Proton has done a good job of speaking about the first part of the equation (the client side)
1 > https://protonmail.com/blog/bridge-security-model/
2 > https://protonmail.com/blog/bridge-open-source/
but the server side leaves much to be desired in terms of a METHOD of establishing where the truth lies … one can make assumptions in the mean-time 
1 Like
@ChriChri That is not something Purism has made by themselves. They adopted the GNOME online accounts settings for mobile. But my hopes are still there that maybe purism or some other people would like to implement native CalDAV/CardDAV support without using Evolution first. Especially because there are no efforts to make that adaptive known to me - instead using Geary is the way purism is going.
1 Like
That’s fine, but it does not mean that one does not have to look into software and adopt it to the goals Purism has.
There are other things, too, that have been adopted (partly heavily) and I guess this one will be just a very small patch to have a big nudge into the wanted direction 
.
Moreover it is hardcoded into GOA, you cannot plug new neither remove old. Which is why I’m considering moving back to libaccounts
That 
You don’t need the Evolution mail client, only Evolution Data Server, you would need an application that could setup CalDAV/CardDAV there
You could of course do it by yourself and make a merge request. I think its just a matter of priorities and maybe a philosophical question because freedom of choice should IMO be important, too. The CalDAV/CardDAV feature on the other hand would also be a nice feature for upstream GNOME. Many people have already asked for that.
By the time my Librem 5 arrives I will have more time to dig into that I think. 
At the moment I am very busy with other (open source) projects. Maybe one could also use those nice GUI shell tutorials from the blog posts to create some importer.
1 Like
Thanks for the answers, however I still do not get the full picture yet.
-
On the calls app I see not possibility to place the call with Matrix. Is there such a thing? If I launch riot then what is this “call not encrypted” doing on the calls app? Something is missing here…
-
Why encryption does not pass through regular call? Makes no sense: why the phone can not encrypt before the signal gets to the modem and the receiving phone decrypts after the signal exits the modem, if the two callers have exchanged their keys before the calls are placed ?
It looks to me that some functionality is missing here, but maybe it is planned for future work. No?
For that to happen both ends of the conversation would need to support encryption.
this is something that we still want to develop in the future
Yes, it is
4 Likes
Because, at least in part, the raw PCM voice data is significantly compressed before transmission (for obvious reasons) and yet if you are going to do compression and encryption then you must do compression first (which then may or may not work when passed through the modem - which may want to do its own compression). In addition to that, the modem is also doing its own encryption for the hop (handset-to-tower). So, straight up, your protocol stack is a heap.
Another consideration is how well the adapted (fudged) protocol would handle loss of packets.
I’m not saying that it is impossible but the bottom line is that the voice call protocol is designed to work in a certain way, which doesn’t involve end-to-end encryption, and it may or may not be practical to adapt it in the way you describe. However don’t let me discourage you, once you get your phone.
Of course. Assume for a moment that both ends are on L5. Both have crypto keys and public keys have been exchanged. Now what? There must be a way. Future work, OK. But in theory it should be possible.
@kieran I do not understand the problem. If it is possible through Riot why it is not possible from regular calls?
No matter what you do at the end the modem passes the communications over to the tower. If it is vioce or data through Riot why does the modem care?
Because regular calls don’t use IP? It’s a bit (understatement) more complicated there I assume.
1 Like
yes they do but it’s called a phone number and the sim and the phone id are identified by the tower using standard methods implemented on a national or regional level as opposed to how ipv4 and ipv6 work in conjunction with the MAC address …
This is incorrect. IP is a protocol and a phone number is an identifier, maybe you are referring to an IP address which is also an identifier?
IP is a protocol and normal voice calls do not go over IP unless it’s VoLTE (Voice-over-LTE) which the Librem 5 does not support yet as far as I know. As you might know it was possible to make calls before the internet was created, hence phone calls do not go over the IP protocol. Cellular phone calls are not extendable as easily as most internet protocols for audio calls are which is why it’s not worth spending time on trying to encrypt them.
3 Likes
I seem to remember that GSM standards include provision for some kind of data call, which was used for ‘dial-up’ WAP services, and also for using the phone as a modem to connect to a normal ISP. I seem to remember you couldn’t use a normal modem that made audio tones down the phone, because the audio compression messed up the signal too much, so you had to use this special mode, with the phone itself acting as the modem.
So, it might be possible to instruct a modem to just send a stream of data to another modem, which could be the encrypted version of a compressed version of the audio data. Or it might not be possible. I have no idea what constraints exist on that kind of arrangement, or which modems might support it. I’m just vaguely remembering something and throwing it out there without doing any research.
They should not have chosen Gnome at all.
1 Like