[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