Earlier quoted context omitted.
That's what the citizens get when they don't hire lobbyists.
So how can this be fixed?
CipherCloud Responds to the Crypto StackExchange Controversy
31–40 of 65 posts
Re: CipherCloud Responds to the Crypto StackExchange Controversy
#32Earlier quoted context omitted.
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
To be specific I mean a second party being able to search the data for arbitrary strings would mean the security of it was broken completely, and I thought this service was storing and searching without client input.
Re: CipherCloud Responds to the Crypto StackExchange Controversy
#33https://webcache.googleusercontent.com/search?q=cache%3Ablog...
"A couple of recent discussions in a few board threads contributed to by our competitors have questioned CipherCloud’s small online payday loans. same day payday loans. easy online payday loan. direct lender payday loans online. approach to delivering cloud information protection."
Re: CipherCloud Responds to the Crypto StackExchange Controversy
#34Re: CipherCloud Responds to the Crypto StackExchange Controversy
#35Earlier quoted context omitted.
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
#36Favorite line in the whole thing "Some of the fundamental security features made available (e.g. full field encryption, randomization through IVs, etc.) were disabled because we were not comfortable sharing such IP on the internet while our patents are still pending" So, apparently they are going to be patenting padding/randomization in encryption and "full field encryption". Our patent system at work for obvious thi…
Re: CipherCloud Responds to the Crypto StackExchange Controversy
#37Weasel 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
#38Re: CipherCloud Responds to the Crypto StackExchange Controversy
#39It is feasible to strongly encrypt all data but you have to make sure that you do not accidentally implement ECB mode or something similar when using a common block cipher like AES. So you definitely want a unique IV for every piece of data you encrypt. But now you have also broken all server-side functionality because (almost) no useful operation will produce the expected result when operating on encrypted data. Client-side functionality is no problem because it only sees decrypted data.
Therefore they (have to) make compromises. Actually the user has to make the compromise - keep some data unencrypted or lose the server-side functionality. This is most prominent in the demos with numeric data that needs to be aggregated, averaged and what not. Actually it would be not to easy to encrypt this numeric data because you have to preserve the format including limits and disallowed values or otherwise the server would reject some values.
What about the infamous text fields? They are probably the easiest to encrypt but you still have to be careful not to break validation rules, for example by making the encrypted text much longer or making an e-mail regular upset (but I bet most applications perform only client-side validation). But this again makes the third-parts application a lot less useful because you lost the ability to search in your textual data. The problem to solve is the following one (with some minor details ignored).
text.contains(searchText) == encrypt(text).contains(doSomething(searchText))
I - not being a cryptography expert - can not think of a way to get this working without leaking information and CipherCloud's solution as discussed on Stack Exchange definitively leaks a lot of information. This is really a very tough problem. (Probably) not even homomorphic encryption would help because you have no control over the comparison method - it is plain old substring search, maybe case insensitive and that's it. It is solvable using private information retrieval in the relaxed case when you have control over the comparison operation but with substring search it is probably to hard (if you want to keep the cipher text length similar to the plain text length).Re: CipherCloud Responds to the Crypto StackExchange Controversy
#40Earlier quoted context omitted.
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...
Whats the guarantee these guys won't sell out?