41–50 of 60 posts
From a paper in that article: "Intel has recently added support for monotonic counters [5] as an optional SGX feature that an enclave developer may use for rollback attack pro- tection, when available. However, the security and per- formance properties of this mechanism are not precisely documented. We performed a detailed analysis of SGX counters and report our findings in Appendix B. To summarize, we found out that…
The gist of them is that instead of using hard computational work to secure a chain against sybil attacks, they use timeouts enforced by Intel. To get more mining power in proof of work, one has to buy a lot of hashing chips, and feed a lot of power into them. To get more mining power in these "proof of Intel" schemes, one must buy more SGX chips from Intel. The supposed benefit here is that the SGX chips consume much less power than the hashing chips.
That's all well and good, except- both of the schemes in the linked papers have the same security properties as if Intel simply set up a centralized timestamping server. Intel's timestamping server would also perform a lot faster than any of these blockchains.
So the security of a blockchain now depends on the security of the SGX enclave? What could possibly go wrong... > Unfortunately, this proposal suffers from a critical security economics issue: node maintainers here have a strong incentive to break into their own SGX chips. If an adversary managed to compromise their SGX, they could win the leader election at every round by setting the timeout to 0. The more valuable…
Part of it is community agreement. In order to mutually trust what we do on each others' machines, we give up some rights, including the ability to lie about what you executed on your own machine. It is the implicit agreement in Folding @home and many community computation projects, only this is better enforced. Peer-to-peer computation is hard to implement because of the quite hairy social aspect of requiring a trus…
Furthermore, the actual implementation isn't likely to use a narrow proof that the running javascript hasn't been tampered with, but rather a blunt proof over the entire software environment. The outcome would basically be putting decades of personal computing freedom back in the box. Imagine needing to run Windows on your bona fide desktop and not being able to virtualize it or even use a headless box via RDP.
Earlier quoted context omitted.
> I agree that that's an unreasonable assumption which is why we developed RRR. Out of curiosity, I would've hoped that the consensus in the cryptography community is that "secure enclaves" are pretty much snake oil to begin with... is this not the case? (I mean... for a secure enclave to actually work, you need "perfect" physical security, "perfect" software implementation inside, and "perfect" design of the cryptog…
You have a very limited understanding of what "works" and what is "impossible", it seems. Actual security engineering occurs in hostile environments all the time, in extremely non-perfect environments, with non-perfect tools, and many of its principles (and practices) noticeably make security better for users, operators, and engineers. Similarly, DRM is not only NOT "impossible", it's very possible, very real, and ac…
I haven't "made up my set of Nerd rules." I have learned what the general expectations of my users are.
From a paper in that article: "Intel has recently added support for monotonic counters [5] as an optional SGX feature that an enclave developer may use for rollback attack pro- tection, when available. However, the security and per- formance properties of this mechanism are not precisely documented. We performed a detailed analysis of SGX counters and report our findings in Appendix B. To summarize, we found out that…
How long until we see an SGX-damaging malware in the wild that simply eats up all the monotonic counters?
Earlier quoted context omitted.
It's not "your own platform", that's what the article gets wrong. The entire purpose of SGX is that it's my platform (that I can control/be assured that you can't), running on your hardware.
It's not my platform either, it's Intel's platform and I'm simply trusting them as to what code is running on SGX. Might as well trust Amazon or any other cloud provider.
Earlier quoted context omitted.
it'd decentralised, not controlled by single entity.
So, like git?
The two blockchain papers are so ridiculous on their face that I find it amazing that the authors were able to work on them at all (Intel funding may have helped in that regard). The gist of them is that instead of using hard computational work to secure a chain against sybil attacks, they use timeouts enforced by Intel. To get more mining power in proof of work, one has to buy a lot of hashing chips, and feed a lot…
As for the two schemes, you are correct about the first paper that it depends on the timeouts enforced by SGX. However, the second paper makes no such assumptions and doesn't even assume that the enclave is secure; all it relies on is the attestation service (which is remote).
Earlier quoted context omitted.
it'd decentralised, not controlled by single entity.
So, like git?
Earlier quoted context omitted.
The assumption behind PoET is precisely that you don't control a part of your machine (the SGX enclave). I agree that that's an unreasonable assumption which is why we developed RRR.
> I agree that that's an unreasonable assumption which is why we developed RRR. Out of curiosity, I would've hoped that the consensus in the cryptography community is that "secure enclaves" are pretty much snake oil to begin with... is this not the case? (I mean... for a secure enclave to actually work, you need "perfect" physical security, "perfect" software implementation inside, and "perfect" design of the cryptog…