> It does if you consider that everyone can act as a relay.
Let's think this through. Imagine civil war breaks out in Australia, and communications infrastructure is destroyed or shut off. I'm in Sydney and want to transmit a message to a friend in Perth.
How exactly is "everyone acts as a relay" going to work? In particular, how is it going to scale when everyone in the country is trying to do the same things?
> This is also how apple airtags can be find anywhere there's an iphone users nearby.
This is incorrect. Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think. Those nearby Internet-connected devices send the airtag's location to a server.
Nothing about this would work without the Internet.
Yeah, I think current tech assumes a server relay. However imo, and if I were to imagine a solution, in this case I think a message would need a ttl, say 24 hours. In a local mesh/hive everyone would store a copy of the undelivered messages. When people move between hives they would sync these undelivered messages where ttl didn't expire. With perhaps a storage limit of say 1k undelivered messages. Undelivered means a destination user that didn't show in a hive. Wdyt?
> With perhaps a storage limit of say 1k undelivered messages.
If you want this to scale you'd need a scheme to deal with limited cache per device. Something like having each device assign a random priority to each message it has in transit. That way everyone culls a different set when things fill up.
> would need a ttl, say 24 hours
Probably better off scaling priority by age. That way you deliver if at all possible, until it eventually falls out of cache. Some people will be able to dedicate much more storage than others.
I do think this approach would be fairly tractable within "hives" where most of the members have few-hop connections to all of the others, most of the time. The trouble is that there would be so many unpredictable cases:
- Regular travelers between cities (e.g. flight attendants) might be the only reliable links between those hives. Travel patterns change, war breaks out, etc and the hive suddenly splits into two (or more).
- A lot of people probably move around too much, and too unpredictable, to participate in a hive that's stable on scales necessary to maintain a TTL of <24h and a reasonable amount of cache for storing others’ undelivered messages.
Maybe I'm being too pessimistic here… I do think it'd be fascinating and instructive to try to build and use a hive/mesh messaging system like this at scale.
Basically, if you visit the Galapagos and you're so inclined… you leave a letter for someone else, and you sift through the letters that have been left there, and try to find one or two that you could conceivably hand-deliver when you return home.
The latency is 100~1000x longer than "normal" snail mail. This is basically with one "hive" constructed around tourists and researchers in an unusual location. But it basically works.
> Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think
Yes, exactly (BLE, UWB, NFC).
First, Airtags only have a coin-cell battery. It is not remotely viable for them to be doing any sort of serious "communicating" because the battery would die in seconds.
Second, making the Airtag effectively a dumb device means you gain the various security and privacy benefits, and means everything needed to make the magic happen can be transmitted in a single BLE/UWB/NFC packet (bringing us back to the battery life aspect already mentioned).
> I haven't studied the protocol but that seems like it has some...obvious routing issues.
Yes indeed. I don't understand how the peer-to-peer relaying can possibly scale without some directed routing algorithm.
If my phone running Briar is literally handing off every as-yet-undelivered message to every other phone running Briar, we're going to pretty quickly become overwhelmed.
Ironically everything works fine if I VPN in from home, or from a phone hotspot. But in office connected directly to the network, no dice. We just switched back to 5 days in office after trialing 2 days WFH the last couple months, so that's actually where it matters most.
Hierarchy can do that too, once you allow a single file to exist in multiple hierarchies at once. Think of database, we have a single table, yet we have a lot of different indexes to search on.
We could do the same, either with symlinks or hardlinks
Yet there be clickbait headlines. Novels are written for people to imagine the scenes described by the author, requiring your own 'filling in' to be immersed in the story.
They added this recently, because lots of people complained to Google that they lose their tokens; Authy and others started to gain traction because they did synchronization. Google was pretty much forced.
I know, 2FA loses the entire point when it's synchronized. But, well. People lose their stuff all the time!
I've had customers tell me that they cannot use email verification to meet a 2FA compliance requirement because it's not a second factor, but somehow SMS is. I always push back with "why not just good old TOTP" and the answer is that it's too easy for a customer to lose because it is only on their device. Like yeah... that's what makes it a real second factor.
It’s possible to synchronise secrets without sharing them with a third party: just encrypt them locally, transmit to third party, download to other device, decrypt.
This could be made easy for users by having each device share a public key with the third party (Google, in this case), then the authenticator app on one device could encrypt secrets for the other devices.
This would be vulnerable to Google lying about what a device’s public key is, of course, but enduring malice is less likely (and potentially more detectable) than one-time misbehaviour.
> It’s possible to synchronise secrets without sharing them with a third party
Sadly the problem Google is actually trying to solve is providing security for the dumbest people you've ever met. Dumbasses are entitled to security too!
I'm talking people who've lost access to their e-mail, and their phone number, and their 2FA all at once. Then they've also forgotten their password.
No password manager, no backup phone, no yubikeys, no printed codes, no recovery contacts, nothing.
The active ingredient in 2FA as practically implemented for nearly everyone has never been the 2. It's mostly just not letting humans choose their entire password.
For "something you have" to be true to its purpose it has to be something that has one and only one copy - so either only you have it, or you don't, but nothing in between. The second you have "cloud backup", or activate an additional device, or "transfer to a new device" then you turn the attack into "phishing with extra steps".
You can support transferring to a new device without increasing the phishing risk, the transferral just needs to be done via a physical cable rather than via the cloud.
I'll grant you that it's a better option but by no means good if you want to stand on the 2FA hill and put security first (only?). That "just" does a lot of heavy lifting.
The only time I'd consider transferring a secret like this is secure is within an HSM cluster. But these are exceptionally hardened devices, operating in very secure environments, managed by professionals.
Your TOTP seed on the other hand is stored on any of the thousands of types of phones, most of which can be (and are) outdated and about as secure as a sieve. These devices also have no standard protocol to transfer. Allowing the extraction via cable is still allowing the extraction, the cable "helps" with the transfer. Once you have the option to extract, as I said, you add some extra steps to an attack. Many if not most attacks would maybe be thwarted but a motivated attacker (and a potential payoff in the millions is a hell of a motivator) will find ways to exfiltrate the copy of the keys from the device even without a cable.
This is plain security vs. convenience. The backup to cloud exists because people lose/destroy the phones and with that their access to everything. The contactless transfer exists because there's no interoperability between phones, they used different connectors, etc. No access to the phone is a more pressing risk than phishing for most people, hence the convenience over security.
I think this is also the main drawback of physical U2F/FIDO2/Webauthn tokens: security-wise they are by far the best 2FA option out there, but in practice it quickly becomes quite awkward to use because it assumes you only own a single token which you permanently carry around.
Sure, when I make a new account I can easily enroll the token hanging on my keychain, but what about the backup token lying in my safe? Why can't I easily enroll that one as well? It's inconvenient enough that I don't think I could really recommend it to the average user...
I don't quite get this "I need to add every possible authenticator I have at account creation or I'm not doing it" kind of mentality I see a lot.
When I make an account, if I have at least two authenticators around me, I'll set up the hardware authenticators or make sure it's got a decent recovery set up. As time goes on I'll add the rest of them when it's convenient. If I don't have at least two at account creation or I don't trust their recovery workflow, I guess I'll just wait to add them. No big deal.
If I'm out and I make an account with $service but I only have my phone, I'll probably wait to add any authenticators. When I'm with my keys, I'll add my phone and my keyring authenticator to it. When I sit down at my desktop sometime in the next few days and I use $service I'll add my desktop and the token in my desk drawer to it. Next time I sit down with my laptop and use $service, I'll add that device too. Now I've got a ton of hardware authenticators to the account in question.
It's not like I want to make an account to $service, gotta run home and have all my devices around so I can set this up only this one time!
>When I make an account, if I have at least two authenticators around me
If you do, you're in a tiny minority of users. Well, even if you have one you're in a tiny minority, but having two laying around is extremely unusual.
Only because I bothered to buy a few. If they're making a new account they're probably on a device which can be an authenticator, i.e. a passkey. Is it rare for people to be far away from their keyring where they potentially have a car key and a house key and what not?
Do most people with hardware authenticators not also have laptops, desktops, or phones? They just have an authenticator, no other computers?
This person I replied to already has two hardware tokens. They probably also have a phone that can be used with passkeys, they probably also have a laptop which can be used with passkeys, they might also have a tablet or desktop which can be used with passkeys. That person probably has 3-6 authenticators, and is probably with two of them often if they carry keys regularly.
I don't understand the existence of an HSM cluster. I thought HSM was meant to be a very "chain-of-custody" object, enabling scenarios like: cryptographically guarantee one can only publish firmware updates via the company processes.
The HSM is more generic than that - a Hardware Security Module. It's just a hardware (usually, software... Hardware security modules exist...) device that securely stores your secret cryptographic material, like certificate private keys. The devices are exceptionally hardened both physically and the running software. In theory any attempts to attack them (physically open, or even turn them upside down to investigate them, or leave them unpowered for longer than some hours, attempt too many wrong passwords, etc.) results in the permanent deletion of all the cryptographic material inside. These can be server sized, or pocket sized, the concept is the same.
Their point is to ensure the private keys cannot be extracted, not even by the owner. So when you need to sign that firmware update, or log into a system, or decrypt something, you don't use a certificate (private key) file lying around that someone can just copy, you have the HSM safely handling that for you without the key ever leaving the HSM.
You can already guess the point of a cluster now. With only one HSM there's a real risk that a maintenance activity, malfunction, accident, or malicious act will lead to temporary unavailability or permanently losing all the keys. So you have many more HSMs duplicating the functionality and keys. So by design there must be a way to extract a copy and sync it to the other HSMs in the cluster. But again, these are exceptionally hardened HW and SW so this in incomparably more secure than any other transfer mechanism you'd run into day to day.
Ah, got it. So in the event someone managed to get access, they are limited to signing things in that moment on that infrastructure. I can see how that would reduce the blast radius of a hack.
Even so, if you have a copy even for a fraction of a second then you can have two copies, or skip the deletion, or keep the temporary copy that was used during the transfer. Even the transfer process could fail and leave a temporary file behind with your secrets.
I quite like Apple’s Advanced Data Protection, I set it up with two physical yubikeys recently.
To login to iCloud/Apple on a new device that’s not part of your trusted devices, you must use the hardware token.
Honestly I'd like to have my mind copied, but may only be 'simulated' once the current me is dead. From my perspective I'll be dead and there's no changing that, but from the clone's perspective, life just goes on.
I think you should think less like Java/C# and more like database.
If you have a Comment object that has parent object, you need to store the parent as a 'reference', because you can't put the entire parent.
So I'll probably use Box here to refer to the parent
reply