Live data from Hacker News

CipherCloud Responds to the Crypto StackExchange Controversy

blog.ciphercloud.com

21–30 of 65 posts

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#21
post #14
post #7

> A couple of recent discussions in a few board threads contributed to by our competitors have questioned CipherCloud’s approach to delivering cloud information protection. My BS meter is running high.

You might want to recalibrate it; the mercury should have burst the tube at this point. Searching encrypted data is impossible without fully homomorphic encryption and fully homomorphic encryption is wildly impractical for use at present. "Contributed to by our competitors" -- if that's the case, the competitors are giving informative SO answers about crypto. Whereas they are engaging in censorious shenanigans. I, fo…

"Searching encrypted data is impossible without fully homomorphic encryption"

That is not true; a private information retrieval protocol can be used to search encrypted data:

https://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=568331...

You could also use an oblivious RAM, although I do not think that is practical yet:

http://eprint.iacr.org/2010/366.pdf

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#22
Weasel wording filter:

Graf 1, sentence 1: "a few board threads" -> Internet's current most important programming forum.

Graf 1, sentence 1: "contributed to by our competitors" -> Smoke screen, unsupported, irrelevant.

Graf 2, sentence 2: "basically admitted they really didn't know the facts" -> Because the facts weren't provided, the contributors set about reversing them from published material, the point of the thread.

Graf 3, sentence 4: "does use publicly available, well researched, and NIST validated cryptographic algorithms" -> Virtually all cryptography anywhere can make a similar claim, and most of that code is broken. NIST validates primitives and a few basic constructions, but tying those primitives into a functional cryptosystem is outside their purview.

Graf 4, sentence 1: "for any customer deployments" -> Leaves open the question of whether they implement semantically insecure constructions in any setting.

Graf 5, sentence 2: "fundamental security features (full field encryption, randomization through IVs) were disabled" -> Randomized encryption isn't a feature, it's a fundamental property of a cryptographic construction.

Graf 6, sentence 1: "currently in the process of obtaining our FIPS 140-2 certification" -> FIPS 140-2 doesn't involve a rigorous analysis of cryptographic primitives; the crypto-specific components focus on use of NIST-approved ciphers and block modes, but do not assure that those primitives are used securely. To illustrate that point: every vulnerable version of SSL3 and TLS1.0 and TLS1.1 has had a FIPS-compliant implementation somewhere.

They should just be honest about their desire to suppress the use of their copyrighted IP in critiques of their product. They're in a competitive space, they're a small company, hard to manage their online reputation and build product, &c. The Reddit/HN/Stack Overflow scene wouldn't like that response, but it's better than this one, which actually creates more questions about their product capabilities.

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#23

I didn't follow this story. Where can I find more information about this "Controversy"?

Basically, someone called out CipherCloud on apparently bogus claims about what they provide (homomorphic encryption). CipherCloud responded with DMCA takedown notices. Now they are trying to explain their actions, with a lot of "trust us, we are only hiding the crypto details because we need to maintain a competitive advantage!"

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#25
post #12

Earlier quoted context omitted.

That's what the citizens get when they don't hire lobbyists.

So how can this be fixed?

Stop voting for politicians who have proved themselves to be servants of lobbyists and corporations, start voting for these guys:

https://en.wikipedia.org/wiki/Third_party_%28United_States%2...

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#26
post #22

Weasel wording filter: Graf 1, sentence 1: "a few board threads" -> Internet's current most important programming forum. Graf 1, sentence 1: "contributed to by our competitors" -> Smoke screen, unsupported, irrelevant. Graf 2, sentence 2: "basically admitted they really didn't know the facts" -> Because the facts weren't provided, the contributors set about reversing them from published material, the point of the thr…

> their desire to suppress the use of their copyrighted IP in critiques of their product

Which is a textbook case of fair use. They may want to do that, but legally, they almost certainly can't.

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#28
post #10

> Service Temporarily Unavailable > The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Everything they do is destroying their reputation. Unfortunately, only among a few people who would have been suspicious anyway.

If you're interested in seeing what's left of their reputation, take a look at Google's cache of their page. Looks like some malware:

http://webcache.googleusercontent.com/search?q=cache:http://...

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#29
This is a good example of bad legal/PR turning a company from a fairly well respected new security company to a joke.

Tokenization, which CipherCloud does, could actually be done fairly securely if you had a decent amount of local storage. They IIRC use a FIPS HSM for local key storage in their local appliance (I talked to one of their founders as a security event a year or two ago and was initially suspicious of their claims, but it seemed adequate for certain use cases based on how they were using it -- maybe things have changed). It's fundamentally not too different from when Stripe gives you a user key vs. PCI information.

Basically, if you can correctly identify certain fields as sensitive and others as not, and force all your traffic through a proxy, you could do totally unrelated random tokens in fields, and then do search locally on the appliance, rather than on the untrusted service. E.g. if you wanted to use Salesforce, but keep customer addresses secret (because they were super-confidential government sites or meth labs or something), you could still put names in Salesforce and do everything else, but just put a random string in for addresses; do address searches on the proxy, either going from single record to address or maybe even "give me all the records in Missouri". There is no magic here. Someone could do an open source implementation for any specific site (via scraping or a public API) easily. The difficulty is doing it for many sites, and keeping it updated, supporting it, and selling it to fortune 500.

I don't know if they've been pushed to do stupid stuff, or if they just have horrible marketing/PR now (which is weird since they raised a fuckton of VC), or what.

Re: CipherCloud Responds to the Crypto StackExchange Controversy

#30

This is total BS. How is posting a few screen-grabs from their publicly available video a violation of their copyright? Isn't it considered fair use? I was expecting more on the lines of "we are sorry for the whole fiasco, our legal team acts independently whenever it feels like there is a violation", instead of him defending the DMCA. They used DMCA to try and censor a debate about their lies. Talking about DMCA, is…

I believe this was a fair use of out critique laws. We are allowed to show copyrighted work when criticizing, reporting and other public things like that.
Post reply on HN