An online store needs to search or sort the identities of products purchased with the credit card, as well as the shipping addresses for orders purchased with the credit card, in order to fulfill the orders. A store offering a subscription arrangement needs to search for upcoming expiration dates so that it can 1. notify each subscriber that the card on file with the store is about to expire and 2. charge the ETF on the last valid day if the subscriber fails to update the card by the expiration date.

But you still need to store which cards are set to expire in a given month. And you still need to store some key with which to decrypt the card number when charging the customer for the subscription each month.

A store offering a subscription arrangement needs to search for upcoming expiration dates so that it can 1. notify each subscriber that the card on file with the store is about to expire and 2. charge the ETF on the last valid day if the subscriber fails to update the card by the expiration date.

Why do the expiration dates need to be encrypted? A thief can't do anything with just the expiration date without also knowing the CC number

search for upcoming expiration dates so that it can notify [customers]

Why do the expiration dates need to be encrypted?

They may not. But like credit card numbers, expiration dates are "credit card info", and notifying subscribers of cards due to expire is still "search[ing] credit card info". Besides, a store still needs to store the credit card numbers with which to charge the customer for each month, and the periodic billing process needs to store the key with which to decrypt the credit card numbers. So does the refund process for any store that sells physical goods and accepts returns.

well.. you have all the clients connected all the time and when a search is done the server sends the search to all the clients and they decide if they want to answer that search query........ ........

sounds real nice in a lab with 5 clients, right? but really shitty if you start to think about it at all.

