I see no way this could ever work the way they want and still be secure. They have two conflicting requirements - strongly encrypting the data and not breaking the functionality of third party applications operating on this data, that is making the encryption transparent to a (sub)set of operations (not under their control).
It 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).
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).
It 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).
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).