Tag Info

Hot answers tagged

59

I could not find any evidence pointing towards homomorphic encryption. What I could find were different combinations of deterministic and format preserving encryption. There is probably also a variant that preserves order, but I couldn't find any material depicting it. This post is based on material published on the CipherCloud website at CipherCloud Cloud ...


23

I don't think they have implemented homomorphic encryption at all. They have just implemented regular AES encryption (they have a FIPS 197 certificate for their AES), but in what appears to be a very insecure way. Why would they choose to do that? Because they had no choice. Here's what I mean: The challenge for cloud encryption providers like CipherCloud ...


21

My recommendation: No, you should not trust CipherCloud. Justification: Yes, there has been analysis of the CipherCloud system -- some of it right here on the Cryptography StackExchange. That analysis found what appear to be severe vulnerabilities in the CipherCloud system. Unfortunately, CipherCloud has apparently sent StackExchange a DMCA takedown ...


20

I haven't posted in a while, so long in fact that the email tied to my Stack Exchange account is no more, I forgot my StackEx password, and I had to create a new account. (I'll leave it to the reader to decide if this is the real me.) But I did want to just to follow up here, because there were some unanswered questions from my last post and the follow-up ...


17

They are not using any exotic encryption. In fact, based on data, it appears it's just 1:1 mapping (tokenization) after lowering the case on plain text data. I don't know about others but to me this pattern just stood out when I had a look at the demo video. To see it yourself, check their publicly visible demo video. Hit HD, go full screen to 2:19. You will ...


11

I also watched the video (thanks Sid, for the link) and after looking at it, it reveals some of the other methods that Ciphercloud appears to be using to preserve search. Nothing appears to be an implementation of any sort of homomorphic encryption. I snapped a copy of one screen after the response from John is entered and encrypted, and have attached an ...


10

I don't know how CipherCloud works. However, a related question is: How could you encrypt data in a database, in a way that allows you to achieve these goals? What are the best cryptographic techniques currently known, for that goal? As it happens, that question has a good answer. Take a look at CryptDB, a system built by MIT researchers to encrypt all ...


10

Looking at the MSDN link given by Tangurena, they use the word salt in this paragraph (and the following ones): To prevent discovery of plain text content by comparing encrypted values (the second attack), most encryption algorithms include a salt value. Specifying a different salt value generates a very different encrypted output. When using the ...


9

This is not a limitation of the cryptographic functions, like SHA or PBKDF, since the zero byte isn't processed any differently. Since the purpose of a salt is generally to travel alongside a human password, libraries that handle the password as a zero-terminated string might also handle the salt as such a string. Obviously, a 0x00 in the salt would ...


8

CipherCloud's website now clearly states, here, that CipherCloud DOES NOT use homomorphic encryption. This also states that CipherCloud DOES NOT implement 1:1 mapping or ECB mode in any customer deployment. Other statements are next to acknowledging that CipherCloud's early demos did that, citing the will to illustrate the functionality, features that where ...


7

Using a static IV isn't simply "poor form" — it introduces crippling weaknesses to the security of your ciphertexts. Likewise, using correctly-generated IVs (the requirements differ from mode-to-mode, but cryptographically random IVs almost always meet those requirements) isn't "better"; it's absolutely necessary. That said, there is absolutely no ...


6

If you go through the math, it appears that exactly the expected amount of ciphertext expansion is happening. Here's what's happening: The GCM takes the plaintext as a byte string of size N, and generates a ciphertext which is a byte string of size N+28, where 12 of the 28 is the nonce, and the other 16 is the authentication tag. Then, that octet string ...


5

What you are proposing in effect means that you use a not-really-random one-time-pad, which is used twice (i.e. a two-times-pad). This is not secure. Using a single hash to generate a key from a password is a bad idea - especially if the password is short, it is easy to brute-force it (i.e. try lots of passwords). Using the simple XOR cipher to encrypt a ...


5

Let's try to avoid random per-password salts. If the only requirement for salt is to be unique, which is the case for good password hashing schemes, you'll need: $globalSalt$ is a secret random 32-byte string. $userId_n$ is a unique user identifier. You can use, for example, $HMAC$-$SHA256(globalSalt, userId_i)$ to generate salt for each user $i$. Or, ...


5

