Introducing Telegram Passport
telegram.org
telegram.org
It's a tractable problem.
(NB: Not necessarily keybase, but they do have a technical solution to the problem in place already.)
I'm guessing you meant non-decentralized?
Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.
About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Gosh, not really. They completely control who can use the service, and any information they 'require' to register for the service.
> since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
I'd like to point out that walled gardens will still openly invite folks to join, and give them tools that they could reproduce, but give them no way to experience the garden outside the walls.. including the tools previously given that are also useless outside the walls. That's exactly the case with keybase.
> About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Huh. I'm interested in hearing how having source code makes autiting more difficult, since that has not been my experience.
It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:
- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)
- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example
- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)
- the tools for analyzing binaries are often more advanced than code tools
It's two passwords, both are something you have to know, there's nothing you need to have or be (sms and biometrics respectively)
But if you can access the phone content remotely behind a password, then it stops being 2FA.
Many people don't realise that they don't own their phone number! It is possible to own a phone number but it is not widely available just like domains are. Hence it is a stupid idea to use it as an identity.
No one else would give you social graph that easily.
It could be worse, an app could say "You must sign up with Facebook"
things businesses assume about people: 1: they have a phone number. 2: they have an address. 3: the country they are in at the moment is the country they live in
They've also expanded it to support more phones recently. I think having a Fi phone, even if it's not your primary device, makes a lot of sense for nomads.
WhatsApp lets you set a pin number to prevent this. Can't remember if Signal does similar..?
But I’m always amazed at the pace at which Telegram keeps improving its feature set and UX. I haven’t experienced a messaging platform that’s anywhere close to it on these aspects. And for these reasons alone, it still remains my primary messaging application (while I keep checking the competition to see where they are).
Additionally their first encryption protocol was extremely wonky and most people I know would correctly call it unsafe for use in a chat messenger.
Their second version is a tiny bit better but neither has been verified by any proper cryptographer I know.
Additionally Telegram as an App seems more like a Toy rather than a proper chat app, the stickers are big and completely destroy the flow of a conversation last I checked it. Other features are like this too.
Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
You could say the same for Signal (before Signal Foundation was created this year) or Wire (created by the people who created Skype) too.
> Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
The “secret chats” are always end-to-end encrypted. The normal chats are encrypted only in transit and not end-to-end. But secret chats are also tied to a single device (currently only phones), unlike Wire, which offers end-to-end encryption and synchronized conversations across devices.
Wire is also Open Source.
>The “secret chats” are always end-to-end encrypted.
Secret Chats come with too many drawbacks and other message applications seem to do perfectly fine. As you mention, only one device.
>The normal chats are encrypted only in transit and not end-to-end
That is TLS and not E2E encryption which is also a total no-go for me.
But telegrams apps and Bots are growing exponentially and the developers unnecessarily keeping a basic work flow outside telegram, which is painful.
But telegram never advertised anonymity as a takeaway.
This implements the dream of authoritarian governments that internet access should never be anonymous. Russian government officials have long wanted to establish a similar authentication system.
Is Pavel with us or against us?
Why should anyone trust them for identification or for storing sensitive documents?
(And no, that DH behavior cannot be explained away as a simple mistake)
> UPD: The story ended well. Vulnerability is corrected, documentation and applications are updated, treasure hunters of bugs are motivated, which has already yielded results (1, 2). It is necessary to pay tribute to the developers of Telegram, who immediately reacted to the article.
It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
Durov and Telegram have more or less shown their mettle; there was no money or profit in standing up to Russia, but they went ahead and did it anyways when it would have been easier to buckle. Yes, it has flaws in its implementation, but so far they've proven that when push comes to shove, they're willing to fight for their politics and to keep on fighting against such regimes. Once this changes, sure, it's fine to lay into them, but right now it really looks like they're true to their word.
It is an obvious backdoor.
They justified XORing in arbitrarily string into the key you have established with DH with the fact that your phone may have bad random number generator. But it obviously gains you nothing. If the server is honest, then it does not read your secret chat anyway. And if the server is malicious or compromised, it knows the string.
So even if it is possible to overlook the possibility of XORing in the difference of keys and evading MITM detection, it is very unlikely that no developer (for example, someone who coded it into the server or one of the clients) have seen that it gains you nothing in any scenario you can think about.
When users started to asking developers for the explanation in the comments, W_K (main developer of the protocol, brother of Pavel Durov) stated that they "don't know" who added this feature in its current form. Shortly after, he stopped using his account or answering any questions at all: https://habr.com/users/W_K/
Upd: regarding the remark in the end of the https://habr.com/post/206900/ that "the story ended well", Telegram team is responsive etc.
Keep in mind that they paid this guy. Adding such updates to articles and publicly confirming that the bug was fixed is almost surely a part of the bug bounty agreement.
I’d like to know of a vaguely plausible thought process that would result in this implementation.
I wish they'd spend more time figuring out how to get around the domain fronting problem.
Then again I'm rambling.
As for this Passport - I'm not interested in this feature and I can't see where it would be useful for me. Not mention the security with just their assurances that nobody would have an access to my personal info - it's ridiculous to say least.
If, however, this is targeted at the providers who are actually collecting IDs as part of their AML compliance strategy, then there’s a much simpler solution here: just become the ID equivalent of a Certificate Authority. Dedup Telegram accounts by using a unique constraint on accounts’ validated ID documents’ extracted creds; and then allow sites to use Telegram for Single Sign-On. Boom—instant surety that each of your users is a real person, and not fifty bots laundering one person’s money; and no need for anyone besides Telegram to actually see your ID (i.e. a much lower chance of identity theft.)
Plus, if enough sites require SSO through an ID-document verifying identity provider, then even sites that ha d no legal reason to require it can free-ride off the benefit in user-deduplication it provides. Imagine, for example, a Reddit or a 4chan where users are still pseudonymous or anonymous, but where banning a user truly works, permanently, with no routing around it (unless you have the criminal connections required to buy yourself a new real-world identity.)
Given that Telegram is already a payment processor (i.e. something people trust with their money), it could serve a similar role, no?
While every third party is doing these things everyday, Telegram is under the risk of getting targeted.
Wonder how the price of CVC is impacted today...