full-disclosure - Re: Does this exist ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070706015255.f6xk46g33vow0co8@www.bsdnixsolutions.com>
Date: Fri, 06 Jul 2007 01:52:55 -0500
From: Dan Becker <list@...nixsolutions.com>
To: Andrew Farmer <andfarm@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Does this exist ?

Quoting Andrew Farmer <andfarm@...il.com>:

> On 05 Jul 07, at 06:20, Dan Becker wrote:
>> I have an idea that won't leave me alone and this list seems to   
>> have the most potential for knowing if the idea exists. My   
>> apologies for a somewhat offtopic post.
>>
>> Would there be a way to create a  rainbow table of tcp packets to   
>> be used to generate one packet for every 1000 or so normal packets   
>> simply by matching hashes with databases on both ends ?
>
> No; for a 128-bit hash (for example) there are only 2^128 packets which
> can be uniquely represented. This is far below the 2^12144 1518-byte
> packets which are possible, so - by the pigeonhole principle, there
> will be collisions. Increasing the hash size won't help unless you make
> it at least as large as the packet, at which point you aren't gaining
> anything.
>
> Computing such a rainbow table is computationally impossible, anyway.
> The largest keyspace which I know of that's been brute-forced was
> somewhere around 64 bits, and that takes either dedicated hardware or a
> distributed-computing network. 128 bits is believed to be physically
> impossible, and even that is just barely enough to fit a TCP header
> into, without any data.
>
> If the data being transmitted over the link is reasonably redundant,
> then you might get lucky and be able to just hash the relevant packets
> ahead of time. However, you could probably do even better with a
> purpose-built compression scheme anyway.

I thank you for the reply and must apologize for using the wrong  
terminology. A rainbow table isn't really what I am thinking about.

Think of DNA strands, we all have the potential to be any living thing  
on the planet. (to my limited understanding of DNA)

Now lets apply that to digital data. We all have the 0's and 1's to be  
any potential data already in the computer. Let us go further and  
create a database of a packet data field with 500bytes in the data  
field or 2^4000 which would come to 16 million entries. Modern  
databases can do extremely quick lookups with the properly configured  
database having that many entries.

So we generate a packet using the idpacket field of a database to  
describe which packets should be assembled in which order then send  
it. 1 packet to send 500.

Then upside is everyone has the potential to create any data possible  
already at their command and data transmissions will be increased  
exponentially. The downside being intellectual property is not going  
to be easy to enforce considering all you are doing is defining the  
order packets are assembled.

Am I missing something ? Would a hash function not be able to do this  
? Would a packet checksum be similar to the hash function I am  
thinking about ?

Again my apologies for offtopic postings.

------------------------------------------------------------------------

      All message scanned for viruses with Clam Antivirus.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/