Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #350990 > unrolled thread
| Started by | owl <owl@rooftop.invalid> |
|---|---|
| First post | 2016-04-20 15:10 +0000 |
| Last post | 2016-04-21 16:26 +0000 |
| Articles | 20 on this page of 36 — 6 participants |
Back to article view | Back to comp.os.linux.advocacy
LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 15:10 +0000
Re: LOL underestimated vallor <vallor@cultnix.org> - 2016-04-20 16:55 +0000
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 17:25 +0000
Re: LOL underestimated vallor <vallor@cultnix.org> - 2016-04-20 18:45 +0000
Re: LOL underestimated vallor <vallor@cultnix.org> - 2016-04-20 18:47 +0000
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 21:05 +0000
Re: LOL underestimated vallor <vallor@cultnix.org> - 2016-04-25 19:07 +0000
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-25 21:16 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 20:51 +0200
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 19:19 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 17:34 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 20:31 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 21:13 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 23:20 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 21:29 +0000
Re: LOL underestimated Me Sham <osirus47@yahoo.com> - 2016-04-20 14:33 -0700
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 23:58 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 22:04 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 23:25 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 21:41 +0000
Re: LOL underestimated Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-20 23:50 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 22:06 +0000
Re: LOL underestimated Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-21 08:54 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-21 17:12 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 23:50 +0200
Re: LOL underestimated Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-20 23:51 +0200
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-20 23:59 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 22:10 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-21 00:11 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-20 22:19 +0000
Re: LOL underestimated Melzzzzz <mel@zzzzz.com> - 2016-04-21 00:57 +0200
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-21 00:07 +0000
Re: LOL underestimated DFS <nospam@dfs.com> - 2016-04-20 23:17 -0400
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-21 03:49 +0000
Re: LOL underestimated DFS <nospam@dfs.com> - 2016-04-21 10:27 -0400
Re: LOL underestimated owl <owl@rooftop.invalid> - 2016-04-21 16:26 +0000
Page 1 of 2 [1] 2 Next page →
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 15:10 +0000 |
| Subject | LOL underestimated |
| Message-ID | <fjgu003af.p4e@rooftop.invalid> |
Underestimated the time it would take. Probably about 90 days at this rate. LOL. Restarted the 200GB file write after starting a series of attacks on the problem space for a particular match. https://vid.me/9qwp They've been running all night and only about half way to flipping the first digit on the left part. It needs to flip 32 times before it's done. This is when you appreciate Linux uptime and X11 virtual desktops.
[toc] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2016-04-20 16:55 +0000 |
| Message-ID | <dnpqjfFf3j2U3@mid.individual.net> |
| In reply to | #350990 |
On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: > Underestimated the time it would take. Probably about 90 days at this > rate. LOL. Restarted the 200GB file write after starting a series of > attacks on the problem space for a particular match. > > https://vid.me/9qwp > > They've been running all night and only about half way to flipping the > first digit on the left part. It needs to flip 32 times before it's > done. > This is when you appreciate Linux uptime and X11 virtual desktops. Got GPU? https://github.com/xpn/CUDA-MD5-Crack -- -v "Desktops, workstations and servers are and Microsoft is doing very well. AS well as Linux." -"Slimer"
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 17:25 +0000 |
| Message-ID | <ghjdk90aafe.kgi@rooftop.invalid> |
| In reply to | #351014 |
vallor <vallor@cultnix.org> wrote: > On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: > >> Underestimated the time it would take. Probably about 90 days at this >> rate. LOL. Restarted the 200GB file write after starting a series of >> attacks on the problem space for a particular match. >> >> https://vid.me/9qwp >> >> They've been running all night and only about half way to flipping the >> first digit on the left part. It needs to flip 32 times before it's >> done. >> This is when you appreciate Linux uptime and X11 virtual desktops. > > Got GPU? > > https://github.com/xpn/CUDA-MD5-Crack > No NVIDIA here.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2016-04-20 18:45 +0000 |
| Message-ID | <dnq12vFf3j2U5@mid.individual.net> |
| In reply to | #351021 |
On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: > vallor <vallor@cultnix.org> wrote: >> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: >> >>> Underestimated the time it would take. Probably about 90 days at this >>> rate. LOL. Restarted the 200GB file write after starting a series of >>> attacks on the problem space for a particular match. >>> >>> https://vid.me/9qwp >>> >>> They've been running all night and only about half way to flipping the >>> first digit on the left part. It needs to flip 32 times before it's >>> done. >>> This is when you appreciate Linux uptime and X11 virtual desktops. >> >> Got GPU? >> >> https://github.com/xpn/CUDA-MD5-Crack >> >> > No NVIDIA here. Well, you might save yourself some time by getting one. ;P Or... http://www.nvidia.com/object/gpu-cloud-computing-services.html -- -v "Desktops, workstations and servers are and Microsoft is doing very well. AS well as Linux." -"Slimer"
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2016-04-20 18:47 +0000 |
| Message-ID | <dnq158Ff3j2U6@mid.individual.net> |
| In reply to | #351035 |
On Wed, 20 Apr 2016 18:45:51 +0000, vallor wrote: > On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: > >> vallor <vallor@cultnix.org> wrote: >>> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: >>> >>>> Underestimated the time it would take. Probably about 90 days at >>>> this rate. LOL. Restarted the 200GB file write after starting a >>>> series of attacks on the problem space for a particular match. >>>> >>>> https://vid.me/9qwp >>>> >>>> They've been running all night and only about half way to flipping >>>> the first digit on the left part. It needs to flip 32 times before >>>> it's done. >>>> This is when you appreciate Linux uptime and X11 virtual desktops. >>> >>> Got GPU? >>> >>> https://github.com/xpn/CUDA-MD5-Crack >>> >>> >> No NVIDIA here. > > Well, you might save yourself some time by getting one. ;P > > Or... > > http://www.nvidia.com/object/gpu-cloud-computing-services.html Well, assuming you don't have some other sort of GPU -- there's always OpenCL for ATI, I do believe. -- -v "Desktops, workstations and servers are and Microsoft is doing very well. AS well as Linux." -"Slimer"
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 21:05 +0000 |
| Message-ID | <hgji9a03f.a@rooftop.invalid> |
| In reply to | #351037 |
vallor <vallor@cultnix.org> wrote: > On Wed, 20 Apr 2016 18:45:51 +0000, vallor wrote: > >> On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: >> >>> vallor <vallor@cultnix.org> wrote: >>>> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: >>>> >>>>> Underestimated the time it would take. Probably about 90 days at >>>>> this rate. LOL. Restarted the 200GB file write after starting a >>>>> series of attacks on the problem space for a particular match. >>>>> >>>>> https://vid.me/9qwp >>>>> >>>>> They've been running all night and only about half way to flipping >>>>> the first digit on the left part. It needs to flip 32 times before >>>>> it's done. >>>>> This is when you appreciate Linux uptime and X11 virtual desktops. >>>> >>>> Got GPU? >>>> >>>> https://github.com/xpn/CUDA-MD5-Crack >>>> >>>> >>> No NVIDIA here. >> >> Well, you might save yourself some time by getting one. ;P >> >> Or... >> >> http://www.nvidia.com/object/gpu-cloud-computing-services.html > > Well, assuming you don't have some other sort of GPU -- there's always > OpenCL for ATI, I do believe. > That sounds cool, but I don't really want to spend any money.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2016-04-25 19:07 +0000 |
| Message-ID | <do7888FsmspU1@mid.individual.net> |
| In reply to | #351053 |
On Wed, 20 Apr 2016 21:05:50 +0000, owl wrote: > vallor <vallor@cultnix.org> wrote: >> On Wed, 20 Apr 2016 18:45:51 +0000, vallor wrote: >> >>> On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: >>> >>>> vallor <vallor@cultnix.org> wrote: >>>>> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: >>>>> >>>>>> Underestimated the time it would take. Probably about 90 days at >>>>>> this rate. LOL. Restarted the 200GB file write after starting a >>>>>> series of attacks on the problem space for a particular match. >>>>>> >>>>>> https://vid.me/9qwp >>>>>> >>>>>> They've been running all night and only about half way to flipping >>>>>> the first digit on the left part. It needs to flip 32 times before >>>>>> it's done. >>>>>> This is when you appreciate Linux uptime and X11 virtual desktops. >>>>> >>>>> Got GPU? >>>>> >>>>> https://github.com/xpn/CUDA-MD5-Crack >>>>> >>>>> >>>> No NVIDIA here. >>> >>> Well, you might save yourself some time by getting one. ;P >>> >>> Or... >>> >>> http://www.nvidia.com/object/gpu-cloud-computing-services.html >> >> Well, assuming you don't have some other sort of GPU -- there's always >> OpenCL for ATI, I do believe. >> >> > That sounds cool, but I don't really want to spend any money. How goes the cracking? Do you not have a GPU in your computer? Even the SIMD stuff in Intel HD graphics could help, if I'm not mistaken. -- -v "Desktops, workstations and servers are and Microsoft is doing very well. AS well as Linux." -"Slimer"
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-25 21:16 +0000 |
| Message-ID | <shjg303.aifr@rooftop.invalid> |
| In reply to | #351803 |
vallor <vallor@cultnix.org> wrote: > On Wed, 20 Apr 2016 21:05:50 +0000, owl wrote: > >> vallor <vallor@cultnix.org> wrote: >>> On Wed, 20 Apr 2016 18:45:51 +0000, vallor wrote: >>> >>>> On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: >>>> >>>>> vallor <vallor@cultnix.org> wrote: >>>>>> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: >>>>>> >>>>>>> Underestimated the time it would take. Probably about 90 days at >>>>>>> this rate. LOL. Restarted the 200GB file write after starting a >>>>>>> series of attacks on the problem space for a particular match. >>>>>>> >>>>>>> https://vid.me/9qwp >>>>>>> >>>>>>> They've been running all night and only about half way to flipping >>>>>>> the first digit on the left part. It needs to flip 32 times before >>>>>>> it's done. >>>>>>> This is when you appreciate Linux uptime and X11 virtual desktops. >>>>>> >>>>>> Got GPU? >>>>>> >>>>>> https://github.com/xpn/CUDA-MD5-Crack >>>>>> >>>>>> >>>>> No NVIDIA here. >>>> >>>> Well, you might save yourself some time by getting one. ;P >>>> >>>> Or... >>>> >>>> http://www.nvidia.com/object/gpu-cloud-computing-services.html >>> >>> Well, assuming you don't have some other sort of GPU -- there's always >>> OpenCL for ATI, I do believe. >>> >>> >> That sounds cool, but I don't really want to spend any money. > > How goes the cracking? > > Do you not have a GPU in your computer? Even the SIMD stuff in Intel HD > graphics could help, if I'm not mistaken. > Actually, I had turned it off after a couple days. Your post made me take a look at it again, and I modified the way I'm running it. Now getting 3500-3800 results per second, versus previous 500 per sec. So it should be doable in a couple weeks vs the original 90 day estimate. I'll let it run for a bit and see if running count jibes with estimate.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 20:51 +0200 |
| Message-ID | <20160420205154.123a3808@maxa-pc> |
| In reply to | #351035 |
On 20 Apr 2016 18:45:51 GMT vallor <vallor@cultnix.org> wrote: > On Wed, 20 Apr 2016 17:25:14 +0000, owl wrote: > > > vallor <vallor@cultnix.org> wrote: > >> On Wed, 20 Apr 2016 15:10:00 +0000, owl wrote: > >> > >>> Underestimated the time it would take. Probably about 90 days at > >>> this rate. LOL. Restarted the 200GB file write after starting a > >>> series of attacks on the problem space for a particular match. > >>> > >>> https://vid.me/9qwp > >>> > >>> They've been running all night and only about half way to > >>> flipping the first digit on the left part. It needs to flip 32 > >>> times before it's done. > >>> This is when you appreciate Linux uptime and X11 virtual > >>> desktops. > >> > >> Got GPU? > >> > >> https://github.com/xpn/CUDA-MD5-Crack > >> > >> > > No NVIDIA here. > > Well, you might save yourself some time by getting one. ;P Hm AMD was better for bitcoin mining, and that's about computing hashes...
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 19:19 +0200 |
| Message-ID | <20160420191915.3cf2c768@maxa-pc> |
| In reply to | #350990 |
On Wed, 20 Apr 2016 15:10:00 +0000 (UTC) owl <owl@rooftop.invalid> wrote: > Underestimated the time it would take. Probably about 90 days at this > rate. LOL. Restarted the 200GB file write after starting a series of > attacks on the problem space for a particular match. > > https://vid.me/9qwp > > They've been running all night and only about half way to flipping the > first digit on the left part. It needs to flip 32 times before it's > done. This is when you appreciate Linux uptime and X11 virtual > desktops. > What are you trying to do?
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 17:34 +0000 |
| Message-ID | <fhjgda03.af3@rooftop.invalid> |
| In reply to | #351020 |
Melzzzzz <mel@zzzzz.com> wrote: > On Wed, 20 Apr 2016 15:10:00 +0000 (UTC) > owl <owl@rooftop.invalid> wrote: > >> Underestimated the time it would take. Probably about 90 days at this >> rate. LOL. Restarted the 200GB file write after starting a series of >> attacks on the problem space for a particular match. >> >> https://vid.me/9qwp >> >> They've been running all night and only about half way to flipping the >> first digit on the left part. It needs to flip 32 times before it's >> done. This is when you appreciate Linux uptime and X11 virtual >> desktops. >> > > What are you trying to do? At least some eternal-september posts have an Injection-Info header, part of which consists of a "posting-host" string that appears to be an md5 hash. I'm working on the assumption that it is a direct hash of a dotted quad IP address (could very well a bogus assumption). So, I am creating an md5 lookup table for all IPv4 addresses. That will take several months to create what will be about 200GB file in the format I'm using: anon@lowtide:~$ head /media/anon/5331134e-f853-4f49-876b-863d26af6261/out 1.1.1.1 a56bdbb2cc577c3eb01b8575c9241d51 - 1.1.1.2 d79e1566ae16cc3ab5060b74df13c9a4 - 1.1.1.3 117786110e867993f7d584b6097f2203 - 1.1.1.4 254e7213914e76fa50811e5fd46e5dc5 - 1.1.1.5 954b258b29028c2c250ecd3dd7b0c5da - progress far (since last night): anon@lowtide:~$ tail /media/anon/5331134e-f853-4f49-876b-863d26af6261/out 1.173.19.22 0986c814c63feea0933437ef5de7a6a8 - 1.173.19.23 fb59ae6da90786e4d0ae256bdf6703b0 - 1.173.19.24 216a58bb2825f4c4cdeaf4e3c6fddce7 - 1.173.19.25 87fe5a2b16d563265e9ec881994533c5 - 1.173.19.26 924e64c48cadbe4133c646f698eca4a2 - anon@lowtide:~$ I'm simultaneously running an attack on a particular hash over the entire address space (those eight small windows in the vid).
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 20:31 +0200 |
| Message-ID | <20160420203110.1b2edf85@maxa-pc> |
| In reply to | #351022 |
On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) owl <owl@rooftop.invalid> wrote: > > I'm simultaneously running an attack on a particular hash over the > entire address space (those eight small windows in the vid). > https://eprint.iacr.org/2006/105 Tunnels in Hash Functions: MD5 Collisions Within a Minute
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 21:13 +0000 |
| Message-ID | <ghdmjbd.lo3@rooftop.invalid> |
| In reply to | #351029 |
Melzzzzz <mel@zzzzz.com> wrote: > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) > owl <owl@rooftop.invalid> wrote: > >> >> I'm simultaneously running an attack on a particular hash over the >> entire address space (those eight small windows in the vid). >> > > https://eprint.iacr.org/2006/105 > Tunnels in Hash Functions: MD5 Collisions Within a Minute Unless I'm misunderstanding things, that's just generating collision pairs. Correct me if I'm wrong, but I assume that all attacks against a hash still require a dictionary of hashes (which is what I'm generating).
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 23:20 +0200 |
| Message-ID | <20160420232012.7027be06@maxa-pc> |
| In reply to | #351056 |
On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) owl <owl@rooftop.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) > > owl <owl@rooftop.invalid> wrote: > > > >> > >> I'm simultaneously running an attack on a particular hash over the > >> entire address space (those eight small windows in the vid). > >> > > > > https://eprint.iacr.org/2006/105 > > Tunnels in Hash Functions: MD5 Collisions Within a Minute > > Unless I'm misunderstanding things, that's just generating collision > pairs. Correct me if I'm wrong, but I assume that all attacks > against a hash still require a dictionary of hashes (which is what > I'm generating). > This paper I got earlier, it's about cracking md5 quickly. It should help your cause ;)
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 21:29 +0000 |
| Message-ID | <ghjdie003.afp4@rooftop.invalid> |
| In reply to | #351059 |
Melzzzzz <mel@zzzzz.com> wrote: > On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) > owl <owl@rooftop.invalid> wrote: > >> Melzzzzz <mel@zzzzz.com> wrote: >> > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) >> > owl <owl@rooftop.invalid> wrote: >> > >> >> >> >> I'm simultaneously running an attack on a particular hash over the >> >> entire address space (those eight small windows in the vid). >> >> >> > >> > https://eprint.iacr.org/2006/105 >> > Tunnels in Hash Functions: MD5 Collisions Within a Minute >> >> Unless I'm misunderstanding things, that's just generating collision >> pairs. Correct me if I'm wrong, but I assume that all attacks >> against a hash still require a dictionary of hashes (which is what >> I'm generating). >> > > This paper I got earlier, it's about cracking md5 quickly. It should > help your cause ;) > Are you sure? I skimmed it, and it seems to be proof of concept of quickly generating md5 collisions, which just means two data which generate the same hash, which makes md5 unreliable for verifying data integrity. But here I need to find the unknown original input that was hashed, given only the hash. Is there another method other than brute force dictionary comparison of hashes to find original input to an md5 hash? Does this paper describe such a method?
[toc] | [prev] | [next] | [standalone]
| From | Me Sham <osirus47@yahoo.com> |
|---|---|
| Date | 2016-04-20 14:33 -0700 |
| Message-ID | <21340349-1215-4478-adb6-4950ad82b948@googlegroups.com> |
| In reply to | #351061 |
On Wednesday, April 20, 2016 at 4:30:02 PM UTC-5, owl wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) > > owl <owl@rooftop.invalid> wrote: > > > >> Melzzzzz <mel@zzzzz.com> wrote: > >> > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) > >> > owl <owl@rooftop.invalid> wrote: > >> > > >> >> > >> >> I'm simultaneously running an attack on a particular hash over the > >> >> entire address space (those eight small windows in the vid). > >> >> > >> > > >> > https://eprint.iacr.org/2006/105 > >> > Tunnels in Hash Functions: MD5 Collisions Within a Minute > >> > >> Unless I'm misunderstanding things, that's just generating collision > >> pairs. Correct me if I'm wrong, but I assume that all attacks > >> against a hash still require a dictionary of hashes (which is what > >> I'm generating). > >> > > > > This paper I got earlier, it's about cracking md5 quickly. It should > > help your cause ;) > > > > Are you sure? I skimmed it, and it seems to be proof of concept of > quickly generating md5 collisions, which just means two data which > generate the same hash, which makes md5 unreliable for verifying > data integrity. But here I need to find the unknown original input > that was hashed, given only the hash. Is there another method other > than brute force dictionary comparison of hashes to find original > input to an md5 hash? Does this paper describe such a method? You can't reverse a hash. MD5 output is only 128-bit, but its inputs can be any length, which means for every hash output K there exists an infinite number of inputs P such that hash(P) = K.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 23:58 +0200 |
| Message-ID | <20160420235843.6a42f107@maxa-pc> |
| In reply to | #351062 |
On Wed, 20 Apr 2016 14:33:45 -0700 (PDT) Me Sham <osirus47@yahoo.com> wrote: > On Wednesday, April 20, 2016 at 4:30:02 PM UTC-5, owl wrote: > > Melzzzzz <mel@zzzzz.com> wrote: > > > On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) > > > owl <owl@rooftop.invalid> wrote: > > > > > >> Melzzzzz <mel@zzzzz.com> wrote: > > >> > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) > > >> > owl <owl@rooftop.invalid> wrote: > > >> > > > >> >> > > >> >> I'm simultaneously running an attack on a particular hash > > >> >> over the entire address space (those eight small windows in > > >> >> the vid). > > >> > > > >> > https://eprint.iacr.org/2006/105 > > >> > Tunnels in Hash Functions: MD5 Collisions Within a Minute > > >> > > >> Unless I'm misunderstanding things, that's just generating > > >> collision pairs. Correct me if I'm wrong, but I assume that all > > >> attacks against a hash still require a dictionary of hashes > > >> (which is what I'm generating). > > >> > > > > > > This paper I got earlier, it's about cracking md5 quickly. It > > > should help your cause ;) > > > > > > > Are you sure? I skimmed it, and it seems to be proof of concept of > > quickly generating md5 collisions, which just means two data which > > generate the same hash, which makes md5 unreliable for verifying > > data integrity. But here I need to find the unknown original input > > that was hashed, given only the hash. Is there another method other > > than brute force dictionary comparison of hashes to find original > > input to an md5 hash? Does this paper describe such a method? > > You can't reverse a hash. MD5 output is only 128-bit, but its inputs > can be any length, which means for every hash output K there exists > an infinite number of inputs P such that hash(P) = K. While there is infinite number of variable length inputs there is limited number of inputs of length n.
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 22:04 +0000 |
| Message-ID | <hgjdi03afa3.441@rooftop.invalid> |
| In reply to | #351062 |
Me Sham <osirus47@yahoo.com> wrote: > On Wednesday, April 20, 2016 at 4:30:02 PM UTC-5, owl wrote: >> Melzzzzz <mel@zzzzz.com> wrote: >> > On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) >> > owl <owl@rooftop.invalid> wrote: >> > >> >> Melzzzzz <mel@zzzzz.com> wrote: >> >> > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) >> >> > owl <owl@rooftop.invalid> wrote: >> >> > >> >> >> >> >> >> I'm simultaneously running an attack on a particular hash over the >> >> >> entire address space (those eight small windows in the vid). >> >> >> >> >> > >> >> > https://eprint.iacr.org/2006/105 >> >> > Tunnels in Hash Functions: MD5 Collisions Within a Minute >> >> >> >> Unless I'm misunderstanding things, that's just generating collision >> >> pairs. Correct me if I'm wrong, but I assume that all attacks >> >> against a hash still require a dictionary of hashes (which is what >> >> I'm generating). >> >> >> > >> > This paper I got earlier, it's about cracking md5 quickly. It should >> > help your cause ;) >> > >> >> Are you sure? I skimmed it, and it seems to be proof of concept of >> quickly generating md5 collisions, which just means two data which >> generate the same hash, which makes md5 unreliable for verifying >> data integrity. But here I need to find the unknown original input >> that was hashed, given only the hash. Is there another method other >> than brute force dictionary comparison of hashes to find original >> input to an md5 hash? Does this paper describe such a method? > > You can't reverse a hash. MD5 output is only 128-bit, but its inputs can be any length, which means for every hash output K there exists an infinite number of inputs P such that hash(P) = K. I know it's one-way. That's why I'm questioning this collision generator as being applicable to my problem of having a known hash and wanting to find the original data that was hashed. Here I'm making an educated guess that the original data is an IP address, and I've decided to generate a hash table of the IPv4 address space, which even though relatively large, is doable in a couple of months on my machine.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-04-20 23:25 +0200 |
| Message-ID | <20160420232546.4804cf6f@maxa-pc> |
| In reply to | #351056 |
On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) owl <owl@rooftop.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) > > owl <owl@rooftop.invalid> wrote: > > > >> > >> I'm simultaneously running an attack on a particular hash over the > >> entire address space (those eight small windows in the vid). > >> > > > > https://eprint.iacr.org/2006/105 > > Tunnels in Hash Functions: MD5 Collisions Within a Minute > > Unless I'm misunderstanding things, that's just generating collision > pairs. Correct me if I'm wrong, but I assume that all attacks > against a hash still require a dictionary of hashes (which is what > I'm generating). > If you find collision of particular length, you have probable solution...
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-20 21:41 +0000 |
| Message-ID | <ghjmbnjc03.are@rooftop.invalid> |
| In reply to | #351060 |
Melzzzzz <mel@zzzzz.com> wrote: > On Wed, 20 Apr 2016 21:13:16 +0000 (UTC) > owl <owl@rooftop.invalid> wrote: > >> Melzzzzz <mel@zzzzz.com> wrote: >> > On Wed, 20 Apr 2016 17:34:37 +0000 (UTC) >> > owl <owl@rooftop.invalid> wrote: >> > >> >> >> >> I'm simultaneously running an attack on a particular hash over the >> >> entire address space (those eight small windows in the vid). >> >> >> > >> > https://eprint.iacr.org/2006/105 >> > Tunnels in Hash Functions: MD5 Collisions Within a Minute >> >> Unless I'm misunderstanding things, that's just generating collision >> pairs. Correct me if I'm wrong, but I assume that all attacks >> against a hash still require a dictionary of hashes (which is what >> I'm generating). >> > > If you find collision of particular length, you have probable > solution... Length of what? Can you give me a layman's executive summary of how the described approach can reveal the original input given only the known hash?
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web