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