Re: features/tokens

Paolo <[email protected]>
Newsgroups gmane.mail.spam.crm114
Message-ID <20090315122955.GE14565@localhost>
On Sat, Feb 21, 2009 at 05:36:07PM -0500, Bill Yerazunis wrote:
>    this will be a fairly complete list. Then, translating anyone's
>    tokens back into text is trivial, even if the hash function was
>    irreversible.
> 
>    Does is impose privacy issues? Am I missing something?
> 
> No, you're not missing anything.  That's the "dictionary attack"
> that I warn against, and that's why one should not consider one's 
> statistics files as being cryptologically secured.  

An attacker would need much apriori knowledge to do anything useful with 
such files, a simple disctionary attack is unfeasable imho - only if 'true'
unigram mode was used and length of word(s) to assess presence of in orig
text is known and bounded, and there's a way to check the result, there
would be some chance to do it in resonable time.

Eg consider a brute force attack on a 32bit hash looking for an 8 bytes
password: that'd mean checking (255+8-1)!/8!/(255-1)! ~ 2*10^19 combinations
which is currently undoable (100ps/hash -> ~10^9 s ~ 32 years, on a pretty
fast m.core CPU). OTOH if such bytes were from just 0x33..0x7e, the
number of combs would be (94+8-1)!/8!/(94-1)! ~ 2*10^11, ie doable in a
few hours on a ~GHz CPU.
And considering that hashed text could have been uu/b64-encoded, each comb
need be checked 3 times.

Of course, that's for true random text; if only 'pronounceable' pwd are to
be considered, that'd reduce such figure by orders.
But still that's the easiest situation, never met in crm114 usage (requires
just *that* single word stored, in 'true' unigram (ours' still bigram?) 
mode), since even the simplest msg comes usually with some junk around
the 'good' word(s). With bigrams and up number of combs skyrockets; add
to that that, a cssfile is just a BOW (Bag Of Hashes, indeed), ie you can't
tell which one is from straight strnhash(word) and which are from 
strnhash(a^x+...+word^y+...+b^z), and - if more msg have been learned - which
hash was in which msg.

The situation might look more favourable (to the attacker) in HS' cssfile
format, since there in each msg is stored as a separate ordered hash 
sequence (kinda DNA), so that one can think of some fast means to generate
text msg and compare the sequences.

But again, you may come up with a text whose hash sequence matches the 
stored one, yet you can't asses *that* was the orig msg, since the hash
function is a (infinite)->N map; which reminds me of a result from a guy
who, talking about sw patents, managed to match a binary string (either
representing a huge prime or a random, can't remember) to the binary img
of a patented & closed src sw: conclusion was, that given enough time & 
luck your *-crypto algo or just /dev/random may happen to put you in 
serious troubles, because they might end up with a 'secret' matching 
some proprietary/patented (binary img form of) some sw.


good luck ;)

-- 
paolo

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.