(sure, plenty of web apps work nicely for that too because you don't do searches and only interact with a limited number of other clients..)

Why is this even a thing? All reversible encryption (which in itself is a tautology) is searchable.

Plaintext record ID > Encryption+key+salt etc > Cyphertext record ID. Search for the cyphertext record ID. Bring encrypted record back from database. Encrypted record > Encryption > Plaintext record.

How is this a marketable product?!

Searchable encryption is more complicated than you think. For example if I encrypt the sentence "I like reading slashot" with traditional encryption I will get a block binary data that is meaningless. Now suppose I want to check if that block contains the word "slashdot"? Your "cyphertext record id" approach won't be of much help. You need a few tricks to do it correctly, notably adding some metadata and additional cryptographic mechanisms. To make things more complicated, you often need the encryption mech

With symmetric encryption, when you encrypt with the same encryption key, you WILL get the same output that can be decrypted using the same key.

With password based encryption, you start with a passphrase and a salt, The passphrase and salt are combined and then run through a secure hash an agreed number of times. The resulting hash is the encryption key that is used with the cipher to perform the actual encryption. The salt and iteration count are why you can reuse the same passphrase.

Exactly what I was getting at. I was including op mode, iterations etc in "encryption" for brevity. Very few here (including me) understand what it actually does, just that it's part of good "encryption". The fact that it is reversible by definition is all I was getting at. If you couldn't recover the plaintext, it would be more like a hashing algorithm.

For a simple scheme, say you have a 32 bit integer as data but you store it in a 64 bit SQL field. You can come up with transformations that conserve ordering (e.g. 1 -> 15, 2 ->29, 3-> 54 and so on). You keep the key to that transformation in a local SQL proxy server and code and decode the data before sending it to the backend (in the cloud, for example). Nowadays this could be implemented in the model of your MVC application. The SQL server c

Well, if you're encrypting, it means the keeper of the data isn't supposed to know what it is, which means they can't do any data mining, selling, etc. of it anyway, which would be where the ability to do queries on the data would be useful. If you're encrypting everything, then all you need is to be able to find the records, and you could use hashed account names or something to index those.

So yes, it would be difficult to search/sort on the encrypted data, but then that's sort of the whole point...

I've implemented a similar solution for one of my web apps.It encrypts the data in the client with a password that they provide before it gets sent to the server. The client also decrypts the value when it receives it from the server.The password is kept in LocalStorage (a feature of HTML5) so that it is never transmitted to the server.Assuming the client application is not compromised, this is a great way to keep data secret even from the service operator.

Unfortunately, you won't see this scheme implemented in many apps because almost everyone's business model these days is all about scraping your data for use by advertisers.

I agree in that this won't be implemented because of the business implications but would also go on to say that this solution is unoriginal and undeserving of all the pomp and circumstance that the media and the educational institutions are giving it, before we know it they're going to give out Ph.D's and there patents for a high school paper on using electrolysis to make hydrogen and oxygen. Call the press!

There's another side to this too. You won't see this scheme implemented because encrypted data can not be de-duplicated, and can not be compressed. Effectively your solution increases the cost of doing business, both in terms of bandwidth and in infrastructure.

How much of "the data" needs to be encrypted and how much can be stored unencrypted?

In a lot of applications there seems to a subset of data that is sensitive and needs to be encrypted while much of it seems like it could be left unencrypted. There may be situations where all of it needs to be encrypted, but I'm guessing that means its stored encrypted now which means its not available for dedupe or compression anyway.

There's another side to this too. You won't see this scheme implemented because encrypted data can not be de-duplicated, and can not be compressed. Effectively your solution increases the cost of doing business, both in terms of bandwidth and in infrastructure.

Encrypted data can be compressed...just you have to compress before encrypting.

So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible! This sounds like a terrible solution!

So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible!

Actually, that objection applies to all encryption systems. You must have a key - which must also be hard to guess, thus fairly long and random - and that key must always be available to YOU. Once you recognize the necessity, there are many ways to handle it. Two or three USB sticks, for example (in case you lose one).

More generally, the objections to this approach seem to be largely based on cost and inconvenience. That's fine: you simply have to take a view of how much security and privacy are worth to yo

You won't see it implemented in free services for the reasons you describe. But it could work as a pay service. Most people will skip that in favor of free services that scrape their data, but some might.

I'm tempted to rent a server from Amazon or DigitalOcean or whoever and put the application on it myself, so I can access my data from anywhere without dealing with advertisements and privacy concerns.

Once decrypted, the data can be snooped on. If data can be decrypted in the browser, then the browser has everything that's necessary to decrypt it. If "Everything that's necessary to decrypt it" is provided by the server, then leaking is still possible. Browser-side decryption also makes this sound like a Javascript solution, which also means the site is potentially open to cross-site scripting attacks - if the application is not properly secured against that (and 35 lines of code hardly implies that it is

So because the NSA could install a keylogger on every gmail user's machine worldwide, google shouldn't bother to encrypt the data on their internal gmail servers where the NSA was previously snooping on all of it at once?

Of course there's always a weak point. Make that point less weak and the work to steal the data gets a little harder - maybe hard enough to defer the attacker - until the attacker adapts. Then fix the new weak point, and iterate until death.

Did something like this in 2005, with the data encrypted on the client side using the user's public key. The key pair is in a hardware USB token.

We also did something with this scheme for an electronic patient record project. Each doctor was issued a USB key with his/her own key pair, and when the doctor submitted any prescription to the system, the data were signed with his key, and the operation was logged into a central log database, each log record is linked to some previous log records in a Merkle tree so that we could detect if a log record has been tampered with or removed.

However, cryptography is hard to get right in applications, and clients are not willing to pay for it. Se stopped doing this after a while.

So, this is all well and good for really simple sites but what about larger, more complex sites that require server-side processing of data that, as I understand it, will only be available unencrypted to the client? Does this mean you need to expose your business logic on the client-side? This does not seem very secure to me no matter what promises they make about being able to detect client-side tampering...

Also, with regards to "searchable encryption", can this be applied to real search tools like Solr or

So basically this is PGP, it's pgp for the web, but ultimately still PGP. How is this even remotely newsworthy? PGP is 23 years old, throwing it up on the web then calling what you are offering a "web service" is a joke. Real web services actually offer you know, services, beyond simple data retrieval, and I saw nothing in the paper that would allow for instance a server to scan a database table with user information in it in order to present the data in a useful fashion, or for the data to be useful at

The Mylar system supports searching of the encrypted data and encryption with multiple, separate keys allowing multiple users to have access to specific records without requiring any key sharing.

The server can operate in a completely compromised fashion (in theory), as the data is all encrypted on the client side, before it goes to the server, and the server will never have the plaintext or the key to decrypt the ciphertext.

You don't even need XSS-like attacks. If you compromise the server you can re-write all the JS to send the encryption keys, the plaintext, or whatever you want to your server instead. Or back to the original server, and have it forward things on to you.

If the software on the user's computer is compromised or the user is stupid enough to print it on paper and leave it at the desk unattended... then those kind of things are out of a web application programmer.

The real problem is eventually you have to present the clear text to the user, what the user does with the clear text isn't an easy problem to solve.

It's a few days early for the April Fools edition of Slashdot. I'm sure the MIT researchers in question think they really have something here but it would be nice if they would've looked around before beginning their research. It seems as though this system connects to a server which then sends back encrypted data. That data is then decrypted at the local client. And they made a browser plugin for it. How is this fundamentally different than public key encryption?

Pretty sure you said brute-forcable which means just trying every key. As far as AES being weak, it is probably the most trusted cipher in existence. It has been around for over 15 years with the smartest cryptographers in the world trying to break it and no flaws have been found. Compare that to other ciphers like DES which researchers were skeptical of on day one and still took 20 years to break.

To clarify all misconceptions in other posts, having been to a talk of hers a few days ago, here's the encryption types involved: * RND (salted symmetric key encryption) - used for columns where no sql manipulation is needed
* DET (unsalted symmetric key encryption) - used for columns that need to be looked up by equality
* Partially homomorphic encryption - used for aggregation such as SUM()
* Order preserving encryption - useful for inequality where