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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ae653bf0707060033y5bf90d85p2d59c720e92b1cee@mail.gmail.com>
Date: Fri, 6 Jul 2007 17:33:18 +1000
From: Fionnbharr <thouth@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Does this exist ?

Ah 2^4000 is rather big, I suggest you plug something less into a
calculator to see how big 2^ can get. If you're looking for 16ish
million entries you want 2^24.

What you're kinda describing would work as far as I understand what it
is you're trying to say. Along the same sort of arguments we can turn
this into a compression algorithm where we represent the whole entire
universe as the letter 'A'. The unfortunate part of this compression
algorithm is that when we want to uncompress it we go to our table,
look up what 'A' represents, and then output it. So we would still
have to store the universe in as a whole.

In other words it's terribly infeasible to have a database of all the
possible packet combinations up to 500 bytes.

On 06/07/07, Dan Becker <list@...nixsolutions.com> wrote:
> 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/
>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