> The cloud and E2EE encryption of Telegram have already been audited by independent researchers.
Yes, and they all agree it's crap. Just look at this thread https://news.ycombinator.com/item?id=6915741 (Feel free to ignore Moxie, but listen to tptacek). In addition, it doesn't even matter since (a) it's not turned on by default and (b) it can't be turned on for group chats.
That said, I agree that Durov probably is not closely collaborating with the Russian state.
E2E is not available on all platforms, is hidden in obscure menus and the whole UI discourages users from using it. Telegram is a data-harvesting social goolag-oriented network after all. :-/
The greatest feature that telegram offers is cloud sync. Everybody knows the limitations E2EE comes with. There's no way you could have thousands of members in a group on Signal.
Along with that, the ability to manage device sessions and to login on multiple devices with full chat sync is extremely unique to Telegram.
You're asking them to ditch that in favor of inferior UX, which they simply cannot do at this point.
But I do hear the valid complaints. I do believe they should improve MTProto 2.0 to work on multiple devices and in groups. Their implementation is fine for 1-1 chats but having something better than that is always welcome.
If I earn $1000$/m, and I save $100/m - in a year, I'll maybe have $1200 saved up.
10% is so little for most you might as well spend it.
Personal rant:
I've been saving up 20-50% of my salary for the last 5 years for a downpayment, and then in the past year 18% inflation hit, interest rate doubled, food price inflation is in top 10 worst in Europe, property prices in increased by 50% in 4 years. My savings obviously cannot keep up with the economy.
I'm glad I wasn't too stringy and spent some money to complete all necessary dental work in the past couple of years (dental is never covered by the insurance here), now I wouldn't be able to afford it.
Oh, and there's also a war in my home country and my family lost almost all of their income (thank god they aren't displaced (yet)), now I'm awaiting a decision from my company whether I get the boot or not. Fun times.
I wish I invested in mental health and therapy too, I would still end up broke as I am now but at least I'd have some resilience.
They shouldn't be using PBKDF2 for new installations at all. It's been nearly a decade since the Password Hashing Competition, and you should just use the memory-hard Argon2.
Also, W3C should finally get it into the WebCrypto API, but it seems like whoever is responsible for it just let's that API rot. There are fast wasm implementations, though.
Memory-hard is not a panacea. I think the point, which is pretty well made by the blog post I linked to, is that the security of the vault is extremely sensitive to the passphrase anyways. Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort, not to mention yes, lacking Webcrypto support is a significant performance problem (WASM Argon2 implementations are at least multiple times slower than native IIRC.)
> Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort
The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, and you'll have to add a clause to the code either way. On the flipside, the memory-hardness allows you to increase the cost for the attacker a lot more than for the user.
> WASM Argon2 implementations are at least multiple times slower than native IIRC
I haven't looked this up, but my suspicion is that it's still better than a WebCrypto PBKDF2 configuration taking the same time for the user, measured in Wh for the attacker.
Just to be clear, the cost of changing the iterations is almost zero. Bitwarden already supports variable PBKDF2 rounds on all platforms, as well as changing the number of rounds. I'm sorry, but the cost of deploying Argon2 in production to a lot of platforms across a lot of devices is non-trivial by comparison. If you have enough different combinations of devices and environments deploying an if statement can become a challenge. In this case, it's especially a problem considering the lack of Webcrypto support.
By all means, use Argon2 in new code, or any other more modern KDF. But PBKDF2 isn't broken, and replacing it warrants actually doing the ground work to see if it makes sense: is it fast enough on most devices? is the security improvement meaningful enough? etc.
The truth is, 1password has the right idea here with their Master Key system. Even very unwieldy long passwords are pretty low entropy compared to a proper cryptographic key, and KDFs cannot significantly improve this situation. If you want to do more than re-inforce the speed bump, you're going to need to work outside the password. It has a usability trade-off of course, so maybe it's good that not everyone does it that way.
Does Argon2 have support for the various platforms that Bitwarden (or other platforms) need? You need support for browser (javascript most likely), iOS, Mac, Windows, and Android at minimum.
On top of that, are the implementations all equal or is one behind in terms of speed or support? You have to have everything else fall to the lowest common denominator. My guess is that that will be browser based implementations.
This is why so many password managers continue to use PBKDF2, because it has widespread support, particularly in browsers. Until Argon2 (or others) have support that matches it, many products won't use it because it brings with it all sorts of issues.
Argon2 is pretty memory hungry. Recommended defaults go up to the gigabyte range. That means that you have to be careful that you don't create a situation where the user originally encrypts their passwords on a device with lots of memory but then tries to decrypt their passwords on a system with not as much memory as was used for Argon2. Then the Argon2 implementation blows up with an out of memory error and the user has effectively lost access to their passwords.
Cache hardness might be more appropriate for situations where multiple devices are involved. Then the user just has to wait for a while if things go bad...
No they wouldn't. Smoking gives a little protection against infection, but once you have it it's likely much worse. Vaccines give you a little protection against infection and also reduce the probability of severe courses of illness.
I couldn't find any marketing material pointing out the switches on the originals, so I assumed this was a change for the Chromebooks. But you're right, I managed to find an image of a Framework laptop where the switches are visible.
The e2e encryption protocol is the definition of "let someone who has just learned about Diffie-Hellman roll their one crypto". It's called MTProto, and version 2 mostly updates padding and uses SHA256 instead of SHA1. Yes, SHA1 was deprecated before Telegram even existed. No, version 2 is not better.
Cryptographers praise Signal because the protocol makes sense and because it's not run by someone as data-hungry as Meta or Alphabet (though I think it's hosted on AWS).
Threema is a good alternative if you want username/password, but has less users (probably since it's a paid app) and less neat security properties (not even forward secrecy).
I agree Signal is not perfect and has never played the Open Source game very well (even under Moxie reports from the community were largely ignored) and the MobileCoin move is weird. I also have not followed the direction the project has taken since Moxie left. However, the _entire_ code is open source (which iirc is not the case with Telegram) and the protocol makes sense (and has been extensively studied), and there is a lot of eyes on the development. I remember code changes that suggested a pivot to not using phone numbers as identifiers (i.e. maybe requiring them for registration but not showing it to everyone you talk to).
I wonder whether MLS will go anywhere and actual projects will adopt it. Last time I checked it did require consensus on message ordering, which seems to make it less well-suited for non-centralized protocols like Matrix, but we'll see.
https://news.ycombinator.com/item?id=36770883