[tor-talk] Fwd: PrivateCore the real deal or snake oil?

Oded Horovitz oded at privatecore.com
Wed Oct 30 19:08:32 UTC 2013

Resending, should not bounce now.

---------- Forwarded message ----------
From: Oded Horovitz <oded at privatecore.com>
Date: Tue, Oct 29, 2013 at 1:57 PM
Subject: Re: PrivateCore the real deal or snake oil?
To: Justin Bull <me at justinbull.ca>
Cc: "tor-talk at lists.torproject.org" <tor-talk at lists.torproject.org>

Hi Oded,

Justin, tor-talk,

Thank you for making the time to reply.
Comments below.

It was an off-the-cuff remark about the use of the phrase "PRISM-proof".
That's akin to the phrase "unbreakable encryption"

We do not claim to have "unbreakable encryption", if you find some of our
own docs claiming that please point me that way. In fact we use standard
AES encryption.

The PRISM-proofness of our system refer to the fact that a service provider
cannot be compelled to provide information or keys, as he would not have
access to such information to begin with.

The setup we have described is a system in which the user of our hypervisor
deploy and run the hypervisor in a co-lo or bare-metal cloud provider
facility. The user doesn't share the hypervisor credentials with the
service provider, and therefore the only method of extracting information
from such running system is through physical forensics, such as physical
memory acquisition (e.g. Cold-boot).

Our hypervisor (KVM based) by design never store any runtime state in the
system memory, no code , no keys, no data, rather it limit the execution
environment to the CPU cache. Therefore cold-boot or other memory
acquisition method will reveal nothing but cipher text.

, a phrase most cryptographers will say is not a reality/possible[0].

The snake oil comment was more about potential future products coming to
market claiming to be "PRISM-proof" as well, and that wasn't directed at
your product or company directly.

Fair warning to the community, but it will do justice to at least attempt
to learn about an offering before labeling/suggesting as snake oil.

My concern is about companies or individuals capitalizing on such phrases
like "***-proof" and putting their customers at risk because the customer
may trust the product a little more than they should.

Customer must refer to security experts to validate what they cannot
validate by themselves. Trust but verify is the right motto here.

Personally, I would have been fine if you said "PRISM resistant" or you've
"developed a product to resist threats such as NSA and their PRISM program".

Just to be clear. We are not NSA proof, nor even resistant. But we are
PRISM proof, as a businesses cannot be compelled to give information they
do not have.

With all that being said, I'm happy and excited that you're putting forth
technologies that could potentially resist NSA attacks and I appreciate
your efforts in that matter.

Again, this is more a business protection than NSA proofing. We for example
cannot protect against backdoor in the CPU...

If you are a network operator, and encrypted communication is passing
through your infrastructure (passing not terminating) you could not be
compelled to give clear text, because you just can't.

We want to allow cloud provider to have the same protection when it comes
to computation.

Best regards,
Oded H

I've CC'd the list on the chance others interpreted my curt, snarky reply
the same way.

[0]: With the exception of one-time pads, of course ;-)

On Tue, Oct 29, 2013 at 2:24 PM, Oded Horovitz <oded at privatecore.com> wrote:

> Justin,
> If you are interested to hear more about our architecture and why it is
> nothing but snake oil, I would be happy to spend my time over a short call,
> and explain what we have built, and how and what it can defend against.
> At the least you would have an informed opinion ;)
> In regards to you comments that is linked in this article:
> http://blogs.computerworld.com/security/23036/prism-proof-solution-public-cloud-security-salvation-or-snake-oil
> Best regards,
> Oded Horovitz
> Co-founder, PrivateCore.

Best Regards,
Justin Bull
E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C

More information about the tor-talk mailing list