On 1 Aug 2010, at 3:28am, Nikolaus Rath wrote: > This not about encrypting data, it's about scrambling data. I want to > apply a one-way hash function to one or more columns of table. > > Possible use case: I want to send someone an SQLite database with my > data, so that he can debug an application that's using the database > (since it's having problems with the particular set of data that I'm > using it with). However, I don't want him to be able to actually read > the data.
And reading the data is what I warned you about: any encryption programmer could work out a good portion of your data unless your hashing function was /really/ lossy or you didn't supply much data. > Please don't suggest other ways of achieving this. There are plenty and > I am able to use them. My question is about the pros and cons of adding > a one-way hash function to SQLite (maybe calling it crypt() was > misleading for some). That's what got me. Not only is crypt() the convention for an encrypting function, it's the convention for a particular encrypting function. > Also, I would appreciate if you would not start a discussion about the > possibility of collisions or the fact that same strings in different > tables or columns would map to the same hash and thus weaken the > scrambling (in case you are tempted to). Everyone who uses a hash > function can be expected to take those things into account (that's why > my example contained different salt strings for different columns). hash(x) does not sort the same way that x sorts, so any operation that depends on the order of the returned rows will not work the same way. Similarly, anything involving '>' or '<' won't give the same answers. You will not be able to do maths on numbers or string operations on strings. Even if your data is made up of discrete strings, and you only ever care whether two strings are identical, then you need to worry how lossy your hashing function is. There's a chance that it will turn two different strings in your source database into the same string in your hashed database. This will, of course, mean that not even '=' would work the same way. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
