That is what I was thinking, too, but rather than the keyfile being an actual file, it is, instead, on the USB-C HW token. So, to decrypt your KeePassXC db, you'd need the physical token to do the decryption, and ask it to be, effectively, an HSM.
I... Am not sure how I feel about it. On tech merits, this absolutely makes sense - the tech is slinging private keys around, and their secure storage is a hard problem.
On the practical merits - maybe? Token-backed decryption of the password manager's database seems like a devent solution? But does this happen? Is there a password manager which uses the public key derived from FIDO2 token's on-chip private key to decrypt the database?
On-token storage is limited (though 100 passkeys on a YK 5 Nano is fairly generous) - but what if we just used the YK as the "Private key is here and ONLY here" setup?
I kinda like the OFFOAD+ design - it promises to show me to where I am authenticating. With origin binding should be a nobrainer, but still, it
speaks to me.
Not quite filesystem navigation, but SGI IRIX's Performance CoPilot software had an IrixGL (OpenGL's precursor) UI for monitoring things like memory state, CPU/storage loads, etc.
The PCP is absolutely nowhere _near_ the graphical wizardry of the state of this app, and the overlay of executing code atop a given directory structure is quite beautiful (practicality be damned), but I can see the inspiration.
I do wonder if, on a modern Linux system with SELinix, this model (code accessing a directory) is actually closer to viable? SELinux's contexts/labels for subjects overlaying with the same for objects can, I imagine, be visualized. The normal access patterns would be way too overwhelming, I think - but exceptions/policy violations? :ponder:
SGI's HW also had ccNUMA (cache-coherent Non-Uniform Memory Access), which, given the latencies possible in systems _physically_ spanning entire rooms, was quite a feat.
The IRIX OS even had functionality to migrate kobs and theor working memory closer to each other to lower the latency of access.
We see echoes of this when companies like high-frequency traders pay attention to motherboard layouts and co-locate and pin the PTS (proprietary trading systems) processes to specific cores based on which DIMMs are on which side of the memory controller.
```you should know the Uvalde school shooter was a minor but he managed to buy the guns legally from a gun shop on credit!```
That does not appear to be true. The investagiom reporting shows that the shooter bought the guns after he turned 18 - the legal age to purchase them (long guns, aka rifles - different from pistols) in the state of Texas.
Buying things on credit seems like a reasonable way to do business in general - are you suggesting that all deadly weapons should be sold for cash to increase the difficulty of legally acquiring them and so lowering the frequency of mass shootings?
```… the pipe was so fast, you could only pcap if you had a SCSI hard drive!```
This is why NSA asked for (and got from SGI) a guranteed rate I/O API - to make sure that whstever the signal intelkigence platform sensors captured could be written to storage.
(Not disagreeing that this is a dupe), but this is The Verge's coverage of Lumafield's findings.
Not sure if there is any additional value in the re-coverage, though it does feel like the message is important enough to be spread, and I suspect there is more readers of The Verge than the original source.
Distributing (and controlling) the necessary decryption seems like a helaciously difficult challenge for general/commercial aviation. Who are the authorized recievers of the ebcrypted data? How do we revoke access as time goes on? How do we handle normal key rotation (so that the adversary can't have unlimited time to crack/bruteforce the current keys)?
(Not my core field, so this is SWAG-ish): There is also a separate but equally important problem of signal vs noise - isolating the signal for decryption. Doable, but fairly costly to implement, and far more brittle than I suspect would be acceptable.
It feels like we have disparate mental models for what is happening.
Mine was that the noise generation was part of the adversary's actions (as is the presence of the drones themselves).
Are you suggesting that the noise (+encrypted data) is part of the airport's standard procedures, and authorized users pick out (and decrypt) the data, and everything else (like Command & Control) of adversarial devices is overwhelmed by the overall noise?
Would your signal eminate from the drones, or a dedicated platform?
Against the drones, that would be difficult to prevent, but the limitations imposed by the transmitter gear (size, weight, inverse square law of area being jammed) would probably limit the impact.
The dedicated platform would be located via signal strength analysis and likely physically destroyed.
Huh. So, making cell site simulators be more useful than just for doing wholesale surveillance?
Wonder if the goal is as wholesome (tool for rescue) as it seems, or there is some sort of commodization of this sort of tools being done, and so should not be subject to any special restrictions or regulation.
In the US, the terminology tends to split into "fired" (implies "for valid reasons") vs "laid off" (implies "position was terminsted, this was not about the employee or their qualities and performance").