I spotted a few oddities in the reporting of these ‘secret papers’.[1]
The only extract of the report the journalists show is, at the very least, misleading. They’re claiming that Fujitsu employees could do a type of requests which would (i) change the record of the transactions in the audit log and (ii) would actually impact the postmasters accounting position.
However, the report actually states that these are two different types of requests, the first one doesn’t impact the accounting position and the second one (BTs) could change the accounting position but would be recorded in the audit log.
The audit log shows that BTs, have only been used once in the period at hand so are unlikely to have caused the accounting shortfalls.
I would quite like to see the original Post Office “Defense” that is mentioned in the article, but don’t know where to find it. Would somebody have a clue?
Quantum Key Distribution (QKD) requires special (expensive) hardware, so it really doesn’t solve the problem of key size.
Moreover, QKD still requires an authenticated channel, so we’ll still need a quantum-resistant authentication scheme.
(All in all, QKD does not have a singular use case)
I dont disagree with this.
I just want to highlight that to do this sort of sandboxing in any systematic manner, you’ll always need to go down at the system level.
Because here we’re trying to sandbox the system using abstraction at the language level which is bound to run into impedance mismatch. I don’t think it’s the role of the language to restrict which system calls are acceptable.
However, there is some appeal to the syntax introduced by the author if we use it for a proper and portable sandboxing mechanism.
Maybe WASI, with capabilities?
To be more specific, there’s no reason for rust to know that writing to a specific file will allow modifying the program’s memory. It’s also not a security problem from the system, it’s just how it works. It really only makes sense for the system to enforce that kind of sandboxing, because it has enough context to enforce things sensibly.
You don’t even need unsafe to reproduce unsafe behaviour on Linux.
You can just read and write to `/proc/self` and modify memory arbitrarily.
If you have `std::fs`, then you have `unsafe`, then you’ve got everything.
In general, sandboxes don’t work well at the language level. You really need to go at the system level.
Luther’s 95 theses literally condemn « indulgences » as promoting greed…
I assume you were making a reference to Weber’s work (the Protestant ethic and the Spirit of Capitalism), which happened a few centuries later and has been heavily criticised and nuanced since.
> What would be better would be a dTPM that is integrated e.g. into a SoC, such that there are no exposed wires anywhere without decapping the SoC. Some systems such as phones work like that, but this is hard to tell even from the technical specs.
> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data.
I’m always very confused by this. TPM offers encrypted sessions (setup with the Endorsement Key) for exactly this kind of attack. Why couldn’t the firmware get the keys over an encrypted session? Is it for reliability in case certificate verification goes wrong?
Thanks for the layman’s explanation, I didn’t realise something like that was even possible!
What are some use cases for using it? Are they all crypto-currency related?
That’s "good things happen to (some) bad people. Rejoice!" Quite the opposite of what was said above.
I don’t consider myself a Calvinist, so I don’t have skin in the game.
However, sweeping statements like this prevent you from understanding the "real" root causes.
Maybe the original commenter meant to blame puritans?
Yes, please. I’m pretty sure Calvinism says that everybody is corrupted by sin (not just prisoners) and that everybody is in need of God’s grace.
There’s certainly nothing about celebrating when something bad happens to somebody.
From a more security security research point-of-view, the paper “Bootstrapping Trust in Commodity Computers”[1] is a very good overview. Although it would necessitate a bit of an update for more recent developments with e.g. dm-verity etc.
Damage is already done, they’ve shipped nearly working software to any creep and police officer that need little modification to actually work.
I wonder though what is the GDPR status of something like that? Is anybody just allowed to build a biometric database using public or personal photos?