Unfortunately, without some additional assumptions about the strings (e.g. that the first 8 bytes are unique), there is no way to reduce the chance of collision below the usual chance levels. If you need unique 64-bit ids, the options are: Do a database lookup when generating keys and pick another key if it is already in use (you state that you want to ...


4

Yes, this is fine, at the record level. (What you've built would be classified as a "Encrypt-then-Authenticate" scheme in the literature, and there are standard provable security results for such schemes.) Well done on constructing a solid, well-engineered cryptographic scheme. An AEAD mode would spare you from having to invent such a scheme, but what ...


4

GCM mode is best, as it can not be attacked using padding oracle attacks, which are much more common than commonly thought. It is also the only one providing integrity protection, something that is certainly much overlooked. Make really sure your NONCE is random though, or use one that is uniquely defined (even in time) within the database. ...


4

Adi Shamir's secret database of all primes is to cryptography venues what the Dahu is to French summer camps. For why, see the answers to this related question. The three other future work items in the quoted presentation are in the same vein (Breaking RSA-1024 with Fermat factoring; Breaking RSA-1024 using $1024 = 2*2*2*2*2*2*2*2*2*2$; Breaking RSA-1024 ...


3

I would say that CBC+HMAC mode is the best of the three (although not the fastest), because of the various security requirements on the IV/nonce. For GCM and CTR, the counter must be unique, for every pair encryption key/plaintext. I assume the key will be always the same. Uniqueness is very difficult to securely achieve in practice. If you rely on some ...


3

I think you misunderstood what they were saying. But then, reading the MSDN topic on Cryptography in SQL Server, they make a vaguely similar claim to what you said you heard. SQL Server 2008 supports encrypting entire databases. It is a bit complicated to set up, but protects the mdfs and backups if stolen. There is a function called HashBytes which ...


3

Let's have a look on how OpenID works. Alice wants to log into Bob's website using Charles as her identity provider. (So, you are Bob in this scenario.) Alice fills her OpenID alice.openid.example.org into Bob's web form. Bob (or Bob's server, actually) transforms this into a canonical form https://alice.openid.example.org/, and fetches this resource to ...


3

IMO AES-CTR+HMAC is more secure than AES-GCM. The most significant difference is that AES-CTR+HMAC relies on the nonce for confidentiality but not for integrity. AES-GCM on the other hand relies on the nonce for both. So nonce failures are much more severe with AES-GCM. The main advantage of AES-GCM is that it's significantly faster.


2

That paper refers to the numerical ordering, while what would be relevant for searchable encryption without changes to the providers is the substring ordering. $\:$ (Thus, their bound does not apply.) What do you mean by "existing queries in a database"? If your assumption holds, then { Encryption must be deterministic (given the key), since different ...


2

First, as a bit of general advice: Designing a secure cryptographic system is hard. Experts with decades of experience still make mistakes. Depending on your intended audience, you may be better served by looking for an established system that meets your needs rather than trying to design an implement something from scratch. To answer your specific question ...


2

I don't think there is an existing library that can satisfy your needs. Homomorphic encryption is powerful and requires lots of computations. However, in your case which allows user-defined keywords, I suggest you to take a look at Searchable Encryption. Searchable Encryption is the algorithm that should be of interest. It allows cloud server to search ...


2

Cryptdb has a search component which implements techniques from this paper this might be helpful to get some insights and get started , cryptdb is open sourced code is available


2

What you describe is a digital signature, which works using methods very similar to the one you suggest. Examples include elgamal-signature and RSA signature schemes (the second of which I would recommend you read). Digital signatures allow you to provide a public signature that 'proves' you provided the message. As the author, you would produce database ...


2

Is there a technically feasible way for companies like CipherCloud to use homomorphic encryption (HE) while preserving full functionality in a third party SaaS app (e.g. Salesforce)? Fully homomorphic encryption can theoretically1 compute any function. Therefore, if a computer can perform a task on plaintexts, then fully homomorphic encryption could ...


2

This answer builds on the answer supplied by @otus. There is also an important worry about whether the main solution works at all as advertised. I am posting it now to make clearer to @otus a question I asked in a comment. I will eventually either delete it or substantially revise it. First off, let me emphasize that if the table is going to be used to ...


1

However, if instead you truncated the hash to (64 bits - X bits), and concatenated the resulting hash with the first X bits of the input string, you'd reduce the chance of collision since two similar strings are unlikely to produce the same hash code: For a good cryptographic hash a given similar string is just as likely to have a hash collision as a ...



Only top voted, non community-wiki answers of a minimum length are eligible