| 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
| ||
|
Date: Fri, 06 Jul 2007 12:40:29 +0200 From: Matjaz Debelak <killerx@...s-on.net> To: full-disclosure@...ts.grok.org.uk Subject: Re: Does this exist ? Yes, that is true, but if you read the original post, he wants to minimize the data transferred not the data stored/processed. I don't know if you want to transfer general traffic that way, but if you are only trying to transfer some special data/protocol it might be even possible to generate such a thing for all the plausible packages (if you know roughly what data will be "encoded")... LP Killer_X Fionnbharr wrote: > 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/ > _______________________________________________ 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