Nowadays all of the messaging pipeline on my phone is closed source and proprietary, and thus unverifiable at all.
The iPhone operating system is closed, the runtime is closed, the whatsapp client is closed, the protocol is closed… hard to believe any claim.
And i know that somebody’s gonna bring up the alleged e2e encryption… a client in control of somebody else might just leak the encryption keys from one end of the chat.
Closed systems that do not support third party clients that connect through open protocols should ALWAYS be assumed to be insecure.
>Closed systems that do not support third party clients that connect through open protocols should ALWAYS be assumed to be insecure.
So you're posting this from an open core CPU running on an open FPGA that you fabricated yourself, right? Or is this just a game of one-upmanship where people come with increasingly high standards for what counts as "secure" to signal how devoted to security they are?
it doesn't need to be open source for us to know what it's doing. its properties are well understood by the security community because it's been RE'd.
> a client in control of somebody else might just leak the encryption keys from one end of the chat.
has nothing to do with closed/open source. preventing this requires remote attestation. i don't know of any messaging app out there that really does this, closed or open source.
also, ironically remote attestation is the antithesis of open source.
Amazed this is being discussed! I’ve only consumed hacker news via rss for maybe 15 years and I guess I didn’t know there was another way to read it at this point :)
Many RSS aggregators automatically convert Youtube links to RSS. You can also do it manually: https://chuck.is/yt-rss/
I have removed Youtube apps from all mobile devices and only watch the creators whose content I'm interested in through RSS, without notifications and distractions. It's a much more pleasant experience, definitely recommend.
You can actually just paste the link to a youtube channel in your RSS reader and it should work. At least for me it works with NetNewsWire. For example, you should be able to copy and paste this directly into your RSS reader: https://www.youtube.com/@freecodecamp
> Neurophos, an AI chip started based in Austin, Texas and backed by Bill Gates’ Gates Frontier Fund, says that it has developed an optical processing unit (OPU)
I wonder if this might be the end of the silicon valley (in California) and the beginning of the photonic valley (in Texas).
I think the implication is that you should own multiple client devices capable of SSHing into things, each with their own SSH keypair; and every SSH host you interact with should have multiple of your devices’ keypairs registered to it.
Tuna-Fish said that instead of backing up the keys from your devices, you should create a specific backup key that is only ever used in case you lose access to all your devices.
This is indeed best practice because it allows you to alert based on key: if you receive a login on a machine with your backup key, but you haven't lost your devices, then you know your backup was compromised. If you take backups of your regular key then it would be much more difficult to notice a problem.
My point was that one of the devices would be your (cold) backup — you'd e.g. get an (ideally passphrase-protectable) smart-card; read off its pubkey; register that pubkey with all your remote systems/services; and then put the smart-card itself into a fire safe / safe-deposit box at a bank / leave it in trust with your lawyer / etc.
Note that you would never need to go get the smart-card just to perform incremental registration between it and a new remote host/service. You just need its pubkey, which can live in your password manager or wherever.
And yet, if your house burns down, you can go get that smart-card, and use it to get back into all your services.
And yet also, unlike a backup of another of your keys, if you find out that someone broke into your house and stole your safe, or robbed your bank, etc, then you can separately revoke the access of the pubkey associated with the smart-card, without affecting / requiring the rolling of the keys associated with your other devices. (And the ideal additional layer of passphrase protection for the card, gives you a time window to realize your card has been taken, and perform this revocation step, before the card can be cracked and used.)
Indeed, as the sibling comment mentions, this is vaguely similar to a (symmetrically passphrase-encrypted) backup of a unique extra KPI keypair onto a USB stick or somesuch.
The major difference, though, is that because a backup of a key is truly "just data", an attacker can copy off the encrypted file (or image the raw bytes of the encrypted USB disk), and then spawn 10000 compute instances to attempt to crack that encrypted file / disk image.
Whereas, even when in possession of the smart-card, the attacker can't make 10000 copies of the data held in the smart-card. All they can do is attack the single smart-card they have — where doing so may in turn cause the smart-card to delete said data, or to apply exponential-backoff to failed attempts to activate/use the key material. The workflow becomes less like traditional password cracking, and more like interrogating a human (who has been explicitly trained in Resistance-to-Interrogation techniques.)
To me that just sounds like creating obstacles for myself to get access to my system when I desperately need to. I keep a backup of my work pc keys on Google Drive and I have zero anxiety about that.
Actually, you shouldn’t. You probably use an easy-to-remember password on SSH keys since you have to type them often, but that also means you’re storing one of your (let’s face it, the primary) password you have in a single file, readable to every executable your run under your account. And that means you’re one exfil away from not only getting your SSH keys compromised, but also allowing an attacker to run an offline decryption attack with unlimited attempts. This invariably leads to your main password getting compromised.
Instead, set up SSH certificates, MFA, Yubikey, or TPM/Enclave storage for your private keys.
> but also allowing an attacker to run an offline decryption attack with unlimited attempts. This invariably leads to your main password getting compromised.
Do the OpenSSH authors not know about PKBDF2 or similar?
How does PBKDF2 prevent an offline decryption attack with unlimited attempts?
All it does is slow down the attempts, but for the average person's easy-to-remember password, it's probably increasing the effort from milliseconds to a few days.
Nowadays all of the messaging pipeline on my phone is closed source and proprietary, and thus unverifiable at all.
The iPhone operating system is closed, the runtime is closed, the whatsapp client is closed, the protocol is closed… hard to believe any claim.
And i know that somebody’s gonna bring up the alleged e2e encryption… a client in control of somebody else might just leak the encryption keys from one end of the chat.
Closed systems that do not support third party clients that connect through open protocols should ALWAYS be assumed to be insecure.
reply