Voice Calls: Secure, Crystal-Clear, AI-Powered(telegram.org)
telegram.org
Voice Calls: Secure, Crystal-Clear, AI-Powered
https://telegram.org/blog/calls
296 comments
>I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
Well, the first problem at home is likely your wireless. Live in an apartment and you can pick up 30 other routers in your wifi search. Chances are you're going to have latency and re-transmit issues to your AP.
Second problem, your router. Most of them suck. If you're lucky and yours doesn't setup QoS/shaping rules. I use fd_codel on mine to attempt to minimize the amount of buffer bloat that occurs. In the race to make your internet 'fast' huge buffers act like buckets for data, which is really bad if you want your data instantly. And if you search buffer bloat you'll see a lot of people talk about it, very few ISPs want to do anything about it though.
Lastly, the one you can't do anything about is the path that your data takes to the remote user. If it is overloaded or has capacity induced latency there isn't much you can do, other than change ISPs maybe.
Well, the first problem at home is likely your wireless. Live in an apartment and you can pick up 30 other routers in your wifi search. Chances are you're going to have latency and re-transmit issues to your AP.
Second problem, your router. Most of them suck. If you're lucky and yours doesn't setup QoS/shaping rules. I use fd_codel on mine to attempt to minimize the amount of buffer bloat that occurs. In the race to make your internet 'fast' huge buffers act like buckets for data, which is really bad if you want your data instantly. And if you search buffer bloat you'll see a lot of people talk about it, very few ISPs want to do anything about it though.
Lastly, the one you can't do anything about is the path that your data takes to the remote user. If it is overloaded or has capacity induced latency there isn't much you can do, other than change ISPs maybe.
For anyone interested, MIT's systems class has students read two different papers on buffer bloat:
http://web.mit.edu/6.033/www/papers/gettys.pdf
http://web.mit.edu/6.033/www/papers/allman.pdf
http://web.mit.edu/6.033/www/papers/gettys.pdf
http://web.mit.edu/6.033/www/papers/allman.pdf
I don't know much about the different router brands and models. Which would you consider to be some of the good ones?
I'm not an expert on routers but if I was in the market I would look at the Wirecutter. I find their recommendations pretty good.
thewirecutter.com/reviews/best-wi-fi-router/
thewirecutter.com/reviews/best-wi-fi-router/
Chiming in here with more anecdotal evidence - I always look in the Tomato (http://www.polarcloud.com/tomatofaq#what_will_this_run_on, http://tomato.groov.pl/?page_id=69) and DD-WRT (http://www.dd-wrt.com/site/support/router-database) "supported router" sections. Personally I like the Netgear routers which have semi-official support here: https://www.myopenrouter.com/
Draytek are a good choice at the consumer level.
Having used Drayteks, and supported them, and indeed having owned one (company supplied for site-to-site VPN) I wouldn't recommend them. The feature set is great, the router is not.
Fair enough. This is the problem with consumer gear, it's all so variable. For me, Draytek have been the only vaguely consistent vendor over the years. I've had countless issues with T-link, Asus and Netgear routers.
A starting point for me: LEDE support
That's: https://lede-project.org or:“Linux Embedded Development Environment” - the new project born from OpenWRT. I've used it with some old d-link routers, and I'm quite happy.
The documentation is still not stellar, but it has gotten better, and the configuration more consistent. It's quite easy to set up ssh-access with a key, and simply get a copy of configuration files with scp - ready to set up identical configurations on new router installs.
The documentation is still not stellar, but it has gotten better, and the configuration more consistent. It's quite easy to set up ssh-access with a key, and simply get a copy of configuration files with scp - ready to set up identical configurations on new router installs.
The Opus codec ( http://opus-codec.org/comparison/ ) can enable very low latency audio. 26.5 ms algorithmic delay (the time it takes to go through the algorithm) by default, but can be set to a very impressive 5ms. Digital audio can't achieve the near no-latency analog POTS has, but it can get pretty darn close e.g. if Opus is used in the very low latency mode. I believe Mumble and maybe TeamSpeak let you choose the Opus latency. I know some other apps like WhatsApp, Wire, and Signal use Opus as well. I don't know what settings they use though.
Another problem is cell phones add ~150ms latency (pre VoLTE) and people that route calls through Google Voice adds an additional 150ms+ latency on top. If you ever talk to someone on a cell phone on google voice, it sounds like they're calling from the moon.
150ms is about the human limit before turn-taking and talking over each other becomes an annoyance. That's why cell-to-landline conversations (150ms one way) were tolerable, but cell-to-cell (300ms one way) conversations are abysmal. And that's all in the same area code. Once you add long distance, it gets worse.
Another problem is cell phones add ~150ms latency (pre VoLTE) and people that route calls through Google Voice adds an additional 150ms+ latency on top. If you ever talk to someone on a cell phone on google voice, it sounds like they're calling from the moon.
150ms is about the human limit before turn-taking and talking over each other becomes an annoyance. That's why cell-to-landline conversations (150ms one way) were tolerable, but cell-to-cell (300ms one way) conversations are abysmal. And that's all in the same area code. Once you add long distance, it gets worse.
Just fyi, POTS is digital up until the very last mile. While the network is digital, it uses time multiplexed serial PCM streams under the hood. Aside from the delay imposed by fiber transmission at the trunk level (~40 milliseconds from one side of the US to the next. If you're using a long distance network that packetizes the connection or sends a call on some weird route, that can certainly increase), the g.711 encoding delay should be fixed at 0.125 milliseconds.
Interesting. I didn't know g.711 was so low. Typical VOIP latency must then stem from D/A and A/D conversion and internet latency.
g.711 has such low latency because it doesn't take advantage of inter-sample redundancy in any way whatsoever - it's just raw 8-bit samples at 8 ksps with a compander on either end (traditionally on the analog side of the DAC and ADC).
> I know some other apps like WhatsApp, Wire, and Signal use Opus as well
Opus is an evolution of SILK which is/was used in Skype.
Opus is an evolution of SILK which is/was used in Skype.
I think you can get < 5ms latency with Opus depending on the sample rate.
> But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
Maybe this is because traditional communications were built by people working exclusively in that field - and they eventually became true experts, with a deep understanding of the real issues.
Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter, and after this project will perhaps move on to work on Facebook games or whatever. Smart people to be sure, but their understanding of the field is necessarily superficial.
The fast rate of change in this industry explains many of the things that are ailing it currently.
Maybe this is because traditional communications were built by people working exclusively in that field - and they eventually became true experts, with a deep understanding of the real issues.
Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter, and after this project will perhaps move on to work on Facebook games or whatever. Smart people to be sure, but their understanding of the field is necessarily superficial.
The fast rate of change in this industry explains many of the things that are ailing it currently.
> Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter,
Skype has been around for 13 years. It isn't a young startup full of ex-node.js programmers.
WhatsApp also has some excellent infrastructure built on top of Erlang which has decades of experience and refinement of heavy-duty telecom usage baked into the framework.
If anything the experience of previous development trickles down and younger engineers benefit from that knowledge. But I'm not sure I buy the idea that you can only build great systems if you've only been doing that one category for your whole career.
The rate of jobs changes faster and in front-end development the pace of toolset changes pretty fast. But even in front-end development it's still the same languages. usually just the tools are the trendy part. And if it's switching languages every 5-7 yrs that knowledge of languages is transferable. I've only benefited as a programmer from exposure to many other languages (and projects).
Regardless, the hardcore backend guys you get to build this type of infrastructure isn't the same hipster front-end devs that Twitter hired in the early years to build out a consumer product. Consumer is very different than building out telecom infrastructure in Erlang/C++.
Skype has been around for 13 years. It isn't a young startup full of ex-node.js programmers.
WhatsApp also has some excellent infrastructure built on top of Erlang which has decades of experience and refinement of heavy-duty telecom usage baked into the framework.
If anything the experience of previous development trickles down and younger engineers benefit from that knowledge. But I'm not sure I buy the idea that you can only build great systems if you've only been doing that one category for your whole career.
The rate of jobs changes faster and in front-end development the pace of toolset changes pretty fast. But even in front-end development it's still the same languages. usually just the tools are the trendy part. And if it's switching languages every 5-7 yrs that knowledge of languages is transferable. I've only benefited as a programmer from exposure to many other languages (and projects).
Regardless, the hardcore backend guys you get to build this type of infrastructure isn't the same hipster front-end devs that Twitter hired in the early years to build out a consumer product. Consumer is very different than building out telecom infrastructure in Erlang/C++.
> I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
You're remembering incorrectly then. Dialup latency was in the range of hundreds of ms. Early high speed internet access also had higher latency than modern connections.
If you have latency problems it's likely a problem with your hardware.
You're remembering incorrectly then. Dialup latency was in the range of hundreds of ms. Early high speed internet access also had higher latency than modern connections.
If you have latency problems it's likely a problem with your hardware.
I don't remember dialup latency. I only remember it having low bandwidth. I'm talking about ADSL latency in the 90s.
Latency for a 56k modem was 180ms. Latency for a voice call on the same line was _much_ smaller. AFAICT, latency from my games console television to my TV is much higher...
300ms was not unusual on a 56k modem, if my memory serves.
180ms is what I got on WirePlay. The number is burnt into my brain. If the machine wasn't co-located, I can envisage it being a lot higher.
Yes, I believe you, I meant I don't remember what the latency was.
When I accessed the Internet over a "56k" modem connection, my network latency was less than 100 ms, so how could that be possible?
Cable tends to have a higher latency than aDSL. I don't know if that's the tech or just over-subscription on cables part. The trade off is in the bandwidth allowed so people mostly gave up that feature in exchange for enough bandwidth to do other stuff.
Unless you're hitting an IP node that transcodes to g.729 or something, landline phones should sound pretty good; the mu-law codec uses companded 8-bit PCM that roughly equates to about 14-bit linear in terms of precision. If you're sending a lot of very low frequencies (most phones and line cards have a pass filter in them to remove stuff below ~60-100 hertz, so while the network is very capable of sending it, it doesn't always in practice), you'll start to hear companding noise, but it's rarely the case that it gets loud enough to cause an issue.
As for the sample rate, 8 khz is a bit low, but you can make it sound significantly better with a bit of equalization; usually turning down frequencies near 1 khz a little goes a long way. Sometimes too, it doesn't hurt to gently (and I stress, gently) reduce frequencies near ~300 hertz if it sounds too muffled.
As for the sample rate, 8 khz is a bit low, but you can make it sound significantly better with a bit of equalization; usually turning down frequencies near 1 khz a little goes a long way. Sometimes too, it doesn't hurt to gently (and I stress, gently) reduce frequencies near ~300 hertz if it sounds too muffled.
The best phone voice quality is still ISDN. Digital all the way to the handset, and rigidly clocked with fixed delay. Switzerland has ISDN phones, and the voice quality is impressive.
I've noticed digital artifacting on radio broadcasts, particularly in rebroadcasting programmes from earlier in the day.
I've experienced this with multiple NPR affiliate stations where it's particularly noticeable for their generally high audio quality.
My suspicion is that audio is recorded with different codecs or at different bitrates, though I've never been able to establish this.
I've also not noted the problem for a few years, so it may have been addressed.
I've experienced this with multiple NPR affiliate stations where it's particularly noticeable for their generally high audio quality.
My suspicion is that audio is recorded with different codecs or at different bitrates, though I've never been able to establish this.
I've also not noted the problem for a few years, so it may have been addressed.
ISDN was 64kbps pet channel though - and to my knowledge did not use a wideband voice codec by default (or at least didn't mandate all ISDN receivers support wideband audio).
Lots of people who had ISDN kit plugged their old POTS phones into their TAs anyway.
Lots of people who had ISDN kit plugged their old POTS phones into their TAs anyway.
ISDN is actually used quite a bit in niche markets in the states. For studios, typically you'll see a couple B-channels bonded to give someone 128K MP3 or AAC. At a bare minimum, 64 kbps/16khz g.722 is used. I worked in a newsroom a few years ago where I frequently had to record a weather guy from a distant area who used this.
Used in STE units for secure communication as well:
https://en.wikipedia.org/wiki/Secure_Terminal_Equipment
https://en.wikipedia.org/wiki/Secure_Terminal_Equipment
Can relate, I remember enjoying more talking with friends in TeamSpeak than with my girlfriend via skype/hangouts/facebook call... now with a discord server, talking with friends is so much easier, but quality is not as good as TS... but still convenience beats quality, and the loss is not that bad.
I've been using TS recently on a consulting project, after my client suggested we use it, due to issues sometimes with Skype. Seems good so far, though not used it for many days yet. Needs a server though. The software is free for a basic version. I think it supports multiple people on the call, though we haven't tried that yet. And seems to have many features overall, not tried them out yet, but will try some over time.
Have you tried Amazon Chime? We are ridiculously aware of the latency issue in high quality voip. We do not at the moment support user generated keys the way Telegram does but we do use TLS/DTLS encryption end to end for our VOIP streams.
> We are ridiculously aware of the latency issue in high quality voip. We do not at the moment support user generated keys the way Telegram does but we do use TLS/DTLS encryption end to end for our VOIP streams.
Any plans to make this available to developers as a service via AWS?
Any plans to make this available to developers as a service via AWS?
Sorry, I can't really comment on our roadmap and our priorities within it.
>interleaving got enabled on my ADSL
What is interleaving in this context?
What is interleaving in this context?
Multiple data frames are interleaved and transmitted together. Good for error tolerance, since bursty noise doesn't wipe out a complete frame, but small parts of multiple ones, which then can individually be fixed by their Reed-Solomon error correction codes. But it adds latency, since the sender has to collect data from multiple frames to combine, and the receiver has to receive the entire block before it can be decoded, instead of transmitting each frame as it arrives.
Thanks.
Try using Skype over a 3G connection.
The latency is almost palpable.
The latency is almost palpable.
If you are on shitty wifi, no app will ever fix that.
If you're ok with the Chinese gov snooping, I find WeChat to be amazingly good at voice chat, even if your connection is bad.
"
Each time you make a Voice Call on Telegram, a neural network learns from your and your device‘s feedback (naturally, it doesn’t have access to the contents of the conversation, it has only technical information such as network speed, ping times, packet loss percentage, etc.). The machine optimizes dozens of parameters based on this input, improving the quality of future calls on the given device and network."
Is it just me or does this sound like serious bullshit? Unless you have some hard evidence of course...
Is it just me or does this sound like serious bullshit? Unless you have some hard evidence of course...
The 'neural network' is probably an SVM or logistic regression. There's nothing special that a neural network can learn with high-level features like network speed, ping times, etc.
In fact, it's probably just a TCP-like algorithm, i.e. decrease rate of packet sending if not getting ACKs back. One day, Intel might come out and say their microprocessors are AI-powered, since it has branch prediction.
In fact, it's probably just a TCP-like algorithm, i.e. decrease rate of packet sending if not getting ACKs back. One day, Intel might come out and say their microprocessors are AI-powered, since it has branch prediction.
I think that Samsung beat Intel to it:
"Neural network spotted deep inside Samsung's Galaxy S7 silicon brain (theregister.co.uk)" - https://news.ycombinator.com/item?id=12340348
"Neural network spotted deep inside Samsung's Galaxy S7 silicon brain (theregister.co.uk)" - https://news.ycombinator.com/item?id=12340348
AMD already claims that with zen platform if I recall correctly.
Which part? That it doesn't have access to the conversation, or that it improves the call quality?
"Each time you make a Voice Call on Telegram, a neural network learns from your and your device‘s feedback (naturally, it doesn’t have access to the contents of the conversation, it has only technical information such as network speed, ping times, packet loss percentage, etc.). The machine optimizes dozens of parameters based on this input, improving the quality of future calls on the given device and network."
What sort of parameters are adjusted?
What sort of parameters are adjusted?
I have the feeling that's there soley for the "AI-Powered" hype train benefit. Versus actually being used as a genuine feedback loop to improve the service.
Logs of speed, ping times, packet loss, would likely be more useful in good old, non-AI reports...to identify regional issues, peering opportunities, etc.
I don't think you need AI for voip calls that upgrade/degrade quality based on network health.
Logs of speed, ping times, packet loss, would likely be more useful in good old, non-AI reports...to identify regional issues, peering opportunities, etc.
I don't think you need AI for voip calls that upgrade/degrade quality based on network health.
Sounds like marketing speech for variable bitrate encoding and/or adjusting compression aggressiveness.
> variable bitrate encoding
I hope not... VBR can easily leak all sorts of information (including the actual content of the conversation)
I hope not... VBR can easily leak all sorts of information (including the actual content of the conversation)
Whoa, I had never thought of monitoring VBR as an attack vector for recovering audio.
Do you have a link discussing this?
Do you have a link discussing this?
Sure, here are a couple papers on the topic:
https://www.cs.jhu.edu/~cwright/oakland08.pdf
https://www.cs.jhu.edu/~cwright/voip-vbr.pdf
It's fundamentally very similar to the sorts of issues you end up with if you compress then encrypt. If the attacker can make some educated guesses about the plaintext prior to the compression, the compression ratio can be a very powerful tool in their arsenal.
https://www.cs.jhu.edu/~cwright/oakland08.pdf
https://www.cs.jhu.edu/~cwright/voip-vbr.pdf
It's fundamentally very similar to the sorts of issues you end up with if you compress then encrypt. If the attacker can make some educated guesses about the plaintext prior to the compression, the compression ratio can be a very powerful tool in their arsenal.
Wire implemented CBR for their encrypted calls, upstreamed it to WebRTC and submitted a patch to Signal, https://medium.com/wire-news/call-security-constant-bit-rate...
Silent Phone has used CBR since day 1.
Correct, last article I recall reading about deciphering VBR from packet size alone was something in the neighborhood of 50% success rate.
Then why not compress really efficiently by just transmitting packet sizes?
Because 50% of them won't be understood?
On the other hand, if you could do it, you'd probably have invented a convoluted speech-to-text (where text is a index into a dictionary of words). Note that you would also likely lose things like inflection, voice, accent etc - so while it might work as a texting system with voice input - it would be a poor substitute for voice chat..
Those codecs have tons of parameters to tweak (source: private conversation with Pavel Durov)
But what sort of parameters are adjusted?
This is HN. A link to an example would be appreciated.
Edit: To clarify, I work with audio codecs too, and can't really think of parameters (other than the compression level?) that would make much sense to adjust on the fly.
If "AI" is used for more than just a buzzword here, then I imagine the answer must be quite interesting.
This is HN. A link to an example would be appreciated.
Edit: To clarify, I work with audio codecs too, and can't really think of parameters (other than the compression level?) that would make much sense to adjust on the fly.
If "AI" is used for more than just a buzzword here, then I imagine the answer must be quite interesting.
They probably adjust the incoming / outgoing buffer sizes (and therefore the audio delay, since it's live) to account for packet loss.
They might also prioritize traffic depending on how full your buffers are.
I can only assume Youtube and Netflix do similar parameter tweaks to optimize their video delivery based on the connection (totally filling the buffer to a max size all the time would waste bandwidth, but if the client has lots of packet loss they need a larger safety net).
They might also prioritize traffic depending on how full your buffers are.
I can only assume Youtube and Netflix do similar parameter tweaks to optimize their video delivery based on the connection (totally filling the buffer to a max size all the time would waste bandwidth, but if the client has lots of packet loss they need a larger safety net).
Right, looks like we're up to maybe 6 parameters. The claim was dozens which i take to mean at least 24, possibly 36 as the lower bound.
Does anyone have an opinion on the new "three-message modification of the standard DH key exchange" they introduced for calls?
From their API doc: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
> Party A will generate a shared key with B — or whoever pretends to be B — without having a second chance to change its exponent a depending on the value g_b received from the other side; and the impostor will not have a chance to adapt his value of b depending on g_a, because it has to commit to a value of g_b before learning g_a.
> The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct visualization in their attack, which means that using just over 33 bits of entropy represented by four emoji in the visualization is enough to make a successful attack highly improbable.
From their API doc: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
> Party A will generate a shared key with B — or whoever pretends to be B — without having a second chance to change its exponent a depending on the value g_b received from the other side; and the impostor will not have a chance to adapt his value of b depending on g_a, because it has to commit to a value of g_b before learning g_a.
> The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct visualization in their attack, which means that using just over 33 bits of entropy represented by four emoji in the visualization is enough to make a successful attack highly improbable.
I like it. I tried to explain it in slightly simpler terms to some friends in a group chat like this:
> reading about the emoticon generation thingy, it's actually worth a read
> they use a DH KEX[1], but wrapped with something which is interesting. Client A generates a, client B generates b, and g seems to be an already-exchanged finite group generator. That's all standard.
[1] diffie-hellman key exchange
> now before A sends g^a to B, it will send hash(g^a) to B. B responds as normal (with g^b) to which A will respond with what it normally would send first: g^a.
> after receiving g^a, B can check whether the initially received hash(g^a) matches. This means that A can't brute force a specific value of a, so it doesn't matter that it's only 33 bits of entropy in that emoticon thingy. Any brute forcing will change the hash (unless you collide, iirc, sha256) and B will go "dude wtf" and kill the connection
> I tried to summarize in more understandable terms, but if it's too shortened or something, the original thing is here: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
> reading about the emoticon generation thingy, it's actually worth a read
> they use a DH KEX[1], but wrapped with something which is interesting. Client A generates a, client B generates b, and g seems to be an already-exchanged finite group generator. That's all standard.
[1] diffie-hellman key exchange
> now before A sends g^a to B, it will send hash(g^a) to B. B responds as normal (with g^b) to which A will respond with what it normally would send first: g^a.
> after receiving g^a, B can check whether the initially received hash(g^a) matches. This means that A can't brute force a specific value of a, so it doesn't matter that it's only 33 bits of entropy in that emoticon thingy. Any brute forcing will change the hash (unless you collide, iirc, sha256) and B will go "dude wtf" and kill the connection
> I tried to summarize in more understandable terms, but if it's too shortened or something, the original thing is here: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
I haven't personally reviewed it, but based on their previous inability to make principled cryptographic choices and resistance to critical feedback from actual cryptographers… I'm skeptical.
can you point to some examples where the resisted critical feedback? I've heard people mention this but haven't actually seen anything convincing yet
Read up the comments on the telegram announcement post here on HN. From couple of years back, IIRC.
PS: on mobile. Could not.search.
PS: on mobile. Could not.search.
Found it [1].
tldr: First message from TelegramApp has some marketing copy ("acm winner phds") but not horrible. The TelegramApp user remains calm/careful and mostly polite in every message after that. There are only a few cases of sideways slapping and they come from HN users. Despite this the conversation between TelegramApp and HN users remain informative debate and discussion.
1. https://news.ycombinator.com/item?id=6913456
tldr: First message from TelegramApp has some marketing copy ("acm winner phds") but not horrible. The TelegramApp user remains calm/careful and mostly polite in every message after that. There are only a few cases of sideways slapping and they come from HN users. Despite this the conversation between TelegramApp and HN users remain informative debate and discussion.
1. https://news.ycombinator.com/item?id=6913456
Being cordial and polite on Hacker News wasn't my concern. My concern is their repeated dismissal of feedback from experienced cryptographers.
Cryptographers can't seem to make sense of a lot of their design decisions in the MTProto protocol. Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
Given how fragile cryptography can be, this is an absurdly irresponsible way to maintain a cryptosystem. Modern cryptographic designs try to be very principled, and steps are taken to prevent any kind of theoretical weakness, even if we don't know how to break it in practice. This is because cryptographic breaks only ever get stronger — never weaker.
As an example, TLS 1.0 using doing authentication for CBC modes with MAC-then-Encrypt was known to be weak, but it was only years later when researchers were able to turn this into a plaintext-leaking break. And MTProto is absolutely littered with unconventional or known-weak constructs, giving a lot of potential levers attackers can use to break it.
You might argue that it's fine for this to be the case, as long as they respond quickly to protocol breaks. The problem is, the good guys only learned how to break TLS 1.0 CBC when the attack was published. Did the NSA/CIA/GRU/FSB know about these attacks before we did? There's no way to know. But if it had conservatively chosen an Encrypt-then-MAC scheme to begin with, such an attack would have never been possible in the first place.
That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
Cryptographers can't seem to make sense of a lot of their design decisions in the MTProto protocol. Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
Given how fragile cryptography can be, this is an absurdly irresponsible way to maintain a cryptosystem. Modern cryptographic designs try to be very principled, and steps are taken to prevent any kind of theoretical weakness, even if we don't know how to break it in practice. This is because cryptographic breaks only ever get stronger — never weaker.
As an example, TLS 1.0 using doing authentication for CBC modes with MAC-then-Encrypt was known to be weak, but it was only years later when researchers were able to turn this into a plaintext-leaking break. And MTProto is absolutely littered with unconventional or known-weak constructs, giving a lot of potential levers attackers can use to break it.
You might argue that it's fine for this to be the case, as long as they respond quickly to protocol breaks. The problem is, the good guys only learned how to break TLS 1.0 CBC when the attack was published. Did the NSA/CIA/GRU/FSB know about these attacks before we did? There's no way to know. But if it had conservatively chosen an Encrypt-then-MAC scheme to begin with, such an attack would have never been possible in the first place.
That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
I read through the linked thread in my previous post and I think it gives a good idea of the rift between the in-house-HN-cryptographers and those at Telegram. One will find the exact same disconnect between cryptographers that worked under heavy computational constraints, and those that have not. For example, in the Satellite TV industry.
The Telegram designers built a protocol with anticipation of some constraints. But rather than debate the plausability of the percieved constraints, the HN-crowd just dug into whatever they already knew and threw in a lot of snark in their response to close the door.
> Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
I haven't seen that. I went looking for it. If you have the patience and time please dig up a link or quote.
> That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
I did see a good bit of discussion about the feasability of some of the weakness pointed out. They responded in a way that seemed to indicate they fully understood the issue but "chose" to take the risk. I'm not sure this means "they don't care". Perhaps it does. But this is where I started to see that the rift here was really about the perception of constraints, not lack of knowledge or, in my opinion, lack of care.
The Telegram designers built a protocol with anticipation of some constraints. But rather than debate the plausability of the percieved constraints, the HN-crowd just dug into whatever they already knew and threw in a lot of snark in their response to close the door.
> Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
I haven't seen that. I went looking for it. If you have the patience and time please dig up a link or quote.
> That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
I did see a good bit of discussion about the feasability of some of the weakness pointed out. They responded in a way that seemed to indicate they fully understood the issue but "chose" to take the risk. I'm not sure this means "they don't care". Perhaps it does. But this is where I started to see that the rift here was really about the perception of constraints, not lack of knowledge or, in my opinion, lack of care.
https://news.ycombinator.com/threads?id=paveldurov
By the way, it is also worth noting that Nikolai Durov, designer of MTProto, is completely absent from any public discussions of that protocol. Doesn't like talking to the plebs, I suppose.
By the way, it is also worth noting that Nikolai Durov, designer of MTProto, is completely absent from any public discussions of that protocol. Doesn't like talking to the plebs, I suppose.
That just sounds like ZRTP to me, from the short description in your comment.
If it is it will be interesting to see if they managed to get zrtp correct. It is a pretty complicated protocol with many use cases.
I've managed to setup Telegram for most of my (non-technical) family - wife, siblings, mother (she doesn't even have a smart phone and just uses Telegram as a message client on her desktop. It's a very convenient way to share family related pictures).
Voice calls are an excellent addition. If these could now also be extended to video calls, I could likely ditch Skype forever.
Voice calls are an excellent addition. If these could now also be extended to video calls, I could likely ditch Skype forever.
A client of mine once explicitly asked to communicate via Wire [1] which is pretty similar to Skype but E2E encrypted.
It was launched by a Skype co-founder, is easy to use and has a pleasant interface. And it's open source.
I can't really tell if the product really does what it's advertising, perhaps someone with more expertise could chime in on that.
I got stuck on it and I'm considering ditching Skype altogether for it. Perhaps not the solution you were looking for but interesting nonetheless!
[1] - https://wire.com/en/
[1] - https://wire.com/en/
It's open source indeed [1] and was recently audited for the quality of the crypto protocol implementation [2]. Not sure what questions you specifically have but I'm happy to answer as I'm part of the team.
[1] https://github.com/wireapp [2]https://medium.com/wire-news/wires-independent-security-revi...
[1] https://github.com/wireapp [2]https://medium.com/wire-news/wires-independent-security-revi...
I used it for a year with friends and family. I have never in my life experienced a buggier app on Android. My friends and family said the same about it. The seem to focus on bringing new features (like an alien voice FX feature) when they should try to fix the basics first.
I can +1 Wire. After looking into it, I was very pleasantly surprised.
It's not as good as Telegram's UI and featureset, but they're much newer/younger still. I'm starting to use it more and more.
It's not as good as Telegram's UI and featureset, but they're much newer/younger still. I'm starting to use it more and more.
It's great, but they went JS for all their clients.
The desktop client is electron, and there's no way their Android app is native, it feels like a WebView.
Native apps really do make the experience that much better.
The desktop client is electron, and there's no way their Android app is native, it feels like a WebView.
Native apps really do make the experience that much better.
Make them switch yet again to Signal? ;)
Most of my family is on iPhone's, while I'm using Android. I tried using Wire as a substitute for Facetime (my 3 year old doesn't consider it a real phone call unless there's video), but it was way too buggy and people would just get annoyed.
Signal's new video chat, however, has worked really well after it got out of beta. There aren't many apps that manage to do video calls well between Android and iPhone, I'm a bit surprised that that feature hasn't gotten more attention.
Most of my family is on iPhone's, while I'm using Android. I tried using Wire as a substitute for Facetime (my 3 year old doesn't consider it a real phone call unless there's video), but it was way too buggy and people would just get annoyed.
Signal's new video chat, however, has worked really well after it got out of beta. There aren't many apps that manage to do video calls well between Android and iPhone, I'm a bit surprised that that feature hasn't gotten more attention.
I'm using Telegram as my main messaging system but I hope they'll open source everything. That's the only way to fully audit the service.
Telegram is not too bad but has too many grey areas at this moment.
Telegram is not too bad but has too many grey areas at this moment.
I think at this point it's quite clear they are not ever going to do that. They actually stopped publishing their client source code and they aren't responding to any questions about that.
https://twitter.com/durov/status/847454485882355713
> Definitely, updated source codes will be online later today.
And the Desktop client[1] is kept very up to date. My biggest complaint is that they have stopped updating the API documentation [2] which has lead me to become a rather lukewarm telegram developer (though I still have a few projects I am work with)
[1] https://github.com/telegramdesktop/tdesktop [2] https://core.telegram.org/#updates-log
> Definitely, updated source codes will be online later today.
And the Desktop client[1] is kept very up to date. My biggest complaint is that they have stopped updating the API documentation [2] which has lead me to become a rather lukewarm telegram developer (though I still have a few projects I am work with)
[1] https://github.com/telegramdesktop/tdesktop [2] https://core.telegram.org/#updates-log
How do you ensure that the code you have access to is the code running on their servers? Having access to some source doesn't help with that.
Unless you strictly use end to end, only after having verified the keys, you are trusting the server quite a lot.
Unless you strictly use end to end, only after having verified the keys, you are trusting the server quite a lot.
Of course. That's part of the grey areas I mentioned.
My question is how a source audit addresses the server trust issue...
It doesn't? Or at least I can't see how it would.
>I'm using Telegram as my main messaging system but I hope they'll open source everything.
A bit too late, now that you're using as your main system.
A bit too late, now that you're using as your main system.
I'm using an Ubuntu Phone and Telegram is the only native messaging service app in it.
I'm using UP for a beta-testing purpose so no big deal.
I'm using UP for a beta-testing purpose so no big deal.
Really? I just get a white screen on mine. I see from reviews that others have the same problem.
I've never looked into logs though, so a fix might be obvious
I've never looked into logs though, so a fix might be obvious
Really. I got 99 ubuntu bugs but Telegram ain't one.
Once in a while I got a blank screen opening Telegram, but closing it and open it again solves the problem.
Are you running OTA-15?
Once in a while I got a blank screen opening Telegram, but closing it and open it again solves the problem.
Are you running OTA-15?
Yup, OTA-15. I've restarted it a few times, and it just gives me a white screen.
First check you're running the last Telegram version, that's 2.3.36.2
Second, have you tried to delete the cache (.cache/com.ubuntu.telegram)? That will erase your secret chats too, so you can make a copy before deleting it.
Second, have you tried to delete the cache (.cache/com.ubuntu.telegram)? That will erase your secret chats too, so you can make a copy before deleting it.
Yup, latest version. I tried clearing the cache and no change. Since I was in console, I just checked syslog and I'm getting a dbus DENIED. I'll poke at it when I have more time, but I wonder if they need to fix up their apparmor perms.
Curious as to why your getting a different result though.
EDIT: I'd also be curious as to your opinion of Touch in general?
My opinion: I love it. I'm not a huge fan of Unity, or Ubuntu, and it's definitely in the beta stage. I like that most of the problems that I have were solvable on my own via shell-script or whatever hacks I come up with.
Curious as to why your getting a different result though.
EDIT: I'd also be curious as to your opinion of Touch in general?
My opinion: I love it. I'm not a huge fan of Unity, or Ubuntu, and it's definitely in the beta stage. I like that most of the problems that I have were solvable on my own via shell-script or whatever hacks I come up with.
Oh sh*t I'm just remembering now a problem some people had with lock files. I thought it was fixed [0].
In that thread someone said deleting .config/com.ubuntu.telegram/<number>/auth.lock solved the problem with Telegram not starting [1].
So look for .lock file/s and delete it/them.
I still love Debian way more than Ubuntu, but I think they're doing a great work with Touch.
[0] https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-...
[1] https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-...
In that thread someone said deleting .config/com.ubuntu.telegram/<number>/auth.lock solved the problem with Telegram not starting [1].
So look for .lock file/s and delete it/them.
I still love Debian way more than Ubuntu, but I think they're doing a great work with Touch.
[0] https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-...
[1] https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-...
Hmmm.... I don't have any lock files. I'll dig into it when I get more time. thanks
Client and protocol are open source. What more do you need?
They have stopped publishing the source code for their clients.
They have?
https://github.com/telegramdesktop/tdesktop seems fairly up to date?
https://github.com/telegramdesktop/tdesktop seems fairly up to date?
Latest commit on the Android version was six months ago: https://github.com/DrKLO/Telegram
And yes, that's the official location of the Android app, linked here: https://telegram.org/apps
And yes, that's the official location of the Android app, linked here: https://telegram.org/apps
it seems they are watching, they've uploaded the newer version
Reproducible builds, and deploying my own server.
And a believable business model would be cool.
Signal has this as well. I trust their security (personal bias), but unfortunately the call quality is a non-starter at the moment.
They've rolled out a new version of video/voice calls this month[1] which supposedly improved the quality quite a bit. I haven't personally tried it yet, though.
[1]: https://whispersystems.org/blog/signal-video-calls/
[1]: https://whispersystems.org/blog/signal-video-calls/
I was recently surprised by a Signal call and the quality was surprisingly good compared to my previous experiences. I would give it another try.
As does Wire, just for the record.
They are one of the newer kids on the block. Open sourced in March 2016, End to End encrypted (everything and by default) since June 2016 (or the other way around). Supports chats, calls, video calls, file transfers and multiple devices (including Linux, though Electron...).
They are one of the newer kids on the block. Open sourced in March 2016, End to End encrypted (everything and by default) since June 2016 (or the other way around). Supports chats, calls, video calls, file transfers and multiple devices (including Linux, though Electron...).
Call quality is much better now. I believe it's a combination of direct peer to peer stream support and a switch from Speex to Opus.
Newest version has improved quality immensely.
Their latest build has WebRTC calls, which improved quality dramatically.
The emoji out of band authentication is cool, but probably annoying. You have to read those emoji by voice to the other end, so they can check them. That could be a pain if the emoji are chosen randomly from the 2600 available emoji.
The idea comes from the STU-3 secure phone, where there was a 2-digit number display to be read back by voice. It's one of the ways to detect a man-in-the-middle attack. If there's a MITM, the crypto bits sent and received are different, because the MITM is re-encrypting, and this is detectable if you have some out of band channel for comparing them. A MITM would thus have to be able to fake the voice of the other party.
With techniques like this, you can make an MITM work arbitrarily hard to maintain the illusion that it's the other party. I've proposed some ways to do this for web pages.
The idea comes from the STU-3 secure phone, where there was a 2-digit number display to be read back by voice. It's one of the ways to detect a man-in-the-middle attack. If there's a MITM, the crypto bits sent and received are different, because the MITM is re-encrypting, and this is detectable if you have some out of band channel for comparing them. A MITM would thus have to be able to fake the voice of the other party.
With techniques like this, you can make an MITM work arbitrarily hard to maintain the illusion that it's the other party. I've proposed some ways to do this for web pages.
But seriously how do they pay their bills?
(I know VK brothers are super rich)
There are bots that relay huge media files
It's probably (imo) the fastest & most complete cloud based chat app
Everything.. Literally everything you share can be retrived over the cloud
& and now calling
That must be super expensive infrastructure? No investors no monetization
There are bots that relay huge media files
It's probably (imo) the fastest & most complete cloud based chat app
Everything.. Literally everything you share can be retrived over the cloud
& and now calling
That must be super expensive infrastructure? No investors no monetization
They're sitting on troves of data. Extremely few use the E2E encrypted "secure chat" feature (mainly because it isn't default, but also because it doesn't sync between devices) and all the chat logs and data are stored on their servers (and are readable by Telegram). They also store your address book on their servers.
I'm sure they will find ways monetize this. Data is the "new gold", as they say[1]...
[1] https://www.google.com/#q="data+is+the+new+gold"
I'm sure they will find ways monetize this. Data is the "new gold", as they say[1]...
[1] https://www.google.com/#q="data+is+the+new+gold"
Their FAQ[1] states:
Q: Will you have ads? Or sell my data? Or steal my beloved and enslave my children? No.
So I don't think they will make money by selling data.
[1] https://telegram.org/faq#q-will-you-have-ads-or-sell-my-data...
Q: Will you have ads? Or sell my data? Or steal my beloved and enslave my children? No.
So I don't think they will make money by selling data.
[1] https://telegram.org/faq#q-will-you-have-ads-or-sell-my-data...
And what in the world makes you think that a company run by a russian nationalist[1] offering a free service with a million dollar bill will stick by their word (which, in this case is literally a single word)? The naivety of people in this post Snowden world is striking to me.
[1] https://www.instagram.com/p/-MrPWGr7aL/
[1] https://www.instagram.com/p/-MrPWGr7aL/
An FAQ isn't binding. What does their TOS say?
Are you really serious? This is a post snowden society.
> An FAQ isn't binding.
Probably not, but please beware that this service is not subject to US law, but the laws of the Russian Federation.
> What does their TOS say?
TOS are subject to change, right? And even if it wasn't, do you really think the TOS will stop a company run by a russian nationalist[1] offering a free service with a million dollar bill will stick by their word (which, in this case is literally a single word)?
[1] https://www.instagram.com/p/-MrPWGr7aL/
> An FAQ isn't binding.
Probably not, but please beware that this service is not subject to US law, but the laws of the Russian Federation.
> What does their TOS say?
TOS are subject to change, right? And even if it wasn't, do you really think the TOS will stop a company run by a russian nationalist[1] offering a free service with a million dollar bill will stick by their word (which, in this case is literally a single word)?
[1] https://www.instagram.com/p/-MrPWGr7aL/
> service is not subject to US law, but the laws of the Russian Federation
They are not registered in Russia, afaik.
> russian nationalist[1] … [1] https://www.instagram.com/p/-MrPWGr7aL/
That's just Pavel's usual populism. He says the same things about Russia or pretty much anything.
They are not registered in Russia, afaik.
> russian nationalist[1] … [1] https://www.instagram.com/p/-MrPWGr7aL/
That's just Pavel's usual populism. He says the same things about Russia or pretty much anything.
>They are not registered in Russia, afaik.
They are writing the software in Russia (right next to the VK's door to be precise), though. Source: local Saint-Petersburg newspapers.
They are writing the software in Russia (right next to the VK's door to be precise), though. Source: local Saint-Petersburg newspapers.
Why isn't the FAQ binding, do they disclaim it elsewhere?
I remember them mention about making a good messaging app without calling fluff (can't exactly point to which blog/faq)
Telegram is losing millions each year, paid by Pavel Durov, its founder.
"If you look at Telegram today, every month it burns over $1 million. It might seem that it’s just going nowhere, but if you want to come up with business model, you need to get to a decent size first. We have 62 million users at the moment, which is enough userbase to attract third-party developers to create products on top of your platform. You can’t do that from day one. It’s difficult."
http://kernelmag.dailydot.com/issue-sections/features-issue-...
I suspect the cost is even higher now.
"If you look at Telegram today, every month it burns over $1 million. It might seem that it’s just going nowhere, but if you want to come up with business model, you need to get to a decent size first. We have 62 million users at the moment, which is enough userbase to attract third-party developers to create products on top of your platform. You can’t do that from day one. It’s difficult."
http://kernelmag.dailydot.com/issue-sections/features-issue-...
I suspect the cost is even higher now.
Isn't this just hoping that products come along that use your platform and that people are willing to pay for that? Doesn't seem a good strategy to my limited understanding.
Also, experience has taught that users are fickle and that products that are free that transition to paid products quickly lose their users.
Also, experience has taught that users are fickle and that products that are free that transition to paid products quickly lose their users.
I tried https://appear.in recently for a short call with a student and it worked well. A friend and fellow freelancer also uses it, he said. One good point about it is if you need to do a quick ad-hoc call - it is browser-based (probably uses WebRTC), and also does not need to you create an account or sign in. Plan to try it more in future, as well as TeamSpeak which I also mentioned in this thread. I had installed Wire too, both on PC and Android phone, but not tried it yet with anyone.
Closed source, not end-to-end encrypted by default, end-to-end only device to device (so I can't swap seamlessly from a desktop to a mobile session).
Not even the protocoll is open, so I am bound to their clients.
Sadly it was the only nice alternative when the snowden stuff was published. That means those of my peers who made it away from skype/fb/whatsapp are now on telegram.
Sadly it was the only nice alternative when the snowden stuff was published. That means those of my peers who made it away from skype/fb/whatsapp are now on telegram.
> end-to-end only device to device (so I can't swap seamlessly from a desktop to a mobile session)
How do you accomplish a seamless swap from desktop to a mobile session using end-to-end encryption?
How do you accomplish a seamless swap from desktop to a mobile session using end-to-end encryption?
https://riot.im
Most seamless end-to-end encrypted solution I've come across. And it's still in beta. Every piece is open source (I'm running my own server), it's federated, supports history sync as a first-citizen feature, individual read receipts for group messages. The UX is not as polished as Telegram, but it's improving rapidly and is more than usable as a daily driver.
Most seamless end-to-end encrypted solution I've come across. And it's still in beta. Every piece is open source (I'm running my own server), it's federated, supports history sync as a first-citizen feature, individual read receipts for group messages. The UX is not as polished as Telegram, but it's improving rapidly and is more than usable as a daily driver.
How is the quality of web based VoIP through the browsers in your hosted riot.im ?
Using riot.im/app/ to communicate with others worked surprisingly well, quality seemed good.
I ended up installing Mumble in aws because I only need voice.
iMessage has end to end encryption and supports multiple devices. Each device uses its own keypair and when a message is sent, it is sent encrypted for each of the recipient's devices.
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
How do I find out that my recipient has a new device/public key that they'd like me to encrypt with?
If it's because Apple tells me so then I think can see that the end to end encryption is broken and interception is possible.
Are old messages re-encrypted with the new key?
This would be even worse.
If it's because Apple tells me so then I think can see that the end to end encryption is broken and interception is possible.
Are old messages re-encrypted with the new key?
This would be even worse.
iMessage does not allow for any out-of-band key verification. It's correct that that Apple (and anyone compromising them) is in a position to change the recipient's key or add new ones without the sender noticing anything's going on. I think iMessage limits this to new messages. (I believe syncing is done through iCloud, which doesn't use E2E-crypto but is optional.)
It would still be possible to implement this in a secure way (including out-of-band key verification) by having the "original" key (the one you've compared out-of-band) sign keys for new devices and have the server deliver that signature (which the sender can then verify). I don't know if there are any implementations of this.
It would still be possible to implement this in a secure way (including out-of-band key verification) by having the "original" key (the one you've compared out-of-band) sign keys for new devices and have the server deliver that signature (which the sender can then verify). I don't know if there are any implementations of this.
The hard part is how do you manage a list of trusted devices.
The thing which is really sad is that there are no end to end encrypted group chats.
The thing which is really sad is that there are no end to end encrypted group chats.
https://riot.im is doing this.
e2e is in beta still, but they have key list management/verification in place already.
e2e is in beta still, but they have key list management/verification in place already.
> The thing which is really sad is that there are no end to end encrypted group chats.
In iMessage specifically, or in general? WhatsApp/Signal do use E2E-crypto for group chats.
In iMessage specifically, or in general? WhatsApp/Signal do use E2E-crypto for group chats.
I highly recommend you check out WIRE. Cheers
Wire? I used it for a year with friends and family. I have never in my life experienced a buggier app on Android. My friends and family said the same about it.
They seem to focus on bringing new features (like an alien voice FX feature) when they should try to fix the basics first.
The worst thing that happened to me was that UI told me I was in a chat with Alice, but I soon realized I was actually chatting with Bob. So much for E2E...
Now we use https://riot.im. I'm kind of surprised a federated solution offers a decent UX and is less buggy.
They seem to focus on bringing new features (like an alien voice FX feature) when they should try to fix the basics first.
The worst thing that happened to me was that UI told me I was in a chat with Alice, but I soon realized I was actually chatting with Bob. So much for E2E...
Now we use https://riot.im. I'm kind of surprised a federated solution offers a decent UX and is less buggy.
There is no way riot is less buggy. Try macos to macos Sierra to Yosemite voice call. It segfaults right away.
Wire is buggy but generally works. The main problem with it is that metadata is collected by default.
Wire is buggy but generally works. The main problem with it is that metadata is collected by default.
Never experienced anything like that on Riot. I mostly call from Android to other Android and iOS phones though.
I'd say we had a 40% chance of actually connecting a call with Wire. Suddenly there was an update to the app and calling didn't work _at all_ until the next update came (this happened more than once).
A close relative finally gave up and yelled something along the lines of "who the f* uses this POS app", and I couldn't really argue. :)
I'd say we had a 40% chance of actually connecting a call with Wire. Suddenly there was an update to the app and calling didn't work _at all_ until the next update came (this happened more than once).
A close relative finally gave up and yelled something along the lines of "who the f* uses this POS app", and I couldn't really argue. :)
e2e on Riot/Matrix is in beta. I've had some experiences with someone else in a group chat only being able to read messages on one of their devices, and this is apparently not uncommon.
I'm a firm believer that Matrix is the future. But right now I wouldn't recommend it to anyone that isn't an early adopter.
I'm a firm believer that Matrix is the future. But right now I wouldn't recommend it to anyone that isn't an early adopter.
We're not aware of any crashes at all on Riot/Desktop (especially as it's an electron app, so crashes will be due to chromium bugs). Please can you make sure it's filed on https://github.com/vector-im/riot-web/issues? thanks!
It was on MacOS desktop. I'll submit an issue when I get a chance to reproduce.
Ok I updated the app and now it is not crashing! Thanks for a great product.
The problem is the friction of making all my peers switch
And one should probably switch straight to Signal anyway if an effort for that was made.
I share your concerns but the protocol is open. https://core.telegram.org/mtproto
All official clients are open source so you can fork them or create a new one from scratch.
All official clients are open source so you can fork them or create a new one from scratch.
But NOBODY I know actually uses the secure chat feature — mainly because it isn't default, but also because it doesn't sync between devices.
The lack of sync is a feature. That's what you get when you have a secure system.
How come https://riot.im (Matrix) manages to sync between devices AND have E2E, while also being federated?
That's not what you get when you have a secure system, that's what you get when you design a system that can collect (and possibly monetize) the data of millions of users.
That's not what you get when you have a secure system, that's what you get when you design a system that can collect (and possibly monetize) the data of millions of users.
I believe that making sync work with E2E bring either security issues or more burden on the user; I would like them in telegram, but I also like the "if you send this message you exactly the device it go to, not an old laptop i forgot in the office, just my phone". it is meant to be secure on a device level.
That's not what I meant. Yes you can have sync and E2E. With different trade-offs.
Telegram is secure from device to device, not from account to account. If I send you a secure message from my iPad I don't have to worry about the web session I opened a week ago on someone else laptop.
Telegram is secure from device to device, not from account to account. If I send you a secure message from my iPad I don't have to worry about the web session I opened a week ago on someone else laptop.
People down voting this comment, care to explain what's wrong with it?
Signal and WhatsApp both support multi-device encrypted chats. Signal is better than WhatsApp in this respect as your primary device doesn't need to be online for it to work.
Signal multi-device support is very limited. Doesn't support multiple mobile devices. Primary device must be a phone, all others must be desktop computers with Chrome.
This. I would love for Signal to have multiple mobile device support.
True, though that's a gap in UI rather than a constraint of the protocol.
If you want to use a standalone app then you can achieve it using NW.js
https://timtaubert.de/blog/2016/01/build-your-own-signal-des...
https://timtaubert.de/blog/2016/01/build-your-own-signal-des...
And its not even available, at least on the linux desktop version.
It just means that nobody you know sells drugs or does other stuff that forces people to choose privacy over convenience.
How come https://riot.im (Matrix) manages to sync between devices AND have E2E, while also being federated? How come I can use both WhatsApp and Signal on both my computer and phone (and they stay in sync)?
It looks like in [1] that each device registered to a user has a device_key and when an encrypted message is sent, they user's public devices keys are requested and the message is encrypted for each device. New devices can't see old messages.
[1] https://matrix.org/docs/guides/e2e_implementation.html
[1] https://matrix.org/docs/guides/e2e_implementation.html
The message isn't encrypted for each device; the message is encrypted once for the room, as part of a 'session' of messages - and then the key data for that session is shared with the devices who are allowed to read it. Thus you can share old session key data with other devices if you want, meaning that new devices /can/ see old messages, although we're still working through the UX for that. (Currently the only way to do it is by import/export session key data in settings and transferring it between devices).
Thanks—so there's another layer of encryption over the ever changing (Megolm) key that encrypts the room, if I understand this. Looks like I simplified too much.
Sort of. Just to clerify: the first layer (Olm) provides a secure channel between pairs of devices, used mainly to share Megolm encryption state between them.
The second layer (Megolm) encrypts each sent message once per room, using a ratchet described by session key data. The session key data is shared 1:1 between the appropriate devices (past and future) over Olm.
The second layer (Megolm) encrypts each sent message once per room, using a ratchet described by session key data. The session key data is shared 1:1 between the appropriate devices (past and future) over Olm.
[deleted]
WhatsApp on your computer uses your phone as proxy, so it's kind of cheating (you never get the data in 2 devices).
The two "main" clients for Android and iOS are no longer open source.
Conference calls! That's what we need in a whatsapp/telegram like app. Make it a reality to see the end of telco domination in the voice space.
This is your periodic reminder that Telegram uses sketchy crypto and should be avoided.
Most people who I know use Telegram(me included) use it because it's frankly the nicest(fast, looks good) Messenger out there, not because of its security features. Personally I don't use the secret chat functionality; I would use Signal if I wanted to communicate securely.
I don't choose my car for its seatbelts, but if they are broken, I reject the car.
Right, because you use seat belts every time you drive. So they are always a factor.
I do not use Telegrams security features though, so whether they are any good isn't relevant to me(and many other people).
I do not use Telegrams security features though, so whether they are any good isn't relevant to me(and many other people).
Whether you use them or not, intel agencies use their lack. This is the naïve "I have nothing to hide" dodge about privacy.
As I already said, if I was concerned about intel agencies capturing my messages I'd use proper OSS encryption via Signal, not Telegram.
There simply are situations where I do not care whether my messages are encrypted or not, in which case I use the app that works the best for me, which in this case is Telegram.
There simply are situations where I do not care whether my messages are encrypted or not, in which case I use the app that works the best for me, which in this case is Telegram.
Comparing the criteria of cars and messaging apps is futile.
I am certain that this was a metaphor, not an actual comparison.
Also an excellent bot platform.
Telegram is more than the security features.
So then why didn't you break the crypto yet? There was a $300,000 bounty to break it.[1]
This whole, "don't roll your own encryption" argument is getting really old. Everything was new at one point.
[1] https://telegram.org/blog/cryptocontest
This whole, "don't roll your own encryption" argument is getting really old. Everything was new at one point.
[1] https://telegram.org/blog/cryptocontest
They had their chance to win my confidence. When Telegram was released, many people said "this looks weird in so many ways. You should really dump that and rewrite it to rely on well-understood primitives" to which the telegram devs answered rather mockingly and started a bullshit crypto contest.
6 months later, a russian guy showed that the server could MITM every newly started or renegotiated secret chat.
Sure, they manned up to their promises and gave him something like $80k, but it is a rather telling story about how good they are at crypto.
Their crypto today? Yup, still weird.
6 months later, a russian guy showed that the server could MITM every newly started or renegotiated secret chat.
Sure, they manned up to their promises and gave him something like $80k, but it is a rather telling story about how good they are at crypto.
Their crypto today? Yup, still weird.
[deleted]
How many times has this headline been changed? I've seen 3 different ones.
No app wil ever accomplish consistent good voice quality over the internet. Ever. For that it's too much of an unreliable network. You may try some calls over Signal, think Hey! This works well! until you hit a moment where the route between endpoints is flaky, attribute it to Signal while using another app for that same call at that particular point in time would have given the same result.
Only when QoS will be honored by all internet routers will we reach something that is consistently reliable.
Only when QoS will be honored by all internet routers will we reach something that is consistently reliable.
You are dumb if you really believe this. Technology always proves people wrong. Just wait for it.
Some artist had fun with this: we have a woman talking on her cell phone while driving and a fully clothed man in a bathtub, with a monocle.
The NN approach sounds interesting, but there are no technical details and it might be hype-based marketing.
Is anyone familiar with solid published work on applying ML/AI to optimize network control (or, as done here, optimize application parameters depending on network conditions).
Is anyone familiar with solid published work on applying ML/AI to optimize network control (or, as done here, optimize application parameters depending on network conditions).
Funnily enough, 10 years ago as a required entry step before being able to do a thesis I scribbled something[0] about distributed components with probes (some automatic, some with user feedback exactly as suggested here) and knobs driven by some fuzzy logic feedback loop, to be e.g applied to codecs and buffer size in an A/V streaming scenario† (possibly bidirectional). Concluded by saying you could get better, self-improving results by using genetic algorithms and/or AI such as NN. Was basically laughed at during defense and dismissed as being way too sci-fi. Got sick of such constant condescending attitudes and dumped research, pursuing my career as a software engineer. Had I pursued I could have been the author on such a paper you're looking for! Pretty sure I could have patented the shit out of this anyway but that's not how I roll regarding software patents. Now I lost the LaTeX source and Java code as well as the resulting PDF, and can't even download the thing as a memento since it's behind some stupid paywall.
† turned out MS launched instant play adaptative 1080p streaming some years later on Xbox 360, which was exactly that.
[0] Supervision d'une Application à Base de Composants afin de Respecter des Contraintes Temporelles - https://hal.inria.fr/inria-00000787
† turned out MS launched instant play adaptative 1080p streaming some years later on Xbox 360, which was exactly that.
[0] Supervision d'une Application à Base de Composants afin de Respecter des Contraintes Temporelles - https://hal.inria.fr/inria-00000787
I still vote Wire. It used to be buggy, but much better now, plus completely Open Source (Telegram is not).
I just placed my first Wire audio call from my phone a few minutes ago: great quality (better than my actual phone service), no noticeable lag.
I just placed my first Wire audio call from my phone a few minutes ago: great quality (better than my actual phone service), no noticeable lag.
> It used to be buggy
How long ago are you referring to?
I tried to use it around the end of 2016 to chat with friends and it was nearly impossible to use. We would try to add a contact but the other person would not appear online, despite having the app open in front of us.
Messages would frequently not be delivered, or take exceedingly long times to be delivered (hours). Notifications of a new message were also quite hit and miss.
Overall I liked the functionality of Wire, but the reliability was terribad.
How long ago are you referring to?
I tried to use it around the end of 2016 to chat with friends and it was nearly impossible to use. We would try to add a contact but the other person would not appear online, despite having the app open in front of us.
Messages would frequently not be delivered, or take exceedingly long times to be delivered (hours). Notifications of a new message were also quite hit and miss.
Overall I liked the functionality of Wire, but the reliability was terribad.
Not sure, 6-9 months ago. Texting always worked for me, but audio & video were hit-&-miss.
Actually, thinking about it now, I haven't used video much lately, but audio has been much better the past 1-2 months.
Actually, thinking about it now, I haven't used video much lately, but audio has been much better the past 1-2 months.
Can anyone familiar with the matter say how secure is the 4-emoji verification code?
> Thanks to this modification, it becomes possible to prevent eavesdropping (MitM attacks on DH) with a probability of more than 0.9999999999 by using just over 33 bits of entropy in the visualization. These bits are presented to the users in the form of four emoticons. We have selected a pool of 333 emoji that all look quite different from one another and can be easily described in simple words in any language.
33 bits of entropy seems quite low to me.
https://core.telegram.org/techfaq#q-how-are-voice-calls-auth...
33 bits of entropy seems quite low to me.
https://core.telegram.org/techfaq#q-how-are-voice-calls-auth...
That would be low if we were considering a long-term key. It seems fine for a one-shot authentication token? Eve is going to have to MitM a lot of calls before she guesses this token correctly.
I wonder about the possibility to use "collisions" between similar-looking emojis in order to fake a match more easily.
I think a while ago someone on HN suggested emoji as a joke as a more information-dense and internationalized alternative to numeric or alphanumeric verification codes. I don't know about security, but if this uses all 1,088 emoji from Unicode 9.0, then four emoji have about 40 bits of information.
Emojis in this case are just sort of visual representation of the keys two users exchange before communication.
In theory this makes MitM attack impractical.
https://core.telegram.org/techfaq#q-how-are-voice-calls-auth...
https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
In theory this makes MitM attack impractical.
https://core.telegram.org/techfaq#q-how-are-voice-calls-auth...
https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
Based on their tech docs[1], it seems pretty good.
1: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
1: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
Is it fully controlled by FSB?
Brothers funded by loans from Swiss banks and citizens of a Commonwealth island. From the paranoid angle try s/FSB/GCHQ.
https://en.wikipedia.org/wiki/Pavel_Durov#Life_after_VK
https://en.wikipedia.org/wiki/Pavel_Durov#Life_after_VK
My problem with Telegram is I want to use it but they wont let me. I use a budget phone service (freedompop) which apparently is technically voip, but I did not know until I tried to register for Telegram with it. They refuse to send me text verification. Wont work with my google voice number either. WhatsApp does not have this problem. And what if I want to use Telegram on desktop only? Why do I need to verify a phone number?
I have the same problem with Project Fi. Every time I try to register they claim my number is a 'voip' number. Duh! Pretty much all numbers are 'voip' at this point.
It worked with my Google Voice number just now. Could they have changed the policy? I did sign up with my iPad (with cell service) first then iPhone, so it was probably more open to not using the device's phone number.
Hey! What do you know? I guess they added support after enough complaints. Now I'll give it a go.
The UI for trimming and setting the quality of sent videos is really neat. It's still annoyingly hard in 2017 to send videos from one mobile to another without needing to completely trash the quality via MMS or upload an often-gigantic file (captured in 1080p or higher) to an intermediary like YouTube or Facebook (and then wait for backend processing).
This is awesome.. I have been trying to video chat with somebody more overseas. Whatsapp video, facebook video, skype, seems like the only thing that works for us right now is Duo.
Bad thing: this tech is trapped in Telegram which is quite political of an app. I wish they'd break it out into something like duo.
Bad thing: this tech is trapped in Telegram which is quite political of an app. I wish they'd break it out into something like duo.
I wish they allow arbitrary user identifiers, which are not tied to mobile operators. Just for geeks.
Very welcome addition. Can anyone confirm if this feature will be available on the desktop app as well?
Very good. Great even.
But there is a problem. Whatsapp has already won the chat/calls app war. Watch it grow massivly in the next year, i promise.
Mostly due to incompetence of MS and Google.
To me Whatsapp is terrible. I can only use it on Mobile in any meaningful way, so it's actually worse than SMS for me. Eg, i get a better UX of seamless multi-device SMS via Hangouts, than i do with Whatsapp.
Frequently i get kicked off of Whatsapp because my phone has been idle for too long. Frequently my messages are out of order between the web client and the android client. Semi-frequently Whatsapp hangs when sending messages, sometimes dropping them (i assume due to my phone going idle).
I wouldn't recommend anyone to Whatsapp.. for UX, at least.
Frequently i get kicked off of Whatsapp because my phone has been idle for too long. Frequently my messages are out of order between the web client and the android client. Semi-frequently Whatsapp hangs when sending messages, sometimes dropping them (i assume due to my phone going idle).
I wouldn't recommend anyone to Whatsapp.. for UX, at least.
I agree it's largely due to MS and Google incompetence.
However, WhatsApp is already at 1bn users [0][1]. Expanding from that is going to be very hard.
0 - http://www.theverge.com/2016/2/1/10889534/whats-app-1-billio...
1 - https://en.wikipedia.org/wiki/List_of_virtual_communities_wi...
However, WhatsApp is already at 1bn users [0][1]. Expanding from that is going to be very hard.
0 - http://www.theverge.com/2016/2/1/10889534/whats-app-1-billio...
1 - https://en.wikipedia.org/wiki/List_of_virtual_communities_wi...
WhatsApp/Fbchat Or WeChat (they (Tennent) just bought 5% of Tesla)
Wait, I saw nobody mentioned this, but I feel this is very similar to Slack, group-chatting basically, isn't it?
I happened to be reading a comparison of Telegram and Whatsapp this morning [1]. I've never used Whatsapp, is it really this bad or is the reviewer clearly a massive Telegram fanboy/girl?
[1] https://info.seibert-media.net/display/Atlassian/Comparison+...
[1] https://info.seibert-media.net/display/Atlassian/Comparison+...
Telegram is superior to Whatsapp from every perspective except for its smaller user base.
However, how can you take as unbiased a comparison table that uses adjectives as "Incredibly fast loading times", "UNRIVALED", etc.?
However, how can you take as unbiased a comparison table that uses adjectives as "Incredibly fast loading times", "UNRIVALED", etc.?
> Telegram is superior to Whatsapp from every perspective except for its smaller user base.
I'd say, except for its security/encryption...
I'd say, except for its security/encryption...
The encryption they claim to use. Not saying they don't, just saying it's only "sort of" superior on encryption, given this caveat.
The same goes for Telegram. The android client hasn't seen any updates to it's github repo since sep 2016.
And, it is quite easy to verify that WhatsApp's encryption is doing what we think. A friend of mine managed to reverse engineer their protocol in 2012 in less than 24 hours, by himself. And there is quite a big chunk of the computer security market that would disagree with the claim that something has to be open source to be verifiably secure.
And, it is quite easy to verify that WhatsApp's encryption is doing what we think. A friend of mine managed to reverse engineer their protocol in 2012 in less than 24 hours, by himself. And there is quite a big chunk of the computer security market that would disagree with the claim that something has to be open source to be verifiably secure.
Couldn't WhatsApp faithfully implement the protocol, but also keylog and phone home occasionally? How would you know?
Sure, but then again so could Telegram. It's a rather fruitless discussion.
No it's not. The fruit is: use a sideloaded Signal which you built yourself if you really need to be secure. If you're not, Signal is still better than Telegram or Whatsapp.
Well, that I agree on, but that wasn't the discussion I was having :)
Well, there is some truth to it, but as a user of both I prefer whatsapp since:
1. most of the features that whatsapp lack are features I find annoying in Telegram.
2. Whatsapp is encrypted by default, which Telegram is not. I don't think I have ever used a secret chat, despite having oven 50 people with whom I regularly talk to over Telegram.
The client being open source is somewhat of a stretch. They have released many new versions, yet the github repo hasn't been updated in 7 months.
1. most of the features that whatsapp lack are features I find annoying in Telegram.
2. Whatsapp is encrypted by default, which Telegram is not. I don't think I have ever used a secret chat, despite having oven 50 people with whom I regularly talk to over Telegram.
The client being open source is somewhat of a stretch. They have released many new versions, yet the github repo hasn't been updated in 7 months.
I've read the list, and although I have faith in its veracity (except for the "value" column) and Telegram appears to have a bunch of extra features, I'm sticking with WhatsApp. They both have the features I need.
Note that they're both listed in the table as having "End-to-end encrypted chats" (value: "medium"?!)
Note that they're both listed in the table as having "End-to-end encrypted chats" (value: "medium"?!)
There are a few factual errors in the list: The Telegram clients seem to be open source, but the server is proprietary. WhatsApp does have a native client for a few platforms; nobody knows about it because everyone just uses WhatsApp Web. WhatsApp has animated GIFs.
For an independent and serious comparison check https://www.securemessagingapps.com that focuses mostly on the security/privacy aspects of various messengers.
With talk of neural interfaces and augmentation will we have apps in the future that support human to human encryption I wonder?
With things like BLADE this is not even a far future http://www.nature.com/nbt/journal/vaop/ncurrent/full/nbt.380...
I wonder if different languages evolved as a way to encrypt communication from other tribes. Too far fetched I admit.
a neural network learns from your and your -- typo
a neural network learns from your and your
Pied Piper, is that U ?
In a world full of bloated Electron HTML5 / JS "desktop apps", I'm very happy to see Telegram on Windows is a native app (Qt). It feels so incredibly responsive compared to everything else.
The funny thing is that Qt apps used to be derided for bloat (15MB of DLLs! 15MB!) but the rise of Electron has made Qt seem featherweight by comparison.
I've been involved in a project that went from standard Win32 controls to Qt, and while I was very much against Qt at the time (such bloat!), I can't deny how easy it has made cross platform UI work. With many apps being written in HTML/JS, a C++ Qt framework is still magnitudes faster than a JS interpreter.
I have zero experience with Qt but have heard that it has problems with High DPI presentations. Now It seems that they did something in that regard in Qt 5.6, but do you have anything to say or an idea about the maturity of it?
Qt classic (C++) apps run flawlessly on my 4K desktop (150% scale in Windows).
QML/QtQuick apps only support integer scaling for whatever ridiculous reason ("fuck your monitor we need to be pixel perfect" or whatever) so they're either tiny or huge.
QML/QtQuick apps only support integer scaling for whatever ridiculous reason ("fuck your monitor we need to be pixel perfect" or whatever) so they're either tiny or huge.
Yeah, I remember years ago when I was pondering writing a desktop app in Python and thinking "Python? It would be so bloated!", and nowadays nobody gives a shit about being able to load more than four programs at once.
>15MB of DLLs! 15MB!
Life's a little different now than in the old XP days. Disk space and ram aren't as limiting as before and the slow redraw times of qt and other cross-platform libraries have been taken care of by GPU hardware acceleration, faster ram, and faster CPUs.
These complaints were valid back then and our opinions didn't change because of things like Electron, as much as our hardware is so much more powerful. I remember dreading running Java desktop apps and now I can barely see the difference between them and native win32 apps. Heck, running an app on a virtualized OS on top of my native OS is often fairly performant nowadays.
Life's a little different now than in the old XP days. Disk space and ram aren't as limiting as before and the slow redraw times of qt and other cross-platform libraries have been taken care of by GPU hardware acceleration, faster ram, and faster CPUs.
These complaints were valid back then and our opinions didn't change because of things like Electron, as much as our hardware is so much more powerful. I remember dreading running Java desktop apps and now I can barely see the difference between them and native win32 apps. Heck, running an app on a virtualized OS on top of my native OS is often fairly performant nowadays.
They have a beautiful native macOS app as well. Also, excellent support for groups, including group URLs you can stick on a github page. Great program all around.
Not to mention GNU/Linux support. That's one of my main reasons for sticking around. Wire just can't compete, unfortunately.
I use the OSX app, too. But there was a downgrade going from the App Store version to the recent "Desktop Telegram" version.
The latter lost bindings like ctrl-a, ctrl-u.
If I could be bothered, I'd delete the "Desktop" release and go back to the App Store version.
The latter lost bindings like ctrl-a, ctrl-u.
If I could be bothered, I'd delete the "Desktop" release and go back to the App Store version.
When you say "desktop" version, do you mean the cross-platform one that offers downloads for Win/Mac/nix, or the specifically Mac version that has a whole lot less features (at this point) than the cross-platform version?
He means the former, which is called "Telegram Desktop".
The Mac-specific App Store version is a better app, but has been abandoned in favor of the (crappy) "Telegram Desktop."
The Mac-specific App Store version is a better app, but has been abandoned in favor of the (crappy) "Telegram Desktop."
Judging from recent updates it's still alive. The version in AppStore might be stale (not sure) but if you install the version from site (https://macos.telegram.org) you'll get frequent update.e
But I must admit that amount of clients is confusing.
But I must admit that amount of clients is confusing.
[deleted]
> Telegram on Windows is a native app (Qt)
I thought Qt still bypassed the native user interface and drew all their own controls?
I thought Qt still bypassed the native user interface and drew all their own controls?
That doesn't make it a non-native app. They're still just leveraging direct platform APIs under the hood.
Native these days seems to mean "without a web browser under the hood".
Native these days seems to mean "without a web browser under the hood".
Not even that. I've seen plenty Electron and Cordova apps billed as "native".
The word has lost meaning as to nontechnical users, it's mostly about "can i install it directly on my device". We need better terms.
The word has lost meaning as to nontechnical users, it's mostly about "can i install it directly on my device". We need better terms.
Indeed. Wrapping a browser control is not "native".
Native means "It doesn't run inside my web browser".
But it being a window that runs a second web browser, that is OK.
But it being a window that runs a second web browser, that is OK.
And Qt is what?
A very well-known cross-platform GUI library. If you google qt, the top hits are the official website and Wikipedia. Without clicking any link, the descriptions would have given you an answer.
I know what it is, it's just not lightweight.
Ah, sorry I misunderstood you.
A UI toolkit
tfatcek(1)
But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
There are so many more sources of latency on every layer on the modern internet and it's a damn shame. I remember when interleaving got enabled on my ADSL and latency to everything doubled overnight. Then there are NATs, and all kinds of filtering shit that ISPs insist on. Sigh...