I've been tinkering with Python all day today... it's pretty slick. Just for practice, I tried to cobble together a tripcode decoder that would let you have "real" words in your tripcode as !WAHa and Sling and others do, and it actually came out better than I thought it would be. I'm aware there's already a program that does this, but if memory serves me, it's Windows-only and in Japanese besides. My script is kind of dumb in the way it goes about things -- it basically just tears through random strings until it finds one that fits -- but I've tested it repeatedly and it seems to work. If you'd like to check it out, nab it here:
http://www.anre.org/crap/detripper.bz2
Of course, you may need to modify the hashbang line depending on where Python is on your machine, and don't forget those execute bits, people... Use "-h" for help.
First person to ask how to get this to run on Windows gets pointed and laughed at.
>>96
Added optional case insensitive mode and optional searching of strings in the whole string.
test
another board bug.
tripcode passwords with # are allowed, ex:
lame#tes#tes
name lame, trip #tes#tes
(by proper 2ch)
if you're the developer of this software, after reading that reply all i have to say at this point is go fuck yourself.
>>104
lol my tripcode password is '####' and it works here...
I saw you complaining on 4chan, and now you're complaining in here. Nobody cares that your customized hyper-special customized tripcodes don't work right, as secure tripcodes are in fact a useful feature.
hint: !
itt you have a stupid tripcode
sup
lol, fag.
see the difference is it works on 2ch, so i kind of expect it to work here too.
Well since you articulate your sentiments so eloquently, let me just remove this feature that people enjoy and use so you can think you're on another site, how about that?
the fuck what?
Not too bright, are you? Now get the fuck out of this thread already.
By request, I wrote a dictionary generator. It needs a system with fgetln(), though. Porting to glibc and getline() wouldn't be too hard, but I'm not interested enough.
Same URL as always.
>>116 typical whiteboy nerd pretending to be a jap while masturbating to shitty anime.
Oh come on, that's pathetic. Surely you can do better than THAT. Try again.
oh timecop-chan -_-
ID:gLTSfIiG
Does anyone think getting Tripper+ translated into English would be useful? 'Cause I'm working on it some, though I don't know any Japanese.
>Name: !WAHa.06x36 2004-11-15 14:22
>I've used some assembly-optimized crypt() code from John the Ripper to get up to 110000 crypts per second per gigahertz.
out of curiosity, was that in a "finding a cute tripstring" (wild discovery) or a "breaking some trips" (targeted discovery) context?
also, was it with the "normal" or the "bitslice" code from john?
and, was it done by cramming a tripcode-format specification into john, or by transplanting john crypto into a tripcode-specific framework?
I'm not too familiar with what the "bitslice" and "normal" code is. What I did was take the version of the DES code that generates results that are padded and out-of-order, and transformed those back to the normal format in base64, and used that to make a small utility that searched for specific substrings and output them. Even with the overhead of the conversion, it was nearly twice the speed of any other DES code. If I was trying to crack specific tripcodes, I could do the conversion in the other direction just once and make it even faster, but I didn't find that very interesting.
So, wild discovery, and using the john code in my own program.
>>126
ah, interesting.
that sounds very much like you used the bitslice code, the output is 64bit binary there, does not include the salt, and it looked like converting it back would be possible.
"bitslicing" is class III vooodoo that treats one N-bit CPU like N 1-bit CPUs. john has a (already somewhat optimized) "normal" DES implemtation (that generates 128bit output with the salt mangeled in), and a even more insane bitslice one that does 32 or 64 crypt()-like operations "in parallel".
some stats, 1GHz athlon, custom framework (based on 4brute.c) doing targeted discovery on about 4k targets, kcps == kilo crypt()-equivalent-operations per second, including comparison, and measured against process user-time (not wallclock. so its equivalent to johns "virtual" rate.):
'John 1.6.38 / 64/64 BS MMX' => 279kcps (this is the "bitslice" version)
'OpenSSL 0.9.7e 25 Oct 2004' => 71kcps
'John 1.6.38 / 48/64 4K MMX' => 64kcps (this is the "normal" one)
'UFC-crypt 1c, 1.9 03/02/92' => 37kcps
'glibc2.3.4 slackware crypt' => 30kcps
this session taught me some things i didnt really expect:
1) forget ufc-crypt unless you have prehistoric hardware.
2) openssl fcrypt() is a very good starting point.
3) at 279kcps, the framework spends 10-15% of the cputime on generating the next input plaintext and comparing output against targets. and that is after some serious optimization in those areas. was more like 60% before that.
How were you choosing the salt on those? Some algorithms take a big performance hit every time you change the salt, so to get them to perform well, you want to arrange your lookups to do many lookups with the same salt in a row.
for the bitslice code to be really useful i had to run it on N sets with the same salt at once, which in case of the odd "salt derived from plaintext" tripcodes made me buffer up candidate-plaintexts mapping to the same salt, only activating the real backend when a salt-bank is full.
in case of john-bitslice the banksize is 64 (didnt have much choice there), for all other backends i was using 128 (thats the "max keys per crypt" johns non-bitslice des code was using).
(exception to the "only fire full banks" is the "endgame" phase when the plaintext-generator says "i am done" and there are partially full banks to purge, but that is pretty much irrelevant for the total performance on a run of several Mcrypt().)
as a sidenote, openssl performance seem to be the same even with not-sorted-by-salt use, but i guess it just initializes by salt every time, even if you pass it the same one again on next call.
Searching through: 0123456789abcdef
Number of users scanned: 4129
...
Exiting after 4581298448 crypt, 35442 inner, 71582993 salts, 22 found
'John 1.6.38 / 64/64 BS MMX' => Real: 26626s, 172kcps
'John 1.6.38 / 64/64 BS MMX' => Virt: 18416s, 248kcps
that was on a duron900 that does a lot of other things all the time.
4.3 Gcrypt run through the bitslice code, changing salts 68M times.
35442 fcrypt() run through openssl in response to the john-crypt giving a 29bit confidence match, 22 actually were full matches.
35420 openssl fcrypt() "wasted" sounds like much, until you realize its (even assuming a worst-case with some swapping) still less than 2 seconds total on a 7hour+ run, so i dont give a damn.
68M salt-changes also sounds like much, but profiling said its responsible for less than 3% of the cpuload, so again i dont give a damn.
so, i couldnt help myself and wasted even more time on it.
here some more highly unrepresentative stats of different systems, all using the john-bitslice code:
Penti-M 1600MHz 1024kB 526kcps 328cpspMHz
Duron 895MHz 64kB 248kcps 277cpspMHz
Athlon 1009MHz 256kB 279kcps 276cpspMHz
Pentium 233MHz 52kcps 223cpspMHz
Penti-4 2000MHz 512kB 406kcps 203cpspMHz
Celeron 2400MHz 256kB 436kcps 181cpspMHz
3rd column is second level cache size.
4th is raw "kilo-crypt() per second", virtual.
5th is "crypt() per second per MHz"
the insanely high score of the Pentium M, and the insanely low ones for the Pentium4 and P4Celeron indicate that version of the code was working on data-sets between 512kB and 1MB.
the Duron with the tiny cache scoring second seemed odd, but if i am trashing through the whole cache anyways, second-most-important feature is ram speed, and that machine is using dual-port DDR.
the pentium 233 using johnbs pushing almost twice the crypt()s the athlon1000 did with UFC amused me. unless i was using some kind of "wrong (version of) UFC", it seems that optimizations done 13+ years ago do not consider modern hardware. shocking.
(so unless you are running a cracking cluster with 15 year old RISC machines, dont bother with UFC)
did some improvements in the comparison framework to reduce the activity-relevant ramsize, in particular some lookup tables where i traded ram for speed earlier, got me another 10% or so, depending on the cachesize. trying this on the 512kB machine is still pending, this will be most interesting, i dont think i got it small enough for the 256kB cache to be enough. (thats where i am seeing 5-10% improvement, depending on how many targets i feed it.)
regarding dictionary generators, i found there is little need to write any, since john has a -stdout option. very handy.
even without any wordlists, just using character-probability/distribution lists and making up words, this is far more effective than the raw bruteforce tries 4brute implements.
the benchmarking-list is about 6800 tripcodes grabbed from various boards, and using "john -i -stdout | 4brute-johnbs -i", 1GHz of cpu find solutions for more than 1000 of those within a minute.
but to not just be a smelly-creepy cracker, i did some work in the direction of wild-discovery ("searching for cute tripcodes"), but without reversing the output of johns code. example, i want to find something beginning with a certain 4-5 char prefix, like /^waha\W/i ... which is just 32 different prefixes after all, upper-and-lowercase combinations for the four letters plus . or / behind it. at the same time, those 5 chars are 30bit worth of target, 5bit (32 strings) of which are considered "hits". so, i mongled the matching code in a way that allows it to just match prefixes, and handed it a list of those 32 possible prefixes i might like as targets. plus "random starting point of 8 char length" as input.
assuming an even distribution, the 30-5 bit suggest i should find a solution about every 33.5 million attempts. here output from a run of ~350 Million tries:
4brute using 'John 1.6.38 / 64/64 BS MMX'
Starting search from "sG+ym_8u"
Limit set to: 350000000
Searching through (randomised): ucWZXdw(P]Eb2gC_I7[/Q3MFKS$G`N}yql0jTm!Yz +UJa#5r89eh*D-:Ais)fOHtBRpvL.1x{k6V4no
Number of users scanned: 32
"WahA.DY8KI" == Gx "3Gxwm_8u" for WahA.aaaaa
"wAha.RNmpE" == .. "_}!Qu_8u" for wAha.aaaaa
"WaHA/D5Jq." == cY "j]Y0u_8u" for WaHA/aaaaa
"wAHA/GeRU." == R8 "NR8vu_8u" for wAHA/aaaaa
"WahA.7NzhI" == 9d "w9d{u_8u" for WahA.aaaaa
"WaHA/GE/Ng" == MU "hMU3c_8u" for WaHA/aaaaa
"WAhA.S/aOs" == bO "AbOac_8u" for WAhA.aaaaa
"wAHa/HPJco" == GC "KGC8c_8u" for wAHa/aaaaa
"WAhA.EyH8c" == l2 "ll2jX_8u" for WAhA.aaaaa
"WAhA/5Fmuw" == hC "+hCWd_8u" for WAhA/aaaaa
"Waha.D1AzY" == .M "G-MWd_8u" for Waha.aaaaa
"WAhA.2piT6" == K9 "LK9_d_8u" for WAhA.aaaaa
"WaHa/0qPHI" == xl "hxl7w_8u" for WaHa/aaaaa
"wAHA.jhgAw" == .x "x-xF(_8u" for wAHA.aaaaa
Exiting after 350059520 crypt, 14 inner, 4267664 salts, 14 found
'John 1.6.38 / 64/64 BS MMX' => Real: 1513s, 231kcps
'John 1.6.38 / 64/64 BS MMX' => Virt: 1308s, 267kcps
so, 25 minutes for finding 14 solutions. the 14 here is above average, i had other runs that coughed up only 8 hits in 350M tries. this run was on my trusty duron900 again, and as the difference between the "real" and "virtual" time indicates, 4brute only got about 85% of the cpu during the time.
I am your arch nemesis!
I updated my code again, now it compiles on Cygwin because I wrote my own strcasestr()!
In the process, I discovered a gcc optimization bug, but it doesn't cause miscompilation so it's not that bad.
Also, I think that at one point I tried dropping in hotaru's ufcrypt to replace the rather slow one I'm using, and it gave different (wrong) results for some tripcodes.
i've been playing around with the bitslice code from john the ripper... and i'm wondering... how the heck do i get a normal hash out of it? i see DES_bs_get_hash() returns an int, and i'm guessing i probably want to do something with that, but i have no idea what...
What John does is take a hash, and turn it into a bitslice, and then compares the bitslices. That's the faster way, but for searching for strings in tripcodes, you need the hash. What you do is take the algorithm for changing a hash to a bitslice and invert it.
>take the algorithm for changing a hash to a bitslice and invert it.
i don't think i can do that...
i updated mine...
i fixed it so it doesn't crash after a few minutes of searching now... and i made some other changes... i tried dropping in openssl's fcrypt(), but it gave wrong results and i don't really feel like trying to figure out what's wrong with it right now, so i'm still using ufc-crypt...
same url as before...
>>127
Can you please provide source code for your test application?
Anders
>>138
hotaru, your site doesn't work, can you put your code on another host or email it to me ([email protected]) ?
anders
>>138
Actually, the site does work, just not the .tar.gz links... If you can make these available somehow I'd be glad.
Anders
How do I get this to run on Windows? It's not working.
I'd really rather people did not link to programs for doing cracking of actual tripcodes. It's a fun academic exercise, but there's no legitimate use for those.
i didn't figure out how to use john's crypt(), tried linking the object with my code then changing the calls...
anyone who got 4brute.c compiling btw?
i get:
anders@home:~$ gcc -O3 -o 4brute 4brute.c -lssl
4brute.c:65: error: syntax error before '(' token
4brute.c:65: error: syntax error before 'const'
Eh, I should remove that one too. It got left behind back in the day.
i fixed the 4brute/4tripper source
>>147
seconded
>>25
http://4dist.yi.org/4cute
but, of course, "there's no legitimate use" for this.
note that 4cute is just a quickly slapped-together CGI frontend for a souped-up 4brute that is pretty much unchanged since the link to it got deleted here for being "evil" two days ago.
(i did add a "exit after finding N solutions" commandlineoption, fixed some typos, added two things to the Usage() output, and shuffled around some defines. which are not exactly any changes to the main functionality, just touching up code i had not open in an editor for some weeks.)
No need to be ironic, you know damn well what I meant earlier.
>>152
Of course there is need to be ironic about something like this.
Thats way better than me being pissed off about it.
4cute is a proof-of-concept frontend, obviously designing userinterfaces is not my strong point.
and of course its keeping a local copy of the results, in the very same format used by 4dist, so i dont end up wasting cputime on cracking 8char cutetrips i supplied myself.
of course, anyone interested and having a x86 mmx cpu could just go grab the source, and waste their own cpu cycles on generating whatever amount of cutetrips they want.
if they were allowed to know where the source is.
not that it is hard to find without the direct link.
which just confirms again that "no legitimate use" is not exactly true, and deleting the link is pretty pointless.
You are wilfully misinterpreting what I said (I am being generous here and not assuming you are too dumb to read what I said). I said, and I quote, "I'd really rather people did not link to programs for doing cracking of actual tripcodes." Your 4cute does not do that, and has nothing to do with the discussion. It seems to do much the same as anything else in this discussion, none of which I had a problem with. Why are you assuming I'd have a problem with yours if I didn't with everybody else's?
>>154
its the very same program you deleted the link to, with your little "no legitimate use" comment.
just run from a perl CGI that feeds it with four commandline options, and wraps its output in some html.
so either there is a legitimate use for 4brute, or 4cute isnt one either.
cant have it both ways.
I never said there weren't legitimate uses for your program, I said there was no legitimate use for cracking tripcodes. I understand your program does that, which is why I didn't want a link to it. All you'd be doing is supplying script kiddies with tools. Make a version that doesn't do that, and I won't mind you linking it.
And how is that supposed to work?
ship it with a "complete" list of "known to be used" tripcodes and make it not output these? yeah, right.
include an AI that evaluates cuteness rating of supplied targets? sure.
of course, in any case of "exit_if_not_political_correct_target();" or other artificial "policy" limits, i would have to start shipping it closed source too.
because else people might comment out that call.
4brute generates plaintexts (or reads them from a pipe), crypt()s them in a tripcode way, and compares the results.
how is it supposed to know what are "good" or "bad" targets for a comparison?
if i take any of the "good" tripcode generators in this thread, tell it to use an alphanumeric charset, begin with one char length and rotate-enlarge, and run it to find me stuff that matches /^WAHa\./, how long would it take to find !WAHa.06x36 ?
seriously, whats the difference between a "bad_cracker" and a "good_generator | grep" ?
How many people do you see using Tripper++ for cracking? It just doesn't work, because it only uses randomized long strings for input. It also has no facilities for doing birthday attacks.
>>158
... which of course only works because its a closed-source GUI-thing?
better delete those links to "Mr VacBob"s tools too, those are evil opensource commandline hackery.
oh, and either you dont understand what a "birthday attack" is or you are assuming i dont know and want to confuse me by using the term? because i fail to see how an "any to any" attack with free choice of targets is related to the current topic.
i repeat: whats the difference between a "bad_cracker" and a "good_generator | grep" ?
Birthday attack in the sense of having many targets. Not entirely correct usage, I guess, but eh.
And stop trying to pick a fight, OK? There's a pretty obvious difference between making a tool that can be used out-of-the-box for cracking tripcodes, and one that can be modified to do it with some work. If you're a good enough programmer to modify it, chances are you could make it from scratch anyway.
Of course, releasing something that is a lot faster than all the others is a bit of a problem, since most people wouldn't develop that on their own. You may have noticed I did a lot of the same as you did, but chose not to release it because it didn't feel it was for the common good.
Now for some less faggy discussion:
I noticed your code said it was comparing against 32 candidates to do a case-insensitve match for 5 characters. I don't remember exactly how the bitslice data was laid out, so I am not enitrely sure it would work, but I'd think you'd get away much easier with a single bitmasked comparison.
>>160
I strongly disagree. Even if it does use UFC crypt() or John's bitslice stuff, the legitimacy is the same... It's just faster.
>>160
actualy, due to the "first character of crypt output cut off" aspect of tripcodes, you could in theory do a birthday-style attack on it, to find a pair of plaintexts that result in the same tripcode.
and if i make you use one of those, i could post with the other.
too bad no one would realize what clever hackish thing i have done, so they wont give me head for it, so its pointless. ;)
>>161
my comparison is doing a two-layered hashed check, then a full recheck using openssl.
meaning:
first it grabs 12-16 bit (a #define, actualy, thats one of the things i changed yesterday) of the bitslice output, and looks it up in a table.
and only if it has any targets in that table-slot it fetches another 16-20 bit (well, 32-$firstmatch) bit, and compares those to the targets in the slot discovered in step one.
and if there is a match in this step, it runs openssl on the plaintext, and compares it char by char to the may-be-a-match.
sounds bad?
Exiting after 1000000485 crypt, 565 inner, 41 salts, 0 found
565 times it hit the openssl inner-stage comparison, and none of it was a true match. gasp
but wait, openssl does more than 70000 crypt per second on this hardware, so its ... even assuming a 2x overhead for it not being in cpu cache or whatever, its less than 200ms of a 1 Gcrypt() batch taking more than an hour total. so its pretty insignificant.
in exchange, the comparison doesnt really slow down even with a lot of match targets. the default target limit is set to 4096, and the mask for stage 1 to 16 bit. that gives me a nice 1:16 rate of its-not-a-match detection right in the first stage.
it could even be scaled up quite a bit (at least to 24 bit, and an equally increased maxtargs), but at that point the ram footprint grows and grows and grows, and since i am allocating all the lookup tables statically...
how is that relevant for the case-insensitive comparison? a 5-char-alpha case-insensitive prefix has 32 possible variants. instead of doing that 1:32 step in the comparison stage for every single of the very many tried crypt()s, i do it before even firing up the crypter, by generating all those possible 32 targets.
what? two of the chars have l33tmode alternatives? thats 72 variants. scary.
what? you want only 4-char case-insensitive alpha prefix? that means full 64 options for char5, giving 1024 variants. bring it on.
oh, i forgot. for matching 5char prefixes, i only have 30bit at all to match, so the stage-2 comparison has 4x less reliability. but, of course thats nonsense, because if all 30 bits match, its a match in stage-3 for sure.
the "where are the bits hiding in johns format" for the individual tripchars is in 4brute-johnbs.h ... those defines are not used anywhere, but i kept them there just in case i ever need them again. it does not say which bit is which, so figuring out which one to ignore for case-insensitive direct matching would be another run of "see which bit flips".
i prefer the current system that stands up to whatever the user may throw at it, even if its leet-mode substitutions, which would be moderately hard to do bitmasked.
rethinks ... aeh, and since we are matching base64 targets here, it wont really work at all, because case-insensitive bitmatching works with ascii, but not base64.
but the idea was good! :)
>>162
would SOMEONE please run benchmarks comparing UFC and openssl crypt() speed?
and by someone, i dont mean me, and not anyone using my code?
my benchmarks (somewhere earlier in this thread) indicated that UFC was really, really bad.
it may have had a point in 1992 (when it was last updated) on 30MHz RISC machines, but i really, really fail to see any use for it today.
but, who knows, perhaps i did something really wrong, or was using an outdated variant, or whatever.
so, please, someone do some benchmarking.
and i dont mean the benchmark included in ufc, because that compares ufc against the libc crypt(), which indeed is the only thing worse than UFC in my tests.
well, or use the benchmark in ufc, and cram in the openssl crypt() so it uses the same framework for testing.
> aeh, and since we are matching base64 targets here, it wont really work at all, because case-insensitive bitmatching works with ascii, but not base64.
Ah, damn, that's right. Oh well!
>>141
my code is at http://hotaru.freelinuxhost.com/fasttrip.tar.bz2 now
>>164
I did some testing on a Pentium M with 1.6GHz. Time for 5,000,000 iterations, changing the salt every 500,000 iterations:
OpenSSL DES_crypt(): 45.144s
UFC-crypt crypt(): 37.078s
>>169
interesting. can i get the code you used somewhere?
i just did some benchmarking again too, not using the sodomized 4brute as framework, but the "speeds.c" that comes with ufc. runs the crypt() for 10sec cpu time, reports number of done cycles. no saltchanges at all. it has defines for ufc and libc, i added a ossl variant.
Results from my trusty Duron900 (64kB cache):
code here: http://4dist.yi.org/misc/ufc-crypt/
the speeds.c and Makefile are modified to add ossl.
this agrees with the numbers i had for 4brute using different backends.
perhaps i am using somethings that calls itself ufc, but really is outdated, wrong, or so?
from patchlevel.h: "UFC-crypt, patchlevel 1c, @(#)patchlevel.h 1.9 03/02/92"
from the README (most people reading this probably dont know any of those except the 386. ;):
but, the README contains also a possible reason for the sucky performance i am seeing:
165 > 64. uh-oh.
let me guess, the Penti-M has 1MB cache?
goes to find something with bigger cache to rerun benches
athlon1000, 256kB
pentiumII 266, 512kB, 2.4.31 SMP
pentiumII 266, 512kB, 2.6.12.1 SMP
(note that the first P2 run only confirms that the linux 2.4.x SMP scheduler sucks frozen goats through nanotubes, with 2.6.x its right back in the pattern seen on the other hosts)
so, it does not seem to be just the size of the cpu cache.
makes me more interested in seeing the code used in >>169 ...
Hrm, i dont quite see the use of cracking tripcodes if you cant post.
I wonder if there is a working proxy server somewhere...
Some Japanese tripcode searchers, not tested and stolen from http://ansitu.xrea.jp/guidance/?FAQ1#t17de328
hello thar. Why doesn't my tripcodes work? I'm using tripper+ but I don't know how to configure the options because my computer won't show Japanese characters...
ﾃδεつεδづつεδεつづδづつづδεつεδづつづδεつづδづつづδεつεδづつεδεつづδづつεδεつεδづつづδεつづδづつ�δεつεδづつεδεつづδづつづδεつεδづつづδεつづδづつづδεつεδづつεδεつづδづつεδεつεδづつづδεつづδづつｨﾃδεつεδづつεδεつづδづつづδεつεδづつづδεつづδづつづδεつεδづつεδεつづδづつεδεつεδづつづδεつづδづつ�δεつεδづつεδεつづδづつづδεつεδづつづδεつづδづつづδεつεδづつεδεつづδづつεδεつεδづつづδεつづδづつ湘δεつεδづつεδεつづδづつづδεつεδづつづδεつづδづつー is 26% faster than mine on my G3. I suppose I should find a faster crypt, but I remember UFC not giving correct output in some case.
>>178
afaik, john has bitslice-des code for fruity platforms.
you could take a stab at adapting the 4brute++ code, but i dont even want to think about what parts of it might be endianess-sensitive.
updating the x86 DESBS code to some newer extensions than MMX would be a pretty heroic task for some highly motivated young coder. :)
Hi. Can someone here please explain why my tripcodes doesen't work?
According to a program called tripper+, "#/te¦4M¼A" will generate tripcode: "!aWrYyYlkcw".
But when I tested it on Sandbox, i got "!nbn1dFk5FA"
Why won't it work?
Because it's full of non-ASCII characters that will get parsed differently depending on which board you post it on, especially if you use HTML entities instead of the actual characters. If you want tripcodes that work everywhere, stick to plain ASCII characters only.
>>179
MMX registers are already 64 bits and have NOT AND and such. The only optimization that comes to mind would be vectorizing and doing two at once in SSE2 128bit registers
>>182
i am not so sure you know what bitslicing means. ;)
basicly it means using a CPU with N bit registers as N CPUs with 1 bit registers.
some operations (like DES) can profit from that a lot.
johns DESBS code does 64 "crypt() equivalent operations" in parallel on MMX, or 128 on altivec.
so porting this to newer extensions like SSE(2) would probably get another performance increase by a factor of 1.5-2 ...
but its hard to say without trying it since this stuff is getting really non-intuitive already. (direct influence of ram-speed on the performance, or the retarded linux 2.4.x SMP scheduler eating 70% of the performance, just to name two cute examples.)
>>183
SSE lacks the instructions to do the needed operations on its 128 bit registers, out of all of the additional instruction sets I can think of SSE2 is the only one that fit (I only know x86 chipsets). Maybe I didn't state it cleary, but I said you would not be likely to gain more than just being able to do two times as many as once. Not exactly something that is going to bring something that is currently an unreasonable search to feasability.
Altivec could certainly do it; it's much better than any x86 SIMD. Too bad it's only on the G4 and up. I could manage 32 bits at once, I guess.
>>185
For those curious of the AltiVec performance, a PowerPC G5 1.8 GHz
currently achieves the following:
Benchmarking: Traditional DES [128/128 BS AltiVec]... DONE
Many salts: 1103K c/s real, 1105K c/s virtual
Only one salt: 910566 c/s real, 910566 c/s virtual
The latest Pentium 4's aren't quite there yet (with MMX code).
Although SSE support for JtR is coming, preliminary testing shows that
it won't achieve this much speedup.
I would indent the quote but I am scared of markdown, straight from the horses mouth though (solar)
>>168
Your site doesn't work... It only redirects me to stuff like http://www.100webads.com/
>>187
100webspace is DQN.
this should work... http://wilson.merseine.nu/download/fasttrip.tar.bz2
>>184
well, it might be enough to shut up those fruituser claims about hardware superiority, considering they are less than factor 2 ahead while using 2x width. ;)
but, seeing how the biggest change in john 1.6.39 is adding a macosx-x86-mmx-cc build target, i guess apple will be shipping real computers before john grows SSE2 support. :)
>>188
Some instructions for using this would be nice.
>>189 doesn't seem to understand much :(
In the G5's case it's entirely CPU bound... I would look into running scalar and AltiVec at the same time, and why jtr's altivec code uses signed numbers.
But since I don't have one, I don't really care. I will see if I can make the non-DES parts parallelizable easily without making it really unreadable. SHA1 is supposedly AltiVecable as well; RC4 doesn't look like it is, though.
RC4 runs like a dream on 8-bit microcontrollers, though.
>>190
to search for a tripcode you just dotrip [regex]
ortrip -c [regex]
where [regex] is the regular expression you want to match. if you don't supply a regular expression it uses .* (matches all tripcodes). if you use -c it does case sensitive matching.
Wow those posts got screwed up..
anyways. Someone asked if it is impossible to crack a tripcode if you use an 8 character random string in aprevious life of this thread. The answer is no, if you really care about being the only one with the tripcode you should use a secure tripcode (name#trip#secure). This is the third and shittiest version of this post I have made. I shall not make another one.
I think the NSA has been attacking this thread to stop this information from getting out!
>>196
Damn bastards cannot leave DES alone! Why bother making the S-boxes resistant to differtial cryptology 15 years before anyone knows about it and then suggest a reduced keysize.. AND THEN hide the information that tripcodes are about as secure as a plastic lock!
does anyone have a copy of 4brute-johnbs?
Not on this board.
Someone really should make a post(somewhere) of all of the technical details of tripcodes. I keep forgetting to verify (and wel.l redo as they are totally fucked up) >>221-222 and list any other inconsitencies. I'm sure I'll eventually get around to it or someone else will do it for me.
Also, is it still 200GET if it isn't the first time?