StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POEncrypted database query
text
Body
copied!<p>I've just found out about Stack Overflow and I'm just checking if there are ideas for a constraint I'm having with some friends in a project, though this is more of a theoretical question to which I've been trying to find an answer for some time.</p> <p>I'm not much given into cryptography but if I'm not clear enough I'll try to edit/comment to clarify any questions.</p> <p>Trying to be brief, the environment is something like this:</p> <ul> <li><p>An application where the front-end as access to encrypt/decrypt keys and the back-end is just used for storage and queries.</p></li> <li><p>Having a database to which you can't have access for a couple of fields for example let's say "address" which is text/varchar as usual.</p></li> <li><p>You don't have access to the key for decrypting the information, and all information arrives to the database already encrypted.</p></li> </ul> <p>The main problem is something like this, how to consistently make queries on the database, it's impossible to do stuff like "where address like '%F§YU/´~#JKSks23%'". (IF there is anyone feeling with an answer for this feel free to shoot it).</p> <p>But is it ok to do <code>where address='±!NNsj3~^º-:'</code>? Or would it also completely eat up the database? </p> <p>Another restrain that might apply is that the front end doesn't have much processing power available, so already encrypting/decrypting information starts to push it to its limits. (Saying this just to avoid replies like "Exporting a join of tables to the front end and query it there".)</p> <p>Could someone point me in a direction to keep thinking about it?</p> <hr> <p>Well thanks for so fast replies at 4 AM, for a first time usage I'm really feeling impressed with this community. (Or maybe I'm it's just for the different time zone)</p> <p>Just feeding some information:</p> <p>The main problem is all around partial matching. As a mandatory requirement in most databases is to allow partial matches. The main constraint is actually <strong>the database owner would not be allowed to look inside the database for information</strong>. During the last 10 minutes I've come up with a possible solution which extends again to possible database problems, to which I'll add here:</p> <p>Possible solution to allow semi partial matching:</p> <ul> <li>The password + a couple of public fields of the user are actually the key for encrypting. For authentication the idea is to encrypt a static value and compare it within the database.</li> <li>Creating a new set of tables where information is stored in a parsed way, meaning something like: "4th Street" would become 2 encrypted rows (one for '4th' another for 'Street'). This would already allow semi-partial matching as a search could already be performed on the separate tables.</li> </ul> <p>New question:</p> <ul> <li>Would this probably eat up the database server again, or does anyone think it is a viable solution for the partial matching problem?</li> </ul> <p><em>Post Scriptum: I've unaccepted the answer from Cade Roux just to allow for further discussion and specially a possible answer to the new question.</em></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload