[mythtv-users] Be vewy, vewy quiet! We'a huntin' pirates! hehehehehehe!

Sam Varshavchik mrsam at courier-mta.com
Fri Jun 22 22:57:03 UTC 2007


Jay R. Ashworth writes:

> On Fri, Jun 22, 2007 at 07:06:07AM -0400, Sam Varshavchik wrote:
>> That's just a form of keyword-based search, which can be done without 
>> revealing entire guide data. What you need to do, in addition to encrypting 
>> program details using a symmetric cipher, with a per-program key, is to 
>> have a second copy of the program guide where each individual word W is 
>> replaced by H(w+secret). H is a hash function, MD5/SHA1/SHA256/whatever. 
>> "secret" is a secret known only to the server. To effect the search, you'll 
>> need to ping the server with w, the server returns H(w+secret), and that's 
>> what you run your search with. I've left out some minor details, but that's 
>> the general idea. 
>> 
>> I admit that, without some crafty hacking, you'll lose the ability to run 
>> arbitrary SQL searches, but this'll work for most searches that people use. 
>> Once your search finds individual programs, you'll then ping the server to 
>> get it's cipher, and obtain the program details.
> 
> So, if I understand you right, you want some centralized DBMS server
> somewhere *to participate in every scheduling event ever on all 200K
> mythboxes in the US*?

Oy-vey.  No database is required, of any kind. There's only one "secret", 
see above, that's needed on the server's side, to return hashes, upon 
request. If you want to use different per-subscriber hashes to vary the 
salt, just add the subscriber ID as an input into the hash function. The 
server does not care if the subscriber ID is valid or not, it's just goes 
into the hash.

This is easily distributable.  The hash servers have no dependencies 
whatsoever. Plus, unless you want the ability to rotate secrets, the mythtv 
client need to obtain the hash only once, when you initially set up a new 
search key, and cache the hash code in perpetuity. And if you want the 
ability to expire hashes, an intelligent expiration mechanism can easily be 
grafted.

> Got it.

Don't think so. Let's say that my secret is the word "rosebud". Scramble the 
program guide by replacing each word W with W', where W'=H(rosebud+W). 
Unless you know that my secret is rosebud, having your program guide filled 
with W' will not help you in any way to determine what my secret is.

Then, to search the program guide for the words "Star" and "Trek", ping the 
server for H(rosebud+star) and H(rosebud+trek), then take the resulting 
hashes, and that's what you search the program guide with. When you find 
some matches, that won't help you, in any way, to figure out what's in the 
rest of the program guide, which is still filled with more hashes. The only 
thing you can do is collect your matches, then ping the server for the 
decryption key for each program's guide data. And, please, I beg you, don't 
complain about having to do one round trip to the server, for each search 
key lookup, or program guide key retrieval. Just don't go there, please. 
That's absolutely false, and I pray to deity that you know it.

As I said, I've left out some minor, irrelevant details, such as forcing all 
inputs into the hash function into lowercase, so that you don't need to 
match upper/lowercase. Or maybe even use soundex, to get near maches.

Now, tell me, what kind of database do you need to do this, hhhhhhmmmmmmm? I 
don't know about you, but I certainly wouldn't need any cockamamie database, 
to hack up something like that. Write the code, distribute it across a bunch 
of servers, use DNS for load-balancing.

The more I think about it, the more I'm convinced that Zap2it's problems 
have a technical solution. I only hope that they considered it, and just 
rejected it due to the overhead of implementing this kind of a mechanism, 
despite its costs being offset, somewhat, by the value of additional 
demographical data obtained from knowing who searches for which words, and 
which program's details they pull down. If they folded just because they 
didn't have anyone over there with background in cryptography, and 
information security, then, and only then, we should all be pissed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20070622/e9bfdb62/attachment.pgp 


More information about the mythtv-users mailing list