There are no significant protocols or implementations that use related keys though, this attack is purely theoretical. Also, 2^100 work is still out of the range of reasonable attackers for the foreseeable future.
That seems pretty dangerous. If you start a study with a ton of variables and no concrete hypothesis you end up with a situation like this: https://xkcd.com/882/
Yeah but it would also grind the economy to a screeching halt. Cars have huge beneficial value to society. Guns are specifically and exclusively for killing. That's why your straw man is not applicable.
Appeal to slashdot ID, haven't heard that one before lol. Who cares what the server supports if the clients don't allow it? All the client has to know is if they see the green lock (as you said) then their communications are secure. It would only matter if the client is using an extremely old browser, in which case SSLv3 is probably the least of your worries considering the huge number of unpatched security vulnerabilities you probably have going on. So yes, I am going to tell you that SSLv3 problems do not exist for the vast majority of people.
QEMU can emulate using OpenSGX, where you generate the certificates yourself. This allows people to test out SGX code but it is NOT able to transparently impersonate an SGX processor, which would attest with a certificate signed by Intel. And I'm not sure what you mean by licensing SGX, it is free and the SDK is GPL.
This is where I realize you don't know what you're talking about because SSLv3 has been disabled in modern browsers for 2 years now. Have a good day with your uninformed, knee-jerk opinions.
Let's Encrypt also participates in certificate transparency programs. Every certificate that it issues is put in a public log so if you ever encounter one signed by them you can verify that it is on there. On the other side, site owners can verify that all the certificates they asked for are on there and no extra ones for any sites they own. If enough people audit this, then maliciously granted certificates would be discovered and there would be indisputable proof that something bad was happening. Google Chrome automatically does some of this auditing whenever you visit an HTTPS site I believe, so it would be pretty difficult to get away with anything more impactful than an extremely targeted (toward only a handful of users) bogus certificate attack.
But ideally that process should not be volatile. If it is that is a whole other issue. That is like saying I don't want my website to automatically respond to HTTP requests, what if it makes a mistake? I have to be sitting next to it in case that happens.
Modern web servers support hot swapping certificates so downtime is not usually an issue. The most important reason for short expirations is that certificates with short expiration times are more secure against attackers that might be able to steal your certificate. A cert that is valid for a year will be much more valuable than one which expires in 90 days. The same holds true even for the Let's Encrypt credentials themselves. If Let's Encrypt refuses to grant any certificates longer than 90 days then your credentials are actually NOT as valuable as they would be otherwise. They also participate in public certificate transparency logs so it is easy to detect a situation where someone gets another certificate issued for your site.
Additionally, Let's Encrypt WANTS to make certificate renewal an automated process, and short expirations force users to do that like you said. There should be no reason to "think about the cert creation process" because CAs should never issue you a certificate with a cipher or key length that is not secure. The idea that web site administrators should all be up on the cutting edge of cryptographic attacks is pretty crazy actually. Standards should be enforced at the bottlenecks (in this case CAs) so that as few fuck ups as possible can happen.
No you don't have to trust the hypervisor, there is a method for the processor to cryptographically attest that it supports SGX in a way that the hypervisor cannot "fake" an SGX container. You are completely right that you have to trust Intel though.
Intel Software Guard Extensions are designed to address exactly this situation. A process can run code in a trusted enclave such that no other process (even the operating system or hypervisor) can inspect the contents of that process. If you trust that Intel has implemented it correctly, then you actually can securely deploy things on untrusted servers.
Other posters have mentioned homomorphic encryption but it could also be done inside a trusted enclave which is not able to be inspected by anything other than the executing process (even the operating system or hypervisor), see Intel Software Guard Extensions.
The filesystem could be encrypted though, unlocked with a password/key that is stored in memory. So yes, it is quite possible that memory extraction is necessary. And I would argue that the contribution of this paper is making the necessary memory introspection sufficiently quick and painless so that the VM cannot find out that something fishy is going on.
You apparently don't want to have an actual conversation. At no point did I ever insult you or devolve the to ad hominem attacks, and I have better things to do with my time than name call with random people on the internet. Have a good day, and I hope you find a better outlet for these feelings.
lolwut? I don't think you know what a straw man is. I directly refuted his argument that there is no proof that any man accused of rape actually did it, which is patently absurd. There are plenty cases with video evidence or multiple eye witnesses.
Appelbaum knows who they are, but imagine how that would go if he tried to tell anyone else their identities. "Hey everybody, this anonymous person that accused me of groping her in this specific situation is definitely Jane Doe because I only ever groped one person in that bar and.... oh... shit...."
I mean, forget about all those cases where there are videos of guys having sex with unconscious women, or women who are vehemently telling them not to. That's not "proof" I guess. By your logic you could never have proof of any crime. If I get you alone in a room and beat the shit out of you, maybe you did that to yourself? We can never know objectively. The only difference here is that you have some weird issues with women that you are projecting onto the situation.
It's not the same opportunity. Boys have the opportunity to take classes where they are with their peers and are generally accepted and comfortable. Girls did not have that opportunity, until now.
Every computer camp that is not a girl camp is a boy camp by default. Because the ratio of students is staggeringly in their favor. How do people not get that?
Slashdot Mirror
There are no significant protocols or implementations that use related keys though, this attack is purely theoretical. Also, 2^100 work is still out of the range of reasonable attackers for the foreseeable future.
That seems pretty dangerous. If you start a study with a ton of variables and no concrete hypothesis you end up with a situation like this: https://xkcd.com/882/
Just... carry it in your side pocket? I never understood why people put it in their back pocket in the first place, it is so uncomfortable.
Yeah but it would also grind the economy to a screeching halt. Cars have huge beneficial value to society. Guns are specifically and exclusively for killing. That's why your straw man is not applicable.
Appeal to slashdot ID, haven't heard that one before lol. Who cares what the server supports if the clients don't allow it? All the client has to know is if they see the green lock (as you said) then their communications are secure. It would only matter if the client is using an extremely old browser, in which case SSLv3 is probably the least of your worries considering the huge number of unpatched security vulnerabilities you probably have going on. So yes, I am going to tell you that SSLv3 problems do not exist for the vast majority of people.
QEMU can emulate using OpenSGX, where you generate the certificates yourself. This allows people to test out SGX code but it is NOT able to transparently impersonate an SGX processor, which would attest with a certificate signed by Intel. And I'm not sure what you mean by licensing SGX, it is free and the SDK is GPL.
This is where I realize you don't know what you're talking about because SSLv3 has been disabled in modern browsers for 2 years now. Have a good day with your uninformed, knee-jerk opinions.
Let's Encrypt also participates in certificate transparency programs. Every certificate that it issues is put in a public log so if you ever encounter one signed by them you can verify that it is on there. On the other side, site owners can verify that all the certificates they asked for are on there and no extra ones for any sites they own. If enough people audit this, then maliciously granted certificates would be discovered and there would be indisputable proof that something bad was happening. Google Chrome automatically does some of this auditing whenever you visit an HTTPS site I believe, so it would be pretty difficult to get away with anything more impactful than an extremely targeted (toward only a handful of users) bogus certificate attack.
But ideally that process should not be volatile. If it is that is a whole other issue. That is like saying I don't want my website to automatically respond to HTTP requests, what if it makes a mistake? I have to be sitting next to it in case that happens.
Modern web servers support hot swapping certificates so downtime is not usually an issue. The most important reason for short expirations is that certificates with short expiration times are more secure against attackers that might be able to steal your certificate. A cert that is valid for a year will be much more valuable than one which expires in 90 days. The same holds true even for the Let's Encrypt credentials themselves. If Let's Encrypt refuses to grant any certificates longer than 90 days then your credentials are actually NOT as valuable as they would be otherwise. They also participate in public certificate transparency logs so it is easy to detect a situation where someone gets another certificate issued for your site.
Additionally, Let's Encrypt WANTS to make certificate renewal an automated process, and short expirations force users to do that like you said. There should be no reason to "think about the cert creation process" because CAs should never issue you a certificate with a cipher or key length that is not secure. The idea that web site administrators should all be up on the cutting edge of cryptographic attacks is pretty crazy actually. Standards should be enforced at the bottlenecks (in this case CAs) so that as few fuck ups as possible can happen.
No you don't have to trust the hypervisor, there is a method for the processor to cryptographically attest that it supports SGX in a way that the hypervisor cannot "fake" an SGX container. You are completely right that you have to trust Intel though.
Intel Software Guard Extensions are designed to address exactly this situation. A process can run code in a trusted enclave such that no other process (even the operating system or hypervisor) can inspect the contents of that process. If you trust that Intel has implemented it correctly, then you actually can securely deploy things on untrusted servers.
If you trust Intel, then yes. It is designed expressly to address situations like this.
Other posters have mentioned homomorphic encryption but it could also be done inside a trusted enclave which is not able to be inspected by anything other than the executing process (even the operating system or hypervisor), see Intel Software Guard Extensions.
The filesystem could be encrypted though, unlocked with a password/key that is stored in memory. So yes, it is quite possible that memory extraction is necessary. And I would argue that the contribution of this paper is making the necessary memory introspection sufficiently quick and painless so that the VM cannot find out that something fishy is going on.
You apparently don't want to have an actual conversation. At no point did I ever insult you or devolve the to ad hominem attacks, and I have better things to do with my time than name call with random people on the internet. Have a good day, and I hope you find a better outlet for these feelings.
I think you believe that what you are writing is a coherent thought, but I assure you it is not.
lolwut? I don't think you know what a straw man is. I directly refuted his argument that there is no proof that any man accused of rape actually did it, which is patently absurd. There are plenty cases with video evidence or multiple eye witnesses.
Appelbaum knows who they are, but imagine how that would go if he tried to tell anyone else their identities. "Hey everybody, this anonymous person that accused me of groping her in this specific situation is definitely Jane Doe because I only ever groped one person in that bar and.... oh... shit...."
That kind of logic is insulting to men. To imply that no man can resist groping a woman that is close enough to them is ridiculous and reductive.
I mean, forget about all those cases where there are videos of guys having sex with unconscious women, or women who are vehemently telling them not to. That's not "proof" I guess. By your logic you could never have proof of any crime. If I get you alone in a room and beat the shit out of you, maybe you did that to yourself? We can never know objectively. The only difference here is that you have some weird issues with women that you are projecting onto the situation.
Stop being willfully obtuse. In regular classrooms there is not a 10:1 ratio of boys to girls.
It is not that they "can't hack it", it is that an environment which is openly hostile to you is not conducive to learning.
It's not the same opportunity. Boys have the opportunity to take classes where they are with their peers and are generally accepted and comfortable. Girls did not have that opportunity, until now.
Every computer camp that is not a girl camp is a boy camp by default. Because the ratio of students is staggeringly in their favor. How do people not get that?