Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-120121-

TRIPCODE QUINE!!!!

Name: faggot !Ep8pui8Vw2 2007-08-28 21:19 ID:8YbuJbma

Can you hack it /PROG/?

Name: Anonymous 2007-08-28 21:20 ID:8YbuJbma

(the idea is to make a tripcode which = itself encoded)

Name: Anonymous 2007-08-28 22:06 ID:Heaven

Definitely not by analytical methods.

Name: Anonymous 2007-08-29 3:12 ID:VLFnduJ3

>>3
??? Are you not HAX enoguh?

Name: string !PkuUAR7Kmk 2007-08-29 3:35 ID:Heaven

Easy.

Name: Anonymous 2007-08-29 3:52 ID:7E9J51VB

>>5
Idiot

>>2
Impossible.

Name: Anonymous 2007-08-29 4:11 ID:Heaven

Impossible.
prove it.

Name: Anonymous 2007-08-29 4:28 ID:7E9J51VB

>>7
Tripcodes are created using unix crypt() and a fuckload of salting.

What goes into the hash function cannot, by definition, come out the same as it went in.

Name: Anonymous 2007-08-29 4:34 ID:Heaven

>>8
formal proof or GTFO.

Name: Anonymous 2007-08-29 4:45 ID:7E9J51VB

>>9
Well, let's take a look at one of the first implementations of the tripcode algo:

<?php
function tripcode($name)
{
    if(ereg("(#|!)(.*)", $name, $matches))
    {
        $cap  = $matches[2];
        $cap  = strtr($cap,"&amp;", "&");
        $cap  = strtr($cap,",", ",");
        $salt = substr($cap."H.",1,2);
        $salt = ereg_replace("[^\.-z]",".",$salt);
        $salt = strtr($salt,":;<=>?@[\\]^_`","ABCDEFGabcdef");
        return substr(crypt($cap,$salt),-10)."";
    }
}
?>


echo tripcode("moot#faggot"); returns Ep8pui8Vw2.

Trying to create a 'tripcode quine' in this manner can't be done. It's about as feasible as an 'sha1 quine', so to speak.

Name: Anonymous 2007-08-29 4:47 ID:7GxzTXFF

Modified version of >>10 that solves this problem,

<?php
    function tripcode($name) {
      return $name;
    }
?>

Name: Anonymous 2007-08-29 4:59 ID:vOArf5lH

>>10
Are you stupid? How is this formal proof?
Tripcode quine means you type moot#Ep8pui8Vw2 in name field, and it becomes moot!Ep8pui8Vw2 when you click Reply

Name: Anonymous 2007-08-29 5:01 ID:7E9J51VB

>>11
You haven't yet mastered BBCode. You are not an EXPERT PROGRAMMER.

Anyway, say for a second I was wrong about this tripcode quine impossibility.


<?php
function tripcode($trip)
{
    $cap  = $trip;
    $cap  = strtr($cap,"&amp;", "&");
    $cap  = strtr($cap,",", ",");
    $salt = substr($cap."H.",1,2);
    $salt = ereg_replace("[^\.-z]",".",$salt);
    $salt = strtr($salt,":;<=>?@[\\]^_`","ABCDEFGabcdef");
    return substr(crypt($cap,$salt),-10)."";
}

srand();
while(1)
{
    $string = tripcode(rand()); // We need a 'random' string, and we need it to be a valid trip
    if(tripcode($string) == $string)
    {
        echo "Quine found! - $string\n";
    }
}
?>


This script hunts for 'tripcode quines'. According to my theory, it will never return any output. Ever. But give a try if you want :)

Name: Anonymous 2007-08-29 5:04 ID:7E9J51VB

>>12
Are you stupid? Why don't you read what the OP is suggesting? >>2

The op is suggesting a specially crafted tripcode that when entered as "name#asdsdfsf" it comes out as "name!asdsdfsf".

Name: Anonymous 2007-08-29 5:15 ID:vOArf5lH

>>13,14
[aa]Sorry for even trying to talk to you, you're hopeless[aa]

Name: Anonymous 2007-08-29 5:34 ID:PV+faYRQ

>>15
Syntax error

Name: Anonymous 2007-08-29 13:31 ID:Heaven

There's no way to supply the same input as the output, because the two aren't even the same length. DES takes a 56 bit key and outputs 64 bits.

Thread over.

Name: Anonymous 2007-08-29 16:18 ID:VLFnduJ3

>>14
I, The op are suggesting

asdsdfsf#asdsdfsf -> asdsdfsf!asdsdfsf

Name: Anonymous 2007-08-29 16:21 ID:Heaven

>>17
if crypt() is given more than 8 characters as input it ignores the extra ones at the end.
so #aaaaaaaa and #aaaaaaaaomgwtfbbq are the same tripcode.

Name: Anonymous 2007-08-29 16:25 ID:vOArf5lH

>>17
I can't believe your stupidity

Name: Anonymous 2007-08-29 16:27 ID:WjhC2bTS

OK guys, time to reread SICP for all of you -- what you are looking for is a fixed point function, which is described in like the first chapter or something.

Name: Anonymous 2007-08-29 16:55 ID:/xIJtDET

>>21
Yeah, I remember that chapter. "Breaking DES and other secure encryption algorithms", wasn't it?
Interesting stuff, especially the part where Sussman intercepted and decoded wireless packets with 2048-bits RSA encryption, using only a swiss army knife and higher-order programming, while being chased by black helicopters and a zombie t-rex.

Name: Anonymous 2007-08-29 17:34 ID:VLFnduJ3

>>22
rofl

Name: Anonymous 2007-08-29 18:37 ID:YOjCJ7yt

>>22
Win

Name: Anonymous 2007-08-29 22:05 ID:iOOMXUDG

numbers + lowercase chars + uppercase chars ~=~ 70

there are 10 chars, 2824752490000000000 possibilities, why not try brute force algorithm?
it will take about 90 thousand years, though, assuming a million attemps by second.

...........
Ok, maybe not. anyway, the tripcode function itself says little, what about a tripcode breaker? that's something one should begin to look at.

Name: Anonymous 2007-08-29 22:13 ID:u/yOzCBu

>>25
also .+!/

Name: Anonymous 2007-08-29 22:17 ID:VLFnduJ3

>>25
YOU MISCALCULATED

Name: Anonymous 2007-08-29 22:23 ID:iOOMXUDG

"~=~" means "aproximatted".
>>27
where?

Name: Anonymous 2007-08-29 23:42 ID:aX0wiKk6

>>19 If you don't care about the extra characters, sure.
>>20 Go back to bed. Working with cryptosystems is my full-time job.
>>26 Just period and slash.
>>28 ≈ means approximate, and the answer is 64, as was mentioned earlier in this thread.

At any rate, there's only eight characters input, thus 281474976710656 possibilities. One million inputs per second is very poor performance; you can easily get five or six million with a modern processor, and that's not even considering specialized DES-cracking hardware. Multiply by a small distributed network of 30 systems (which isn't at all difficult to get; all you need for this is the CPU and motherboard, and a minimal amount of RAM, so you can build one yourself for less than $300) and you have a very reasonable time of 18 days.

Name: Anonymous 2007-08-29 23:57 ID:VLFnduJ3

>>29
YOU MISCALCULATED

Name: Anonymous 2007-08-30 5:58 ID:Heaven

>>27
>>30
samefag

Name: Anonymous 2007-08-30 6:51 ID:Z1VZr0m4

>>30

His only mistake was assuming that a general purpose PC can do 5-6 million crypts per second. About 1.5 million would be more accurate. The remaining calculations are sound.

Output of crypt can be A-Z, a-z, 0-9, . or / - this gives 26 + 26 + 10 + 2 = 64 different characters.

A tripcode contains 8 characters, so the theoretical (perhaps not all can be created) tripcode space is 648 = 281,474,976,710,656.

Divide that by the crypts per second. Further divide that by 86400 (number of seconds in a day) - you now have the number of days. I make that 2172 days for my 1.5 millions estimate and 543 days for his 6 million.

Divide by the number of computers working on it. Mr >>29 says thirty. That gives 72 days for my estimate of cps and 18 days for his.

Name: Anonymous 2007-08-30 6:58 ID:gWekq0zm

We need a Tripcode@home campaign

Name: !DEEPjKeito 2007-08-30 7:21 ID:DwjwhIIv

>>33
how do you think shit like this got cracked?

Name: Anonymous 2007-08-30 7:33 ID:Ocbkjg1s

someone post a tripcode cracker and ill change it into a quine generator

Name: Anonymous 2007-08-30 7:39 ID:SN2SlQY7

>>32
Six million tripcodes per second per CPU is actually a quite sound estimate. You're probably thinking in terms of running standard crypt() (or maybe DES_crypt()) in a for loop. Remember every time you call crypt(), it has to do a lot of bitwise manipulating to get a 56-bit key out of the input characters, set up the IV, etc., and it has to do more bit arithmetic at the end. For a sequential search of *all* tripcodes with a given key size you can make the search many times more efficient by setting up the IV once and iterating through the keys numerically. This is especially fast if you use bitslicing code instead of assuming a one-to-one mapping of plaintext->crypttext. Now, once you've eliminated all that unnecessary bit-shifting and initialization overhead, you can speed things up further by reducing the comparison function to a simple xor between two 64-bit integers instead of a costly strcmp().

Name: Anonymous 2007-08-30 8:02 ID:Ocbkjg1s

>>36
IMPLEMENTATION PLZ ;)

Name: Anonymous 2007-08-30 10:54 ID:Z1VZr0m4

>>36
That's an interesting theory. Please post some code demonstrating this.

Name: Anonymous 2007-08-30 11:01 ID:Heaven

Name: Anonymous 2009-03-06 6:38


Quine' so to speak   of ie not   you is not   superior to C   to get better   performance The better   question is If   you get to   a medium skill   level you can   have 3 7s   1 9 and   now 10 u   must trai it?

Name: Anonymous 2009-08-16 23:23

Lain.

Name: test !3ORzU0yNjQ 2013-03-06 2:49

bumping a thread that is 4 years old. I'm trying to figure out how to get a specific tripcode in php. my logic would be the following:

if($tripcode == $desired){
echo $hashtext."==".$tripcode;
}

also testing shit.

Name: Anonymous 2013-03-06 4:22

>>43 more info?

@ ghosts of /prog/ past... nice idea, but there may well not even be one..
chances are there would be cyclic quines though.. (whether or not there is collisions, there Will be cycles in the hash.. (unless everything is a collision..)) ^^
might be better off looking for a name ->hash-> trip /and/ trip ->hash-> name (ie period-2 cycle) ;)

Name: Anonymous 2013-03-06 6:19

>>44
That's (almost) equally unlikely.

If we just take the first 8 characters of the tripcode and feed that back into the hash function:

aaaabbbb -> zzzzcccc(xxx)
zzzzcccc -> aaaabbbb(xxx)

Equivalent to attempting to find x = f(f(x)) for some x. If x = f(x) doesn't exist for any x, then it's possible that neither does x = f(f(x)), because the set of all 8 char inputsX is equivalent to the map f(X) -> Y, just in different order.

Taking a simple ``hash'' function with no collisions:

f(x) = x+1%100 bounded on 0 <= x < 100, then there is no x that satisfies f(x) = x. Similarly, there is no f(f(x)) = x, due to the property of the function, you have to do 100 cycles before the input can equal the output. Which is equivalent, in this case, to feeding the entire set of its inputs to the function, until you get back to where you started.

So even in the DES hash, it's possible you'd have to perform 648 = 281,474,976,710,656 cycles before you can satisfy the equation.

The chance is still absurdly low. It gets higher and higher the more cycles you use, but the rate at which the chance goes up is dependent on how many collisions the function has.

Name: Anonymous 2013-03-06 6:51

>>45
Expanding on this, to make it a bit clearer:

Chaining f(x) 100 times is equivalent to turning it into f(x) = (x+100) mod 100, which is just x.

If in DES, we create the set Y by feeding in all possible 8 char inputs in X, and we assume that X and Y are subsets of each other (they share all elements), then we can turn the DES hash function into a function that associates each input in X with a position, or index in Y.

So we can represent each element x in X as a natural number, from 0 to 281,474,976,710,656, and associate with it another number, j that maps x to its corresponding (equal) entry y in Y. If we restrict all numbers j to be positive, then the function for getting the y in Y associated to the x in X equivalent to:

f(x) = (x + j) mod 281,474,976,710,656.

Now, we see that this is equivalent to the previous ``simple'' hash function that just added 1 to x. The addition in the previous function was constant, whereas this one changes depending on x. If there are no collisions, then for any 2 distinct x and j, x + j is unique.

So, to find a ``cyclic quine'', we are trying to find a series of x in X that generate a series of j so that the sum of all those j and j mod 281,474,976,710,656 is equal to x.

In other words, you're trying to find a series of x and associated j, which, when all summed together, result in 281,474,976,710,656 + s, where s is the first x that fed to the chain.

Calculating the amount of cyclic quines for any amount of cycles c is the subset sum problem, which is NP-Complete.

So just calculating all quines for cycle c  through applying all j for all x would take more time than the lifetime of the Universe. Finding one by bruteforce is not likely.

Name: Anonymous 2013-03-06 6:54

>>46
so that the sum of all those j and j mod 281,474,976,710,656 is equal to x.

Should be:

so that the sum of all those j and x mod 281,474,976,710,656 is equal to x.

Name: Anonymous 2013-03-06 7:04

>>43
php

Of course you are testing shit

Name: Anonymous 2013-03-06 7:26

So even in the DES hash, it's possible you'd have to perform 64^8 = 281,474,976,710,656 cycles before you can satisfy the equation.

It's possible, but that too is highly unlikely.. mainly because it implies that all hashes chain together perfectly to form a single period-64^8 cycle. at most (?) the longest cycle (at random) should probably be at least a binary order of magnitude less... probably closer related to the longest run over n random bits ;D

is dependent on how many collisions the function has.

i'd also argue that it has more to do with the number of disjoint cycles than collisions =)

Name: Anonymous 2013-03-06 7:41

>>49

i'd also argue that it has more to do with the number of disjoint cycles than collisions

Each cycle is just the same as if you replaced the set of inputs X with Y, and reordered the set of all numbers j, which can be denoted as J.

The operations that come out of this, as noted in >>46, can just be treated as the generation of an n-dimensional vector, for n cycles, and the problem of finding the ``cyclic quine'' equivalent to checking if the vector is a linear combination over the space. Assuming random distribution, since it's a hash function, and little to no collision, you can calculate the chance of finding one of these quines by the size of the space, and each cycle adding another dimension. The more dimensions, the higher the chance. The number of disjoint cycles cannot be easily computed, due to the fact that hash functions are made to resist such things. But you can just compare the number of elements to the dimension of the vector.

Name: Anonymous 2013-03-06 7:54

>>50 =) sounds like we agree
This is kind of the concept i have.. there will be some number n cycles of assorted lengths.. smaller ones are of course harder to find individually, but there may or may not be many of them (probably quite a few at least, as they don't take up much room..) there will also be another component, i'm going to call these strands, which are formed where a chain of hashes collides with a member of a cycle.. strands are not cyclic, but will inevitably lead to a cycle.. ^^

Name: Anonymous 2013-03-06 8:04

>>51

You can probably just use a statistical approach for a large number of cycles. Hash functions tend to avalanche / converge to certain points over many cycles.

Pick a cycle number, and create a matrix that represents the distances between the output and input. Or you can just put that all in a vector, whichever way. After calculating some amount of these, you'll likely start to be able to discern patterns in the distances recorded in the vectors.

Then you can use those distances as a guide for which initial x to choose to have a higher chance of finding a quine.

Not sure how easy it would be to properly normalize those vectors so as to actually be able to gather starting points, though. Seems like it would get harder as the dimensions rise, unfortunately.

Name: Anonymous 2013-03-06 9:01

hm this is kind of neat..
Would it be fair to expect that for a hash function with at least one collision and one cycle, around 50% of the elements(?) might exist as part of a strand, and the other 50% as part of a cycle?
The number of collisions apparently is = to the number of strands(?!), and for each strand there is another end, ie an input which is not possible to output given any input.. funnily enough these are probably the hardest to find, but pretty much guaranteed to exist =)
Like you said, very difficult to know how many cycles there is exactly =/

Name: Anonymous 2013-03-06 9:17

oh, and a third thing can happen, which is where a new strand merges with an existing strand (via a collision), kind of like a tree leading to a cycle..
Probably a bit optimistic to expect a very long strand to link to a very short cycle.. but it could happen =)

Name: Anonymous 2013-03-06 9:20

>>53

Better define the term ``strand''. Also, it depends on the dimension of the cycle.

For a cycle of large dimension, probably more than 50% of the elements are part of the cycle. For a cycle of dimension 10, there's probably only a very small percentage of elements that are part of the cycle. Much less than 1%, I'd say.

Here I define cycle of dimension 2 to be f(f(x)). A cycle of dimension 1 would just be x = f(x).

Also, if the hash has collisions, the number of "unreachable" outputs is the same as the number of collisions. Obviously because if it outputs n hashes, and x of those hashes are the same, the number of different hashes is n - x, which leaves n ``holes''. Assuming the input and output space are the same.

You might want to look into linear regression for the statistical approach in finding these quines.

Name: Anonymous 2013-03-06 9:22

>>55

I meant, which leaves x ``holes''.

Name: Anonymous 2013-03-06 9:26

even better if it's a very large tree instead, with a short cycle, in terms of finding them =D

Name: Anonymous 2013-03-06 9:32

>>57

A large tree? Picking a random element as the top of the tree, and having other random elements as leaves, viewing edges as chainings, etc?

That's probably going to trap you in a local minima extremely quickly. The chain converge is likely decided early on in the operation sequence.

Name: Anonymous 2013-03-06 9:38

cycle of dimension 2 to be f(f(x)) = x
and yep, Assuming the input and output space are the same.
a strand is effectively defined as beginning at each of the x holes (inputs with no preimage at all - side-effect of collisions)... where they end can't really be said till you've completed a circuit of the attached cycle?

Name: !myrKUSIW0s 2013-03-06 9:40

Are we sure 70 chars is "about right"? I've seen trips using accented characters and punctuation.

It's more likely to be UTF-8 or even 16, which means a much larger set of possible symbols.

Eg, the trip I am using is: #z水????????????

Name: !myrKUSIW0s 2013-03-06 9:41

>>60
And then I realized you guys meant output. Shame on me.

Name: Anonymous 2013-03-06 9:47

well, a large and shallow tree would be ideal but would probably need lots of collisions..
random oracle model? ^^ / hmm wonder what will happen to this with a larger input -> output, or even just using salts....

Name: Anonymous 2013-03-06 9:48

>>60,61
The number of input characters is 95 + what you can fit in using Shift-JIS, I think.

>>59
beginning at each of the x holes
So, a strand is something where the first input in the chain, say, x0 is not in the set of outputs?

A cause of this would be a unique first offset for the cycle, I suppose. Perhaps you can find these by computing many, many random short cycles, and seeing which "offsets" are never applied? The set of ``holes'' would be a subset of those.

I'll have to do some testing on this, myself. Also, actually look at the internals of DES, it's been a while since I did. Perhaps you can extract some properties from looking at how it handles things in the first few rounds.

Name: Anonymous 2013-03-06 9:54

i think statistically, for a hash with no collisions at all, there will be around log2(n) disjoint cycles? kind of like the birthday paradox, but each person only adds one instead of n-1 for the n-th person =)

Name: Anonymous 2013-03-06 10:16

and then for a normal hash the first strand+cycle+collision can be expected at n^0.5, with the birthday non-paradox (>>64) chance of just finding a cycle instead =D

Name: Anonymous 2013-03-06 10:37

>>64

Let me think. If for a function that takes n elements and outputs n elements, with no collisions, and the output is suitably random, then the chance of encountering a disjoint cycle in dimension N would be...

Taking a first random x, chance to find one that is disjoint, is 1/n. Chance of finding a disjoint sum taking x and two other random elements is n-1/((n-1)!)

With three elements its... what the hell is the equation for the number of all unique subsets of a set where each subset has n elements?

Just apply this, but with the mod n for the group. Due to the mod it'll go up for each dimension, otherwise the chance would diminish.

I'll work this out and see.

Name: Anonymous 2013-03-06 10:50

>>44
You wouldn't look so retarded if you stopped abusing emoticons so much, retard-kun.

Name: Anonymous 2013-03-06 11:02

>>66

Right, assuming that all permutations are possible, a cycle in dimension N creates n! / (n - N) subsets. Due to n being 281,474,976,710,656 this number is huge. The subset of that generated set, where the elements add up to a multiple of n is the number of disjoint cycles, and the chance of getting a disjoint cycle for dimension N can be arrived at by figuring out that number.

Though, I'm not sure how to calculate the number in higher dimensions with a mod.

Name: Anonymous 2013-03-06 14:07

I need a LaTeX to BBCode compiler. Making far too many errors in the equations. I meant n / N - (n - N) in the above post.

I think the number of possible disjoints might actually get lower the more collisions there are. Or, at least, it'll become unstable.

Name: Anonymous 2013-03-06 14:08

Fucking hell. Should be:

n! / N! (n - N)! in the above post.

Name: Anonymous 2013-03-06 22:47

i have a rather stupid question. if we try different password against tripcode algorithm (which is 10 last characters of crypt()'s hash for a given password) bruting for a specific string in the tripcode (like tripcode explorer does), does it matter how many possible characters our password can have? would more possible characters speed the process? apart from technical requirements (like passwords with 1 possible character would just crash your computer since the only way to change them it's to increase their length and you need hundred of millions different passwords etc), if we take 52 possible characters (alphabet only) and, say, 100 possible characters (alphabet + special symbols and other weird shit, if we don't care of possible tripcode compatibility problems), would it take the same time to brute a desirable string? i guess yes since i don't see how it matters. if any combination have an equal chance to pass it shouldn't matter how many different symbols it contains, we can have the same number of combination with any set of characters, if we have less characters we just should make passwords longer more soon but it shouldn't affect the speed. am i right?

Name: Anonymous 2013-03-06 22:50

It makes me feel better to see that people were still mean back in 2007. Maybe we didn't ruin /prog/ and it was always like this.

>>46
Now I need to wash my underwear. :\

Name: Anonymous 2013-03-06 22:56

>>70
just [b] the whole thing

Name: !!8y+XapecU2EyVoF 2013-03-06 23:51

asf

Name: !zfhFgYqZk6 2013-03-06 23:52

asd

Name: !!rDJsM61+WG64Yln 2013-03-06 23:53

asd

Name: !zfhFgYqZk6 2013-03-06 23:53

asd

Name: !TO.0Yxx82k 2013-03-06 23:53

asd

Name: !WULf08IaA. 2013-03-06 23:54

asd

Name: asdf !tr.t4dJfuU 2013-03-07 0:04

asdafs

Name: anus !u8dVJyyGAs 2013-03-07 0:14

anus

Name: Anonymous 2013-03-07 0:44

Jesus this was a depressing thread. People believe the dumbest shit about tripcodes.

Name: Anonymous 2013-03-07 0:58

>>82
Kids say the darndest things!

Name: Anonymous 2013-03-07 1:10

huh, i should of read the thread. well, >>19 means that 8 character passwords are the limit (i proved it, it's true), so difference between 52 vs 100 possible characters in a password is 52 + 2704 + 140608 + 7311616 + 380204032 + 19770609664 + 1028071702528 + 53459728531456 = 54507958502660 vs 100 + 10000 + 1000000 + 100000000 + 10000000000 + 1000000000000 + 100000000000000 + 10000000000000000 + 10000000000000000 = 10101010101010100 possible passwords.
for any practical purpose there shouldn't be any difference (if i was right in the previous post) since you are unlikely can try every possible combination even for 52 characters

i know it's a stupid question, but if i'm not right could somebody show it -_-

Name: Anonymous 2013-03-07 1:14

american public education at its finest

Name: Anonymous 2013-03-07 1:25

>>85
don't be mean to me ><
my c is bad, i cannot completely understand the source of crypt() so i don't know if the possibility for any particular symbol to be at any particular position in the hash output depends on the set of symbols you use for passwords or not

Name: Anonymous 2013-03-07 1:33

>>84
I can't even begin to guess where you got those numbers. Maybe you should stop posting.

Name: Anonymous 2013-03-07 1:49

>>87
Can't you tell that they are all either primes or the products of primes? Are you seriously this stupid?

Name: Anonymous 2013-03-07 1:53

>>87

eh. i suppose you cannot say anything useful.

well, it's the number of possible inputs to crypt() i.e. possible passwords 1-8 characters long if we use 52 different characters (i.e. a-z A-Z) and (for simplicity) 100 characters (alphabet + special characters + some non-ascii stuff). i.e. it's 52^1+...+52^8 and 100^1+...100^8

of course (huh), hash still would have the same number of possible characters in its outputs disregard what set of characters we use in our inputs, but the question is, will the possibility for any particular symbol to be at any particular position in the hash output depends on the set of symbols you use for passwords or not

to put it more simple, yesterday, out of curiosity, i wrote a tripcode bruter to brute a 1-10 character long string at the beginning of tripcode, but it's slow, it uses 54 different characters for its passwords, i wonder if i increase the pool of possible characters it will have any effect on its speed or not. i guess it wouldn't. the actual tests would be very annoying -_-

Name: Anonymous 2013-03-07 2:26

>>89
You're... bad at things.

The tripcode algorithm's fixed points are obviously going be exactly ten characters long and contain only characters from the set A-Za-z0-9./.

648 = 281,474,976,710,656 inputs. Supposing Tripcode Explorer runs at 4 billion trips per second, that's going to take about 19 and a half hours to check. Get to it.

And stop using ``brute'' as a verb, fucking mouth-breather.

Name: Anonymous 2013-03-07 2:36

>>90
^^ faggot

Name: Anonymous 2013-03-07 2:41

>>90

eww. do you even understand my question? you are talking about tripcode output. its obvious that it has 64 possible characters and is 10 characters long, i mentioned it too despite it's obvious

input (i.e. password) isn't limited with those 64 characters (you can prove it here http://desktopthread.com/tripcode.php, try stuff like ~`{}-_=+ etc in your passwords)
and you can use less than 64 characters as well

the problem is how output would depend on input

Name: Anonymous 2013-03-07 2:41

>>91
Imageboard effluent.

Name: Anonymous 2013-03-07 2:46

>>92
This thread is about tripcode's hypothetical fixed points, not about writing skiddy cracker #1,403. People have been writing tripcode crackers for fourteen years now, and /prog/ itself has already produced dozens. They aren't interesting to anyone anymore.

If you are going to try to write a cracker, at least have the decency not to tell us about it (and read gopher://xarn.no-ip.org:7070/0/tripcode.txt so you don't end up shitting yet another broken implementation onto the Internet).

Name: Anonymous 2013-03-07 2:56

>>94

i asked a quite basic question of crypt() algorithm which you at first didn't understand and then couldn't answer so you began to try to insult me, it's kind of funny

also i didn't get, you think i have no right to write something for my own amusement and ask about if its perfomance depends on something just because it was already written?

Name: Anonymous 2013-03-07 2:59

>>95
I didn't even read your question. You have a right to write whatever you want; you don't have a right to shit up more interesting threads with it without being called out for being off topic.

Name: Anonymous 2013-03-07 3:01

>>96
there there

Name: Anonymous 2013-03-07 3:05

>>97
that that

Name: Anonymous 2013-03-07 4:25

I'm not sure who's who anymore, but I'm the guy with the crypto background that at least attempted to formalize the problem in >>45-46 and so on.

If you're still here, other person who was working on it, or anyone else interested in this, we can attempt to work on this together. I've got a simple, non-optimized version of crypt(3) that I can use to do cryptanalysis, surely it'll help in finding starting points if we actually take into consideration implementation details, the layout above was probably a bit too abstract, seeing as it just assumes no collisions and perfect space distribution. Though, some quick by-hand calculations shows that you're almost guaranteed to hit a cyclic quine at N/2 cycles, where N = output space. This is ~140 trillion hash cycles, for crypt(3)'s scheme as it is implemented in the trips.

I've still got to figure out how the chances are impacted depending on how the set of translation inputs J is structured. While X cannot have duplicated members, J can. Or, at least, it can have members that equal each other after a mod N, where this isn't possible with X due to it being a 1-1 indexing set to Y and no x in X can be greater than N.

I'll try to post some code that can find partial quines, later in the week, if I can manage it.

Name: Anonymous 2013-03-07 4:41

ah sounds cool (>>44,49 here) what language did you use?
uhm, also what was J? is that a strand / (non-cyclic) chain of hashes?

Name: Anonymous 2013-03-07 4:57

>>100
J was the set of translation inputs ji that are applied to each xi in X for i = 1, ..., N, where xi + ji = yi in Y.

In other words, I'm not sure what effect ``offsets'' not all being different has. Of course, if they're all different, but at the same time synchronizing, as in the function:

f(x) = (x + j) mod N; where j = (N - x)

Then this is a hash function made entirely of collisions, for

setting N = 10

f(5) = (4 + (10 - 4)) mod 10 = 0
f(5) = (5 + (10 - 5)) mod 10 = 0
f(6) = (6 + (10 - 6)) mod 10 = 0
...


Even though each value ji for xi is unique (being effectively just an inversion of the set X)...

Anyway, I use C. I just wrote something to generate a lot of random perfect hash functions and generate all subsets of size c which were then applied as operations and got some stats out of it.

No real need for bignum stuff because if you work with subset generation / set operations beyond what a long int can hold you're going to need a supercomputing cluster anyway. Mostly just trying to figure out where to start.

Name: Anonymous 2013-03-07 5:09

hmm.. then in my (kind of made up) terminology.. it has one cycle of period 1 (basically the quine of the set) at f(0) = 0, and if i assume 1:1 input:output space, 9 strands, else as many as there are inputs -1 =)

Name: Anonymous 2013-03-07 5:17

>>101

Err, sorry. Mistake. The following:
where xi + ji = yi in Y.

Should be:

where (xi + ji) mod N = yi in Y.

>>102
I'm still not clear on what you mean by strands. Also, say that there are collisions. This means that for an endpoint x there is more than one way to get to it. So depending on the number of collisions and path of the hash, over time, many cycles will converge towards collisions, and if you had the time to compute the entire input space, you could use a large bit array to get a bit table of where all the "holes" are.

What is your assumption of the 1 cycle quine f(0) = 0 based off of? Do you define a strand to be a cycle that doesn't connect to the rest of the set? Is that what you're saying? Maybe a better term would be string, then. Since even though it doesn't connect to the rest of the set, it'll loop in on itself many times.

Name: Anonymous 2013-03-07 5:24

>>103

``Closed string'', perhaps.

Name: Anonymous 2013-03-07 5:42

oh no! i'm calling a "Closed string" a cycle (of some/any period).
Strands begin from the holes in the table, and are certainly linked to collisions, but it is highly unlikely that a randomly chosen starting point will be the beginning of a strand.. so a part of a strand can be defined as any input w that cannot be reached by repetitive application of f() to w

Name: Anonymous 2013-03-07 5:52

hmm, example. w = 0

f(0) = 1 (shorthand 0 -> 1)

then if 1 -> 2 -> 3 -> (4 -> 4) 0..3 are part/members of a strand, 0 is (probably) the beginning of the strand..? and 4 is a cycle

Name: Anonymous 2013-03-07 5:56

'probably' because i didn't define the size of the set.. ie 5 -> 0... making 5 the beginning?

Name: Anonymous 2013-03-07 6:09

>>105
Let us start to use proper terminology so that we can define it all appropriately.

[m]1: fn(x) defines an iterated function in degree n.

x1 = f(x0) = f[sup]0(x)
x2 = f(x1) = f[sup]1(x)
x3 = f(x2) = f[sup]2(x)
...
xn+1 = f(xn) = f[sup]n(x)
[/m]

If strands begin at holes, then there are just as many strands as there are holes... a part of a strand defined as an output y that cannot be reached for fn(w) for n < N.

Therefore, the set of all strands (being a set of vectors of dimension N at most) is the set A - C.

where A:
fn(X) set of all possible unique cycles
and C is equal to A, taking away all the elements that have a vector c0 = {v1, v0, ... vn} where v1 is a unique value in the vector. It's likely that all other vectors are either combinations of these vectors, or have some complementary properties with other vectors that could be discerned.

Name: Anonymous 2013-03-07 6:12

>>108

Fuck.


1: fn(x) defines an iterated function in degree n.

x1 = f(x0) = f0(x)
x2 = f(x1) = f1(x)
x3 = f(x2) = f2(x)
...
xn+1 = f(xn) = fn(x)

Name: Anonymous 2013-03-07 7:24

Here's a simple crypt(3) implementation to analyze.
Not to be used for bruteforce.

#include <sys/types.h>

//
// This program implements the Proposed Federal Information Processing Data
// Encryption Standard. See Federal Register, March 17, 1975 (40FR12134)
//

//
// Initial permutation
//

static const char IP[] = {
  58, 50, 42, 34, 26, 18, 10, 2,
  60, 52, 44, 36, 28, 20, 12, 4,
  62, 54, 46, 38, 30, 22, 14, 6,
  64, 56, 48, 40, 32, 24, 16, 8,
  57, 49, 41, 33, 25, 17, 9, 1,
  59, 51, 43, 35, 27, 19, 11, 3,
  61, 53, 45, 37, 29, 21, 13, 5,
  63, 55, 47, 39, 31, 23, 15, 7,
};

//
// Final permutation, FP = IP^(-1)
//

static const char FP[] = {
  40, 8, 48, 16, 56, 24, 64, 32,
  39, 7, 47, 15, 55, 23, 63, 31,
  38, 6, 46, 14, 54, 22, 62, 30,
  37, 5, 45, 13, 53, 21, 61, 29,
  36, 4, 44, 12, 52, 20, 60, 28,
  35, 3, 43, 11, 51, 19, 59, 27,
  34, 2, 42, 10, 50, 18, 58, 26,
  33, 1, 41, 9, 49, 17, 57, 25,
};

//
// Permuted-choice 1 from the key bits to yield C and D. Note that bits
// 8,16... are left out: They are intended for a parity check.
//

static const char PC1_C[] = {
  57, 49, 41, 33, 25, 17, 9,
  1, 58, 50, 42, 34, 26, 18,
  10, 2, 59, 51, 43, 35, 27,
  19, 11, 3, 60, 52, 44, 36,
};

static const char PC1_D[] = {
  63, 55, 47, 39, 31, 23, 15,
  7, 62, 54, 46, 38, 30, 22,
  14, 6, 61, 53, 45, 37, 29,
  21, 13, 5, 28, 20, 12, 4,
};

//
// Sequence of shifts used for the key schedule.
//

static const char shifts[] = {
  1, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1,
};

//
// Permuted-choice 2, to pick out the bits from the CD array that generate
// the key schedule.
//

static const char PC2_C[] = {
  14, 17, 11, 24, 1, 5,
  3, 28, 15, 6, 21, 10,
  23, 19, 12, 4, 26, 8,
  16, 7, 27, 20, 13, 2,
};

static const char PC2_D[] = {
  41, 52, 31, 37, 47, 55,
  30, 40, 51, 45, 33, 48,
  44, 49, 39, 56, 34, 53,
  46, 42, 50, 36, 29, 32,
};

//
// The following structure maitains the key schedule.
//

struct sched {
  // The C and D arrays used to calculate the key schedule.
  char C[28];
  char D[28];

  // The key schedule. Generated from the key.
  char KS[16][48];

  // The E bit-selection table.
  char E[48];
};

static const char e[] = {
  32, 1, 2, 3, 4, 5,
  4, 5, 6, 7, 8, 9,
  8, 9, 10, 11, 12, 13,
  12, 13, 14, 15, 16, 17,
  16, 17, 18, 19, 20, 21,
  20, 21, 22, 23, 24, 25,
  24, 25, 26, 27, 28, 29,
  28, 29, 30, 31, 32, 1,
};

//
// Set up the key schedule from the key.
//

static void setkey_r(struct sched *sp, const char *key) {
  int i, j, k;
  int t;

  // First, generate C and D by permuting the key.  The low order bit of
  // each 8-bit char is not used, so C and D are only 28 bits apiece.
  for (i = 0; i < 28; i++) {
    sp->C[i] = key[PC1_C[i] - 1];
    sp->D[i] = key[PC1_D[i] - 1];
  }

  // To generate Ki, rotate C and D according to schedule and pick up a
  // permutation using PC2.
  for (i = 0; i < 16; i++) {
    // Rotate
    for (k = 0; k < shifts[i]; k++) {
      t = sp->C[0];
      for (j = 0; j < 28 - 1; j++) sp->C[j] = sp->C[j + 1];
      sp->C[27] = t;
      t = sp->D[0];
      for (j = 0; j < 28 - 1; j++) sp->D[j] = sp->D[j + 1];
      sp->D[27] = t;
    }

    // Get Ki (note C and D are concatenated)
    for (j = 0; j < 24; j++) {
      sp->KS[i][j] = sp->C[PC2_C[j] - 1];
      sp->KS[i][j + 24] = sp->D[PC2_D[j] - 28 - 1];
    }
  }

  for (i = 0; i < 48; i++) sp->E[i] = e[i];
}

//
// The 8 selection functions. For some reason, they give a 0-origin index,
// unlike everything else.
//

static const char S[8][64] = {
  { 14,  4, 13,  1,  2, 15, 11,  8,  3, 10,  6, 12,  5,  9,  0,  7,
     0, 15,  7,  4, 14,  2, 13,  1, 10,  6, 12, 11,  9,  5,  3,  8,
     4,  1, 14,  8, 13,  6,  2, 11, 15, 12,  9,  7,  3, 10,  5,  0,
    15, 12,  8,  2,  4,  9,  1,  7,  5, 11,  3, 14, 10,  0,  6, 13 },

  { 15,  1,  8, 14,  6, 11,  3,  4,  9,  7,  2, 13, 12,  0,  5, 10,
     3, 13,  4,  7, 15,  2,  8, 14, 12,  0,  1, 10,  6,  9, 11,  5,
     0, 14,  7, 11, 10,  4, 13,  1,  5,  8, 12,  6,  9,  3,  2, 15,
    13,  8, 10,  1,  3, 15,  4,  2, 11,  6,  7, 12,  0,  5, 14,  9 },

  { 10,  0,  9, 14,  6,  3, 15,  5,  1, 13, 12,  7, 11,  4,  2,  8,
    13,  7,  0,  9,  3,  4,  6, 10,  2,  8,  5, 14, 12, 11, 15,  1,
    13,  6,  4,  9,  8, 15,  3,  0, 11,  1,  2, 12,  5, 10, 14,  7,
     1, 10, 13,  0,  6,  9,  8,  7,  4, 15, 14,  3, 11,  5,  2, 12 },

  {  7, 13, 14,  3,  0,  6,  9, 10,  1,  2,  8,  5, 11, 12,  4, 15,
    13,  8, 11,  5,  6, 15,  0,  3,  4,  7,  2, 12,  1, 10, 14,  9,
    10,  6,  9,  0, 12, 11,  7, 13, 15,  1,  3, 14,  5,  2,  8,  4,
     3, 15,  0,  6, 10,  1, 13,  8,  9,  4,  5, 11, 12,  7,  2, 14 },

  {  2, 12,  4,  1,  7, 10, 11,  6,  8,  5,  3, 15, 13,  0, 14,  9,
    14, 11,  2, 12,  4,  7, 13,  1,  5,  0, 15, 10,  3,  9,  8,  6,
     4,  2,  1, 11, 10, 13,  7,  8, 15,  9, 12,  5,  6,  3,  0, 14,
    11,  8, 12,  7,  1, 14,  2, 13,  6, 15,  0,  9, 10,  4,  5,  3 },

  { 12,  1, 10, 15,  9,  2,  6,  8,  0, 13,  3,  4, 14,  7,  5, 11,
    10, 15,  4,  2,  7, 12,  9,  5,  6,  1, 13, 14,  0, 11,  3,  8,
     9, 14, 15,  5,  2,  8, 12,  3,  7,  0,  4, 10,  1, 13, 11,  6,
     4,  3,  2, 12,  9,  5, 15, 10, 11, 14,  1,  7,  6,  0,  8, 13 },

  {  4, 11,  2, 14, 15,  0,  8, 13,  3, 12,  9,  7,  5, 10,  6,  1,
    13,  0, 11,  7,  4,  9,  1, 10, 14,  3,  5, 12,  2, 15,  8,  6,
     1,  4, 11, 13, 12,  3,  7, 14, 10, 15,  6,  8,  0,  5,  9,  2,
     6, 11, 13,  8,  1,  4, 10,  7,  9,  5,  0, 15, 14,  2,  3, 12 },

  { 13,  2,  8,  4,  6, 15, 11,  1, 10,  9,  3, 14,  5,  0, 12,  7,
     1, 15, 13,  8, 10,  3,  7,  4, 12,  5,  6, 11,  0, 14,  9,  2,
     7, 11,  4,  1,  9, 12, 14,  2,  0,  6, 10, 13, 15,  3,  5,  8,
     2,  1, 14,  7,  4, 10,  8, 13, 15, 12,  9,  0,  3,  5,  6, 11 },
};

//
// P is a permutation on the selected combination of the current L and key
//

static const char P[] = {
  16, 7, 20, 21,
  29, 12, 28, 17,
  1, 15, 23, 26,
  5, 18, 31, 10,
  2, 8, 24, 14,
  32, 27, 3, 9,
  19, 13, 30, 6,
  22, 11, 4, 25,
};

//
// Encrypt a block
//

static void encrypt_r(struct sched *sp, char *block, int edflag) {
  // The current block, divided into 2 halves.
  char L[64], *R = L + 32;
  char tempL[32];
  char f[32];

  // The combination of the key and the input, before selection
  char preS[48];

  int i, ii;
  int t, j, k;

  // First, permute the bits in the input
  for (j = 0; j < 64; j++) L[j] = block[IP[j] - 1];

  // Perform an encryption operation 16 times
  for (ii = 0; ii < 16; ii++) {
    // Set direction
    if (edflag) {
      i = 15 - ii;
    } else {
      i = ii;
    }

    // Save the R array, which will be the new L
    for (j = 0; j < 32; j++) tempL[j] = R[j];

    // Expand R to 48 bits using the E selector; exclusive-or with the current key bits
    for (j = 0; j < 48; j++) preS[j] = R[sp->E[j] - 1] ^ sp->KS[i][j];

    // The pre-select bits are now considered in 8 groups of 6 bits each.
    // The 8 selection functions map these 6-bit quantities into 4-bit
    // quantities and the results permuted to make an f(R, K). The
    // indexing into the selection functions is peculiar; it could be
    // simplified by rewriting the tables.

    for (j = 0; j < 8; j++) {
      t = 6 * j;
      k = S[j][(preS[t + 0] << 5) +
          (preS[t + 1] << 3) +
          (preS[t + 2] << 2) +
          (preS[t + 3] << 1) +
          (preS[t + 4] << 0) +
          (preS[t + 5] << 4)];
      t = 4 * j;
      f[t + 0] = (k >> 3) & 01;
      f[t + 1] = (k >> 2) & 01;
      f[t + 2] = (k >> 1) & 01;
      f[t + 3] = (k >> 0) & 01;
    }

    // The new R is L ^ f(R, K). The f here has to be permuted first, though.
    for (j = 0; j < 32; j++) R[j] = L[j] ^ f[P[j] - 1];

    // Finally, the new L (the original R) is copied back.
    for (j = 0; j < 32; j++) L[j] = tempL[j];
  }

  // The output L and R are reversed.
  for (j = 0; j < 32; j++) {
    t = L[j];
    L[j] = R[j];
    R[j] = t;
  }

  // The final output gets the inverse permutation of the very original.
  for (j = 0; j < 64; j++) block[j] = L[FP[j] - 1];
}

char *crypt_r(const char *key, const char *salt, char *buf) {
  int i, j, c;
  int temp;
  char block[66];
  struct sched s;

  for (i = 0; i < 66; i++) block[i] = 0;
  for (i = 0; (c = *key) && i < 64; key++) {
    for (j = 0; j < 7; j++, i++) block[i] = (c >> (6 - j)) & 01;
    i++;
  }

  setkey_r(&s, block);

  for (i = 0; i < 66; i++) block[i] = 0;

  for (i = 0; i < 2; i++) {
    c = *salt++;
    buf[i] = c;
    if (c > 'Z') c -= 6;
    if (c > '9') c -= 7;
    c -= '.';
    for (j = 0; j < 6; j++) {
      if ((c >> j) & 01) {
        temp = s.E[6 * i + j];
        s.E[6 * i + j] = s.E[6 * i + j + 24];
        s.E[6 * i + j + 24] = temp;
      }
    }
  }

  for (i = 0; i < 25; i++) encrypt_r(&s, block, 0);

  for (i = 0; i < 11; i++) {
    c = 0;
    for (j = 0; j < 6; j++) {
      c <<= 1;
      c |= block[6 * i + j];
    }
    c += '.';
    if (c > '9') c += 7;
    if (c > 'Z') c += 6;
    buf[i + 2] = c;
  }
  buf[i + 2] = 0;
  if (buf[1] == 0) buf[1] = buf[0];

  return buf;
}

Name: Anonymous 2013-03-07 7:24

Compile against:

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv){

  char *input = "faggot";
  static char salt[3] = {0};
  static char buf[12] = {0};

  if (argc == 2 && strlen(argv[1]) > 2)
    input = argv[1];

  salt[0] = input[1];
  salt[1] = input[2];
 
  crypt_r(input, salt, buf);

  fprintf(stdout, "%s: %s\n", input, buf+3);

  return 0;

}

Above scheme is what shiichan uses. Not really, because Japense Quality Software, things like "<> are converted into &quot;&lt;&gt before being hashed, but since the hash output is only A-Za-z0-9, this doesn't matter. Enough for finding cycles.

Name: Anonymous 2013-03-07 7:53

>>108 back, was time for dinner & a spot of futurama ^^

for all n members of a period-n cycle, fn-1(x) = x
n-1, because we've started counting at f0

Name: Anonymous 2013-03-07 8:15

=) initial permutation also consists of 8 cycles of period-8... muahahaha =D

Name: Anonymous 2013-03-07 8:18

oh wait no probably not.. *wasn't paying attention again.. =. looks like it might be just 1 cycle..?

Name: Anonymous 2013-03-07 8:22

also kind of looks like a matrix transpose... interesting =)

Name: Anonymous 2013-03-07 8:33

much better off looking at fp (well, both really) since its just the inverse (and a bit clearer), yeah pretty sure its just one cycle..

IP is being as a translation type permutation (looks like they'll all be translations actually =) hmm

Name: Anonymous 2013-03-07 8:44

probably wrong there though, wasn't DES a sp-network? 6-bit substitutions somewhere in there..? they aren't very obvious though, ah nvm there they are lol, the S block..

Name: Anonymous 2013-03-07 8:57

expansion is just repeating every second pair of bits.. think i'm going to need a piece of paper ^^

Name: Anonymous 2013-03-07 8:58

>>118
I'm just working out a few cycles by hand, as well. It's taking a lot of paper.

Might be useful to make a program that uses gdb or something to print out a list of the operations performed on the arrays.

Name: Anonymous 2013-03-07 10:14

ITT: two idiots literally think they're going to cryptanalyse crypt, and that this is a smarter approach than an exhaustive search.

Name: Anonymous 2013-03-07 10:23

>>120
More productive than plain shitposting, Anonymous. Give it a try.

Name: Anonymous 2013-03-07 13:06

>>121
Is it really, though?

Look, there are 648 candidates for tripcode's fixed points ([a-zA-Z0-9./]{8}). Each of those can produce 649 ✕ 16 possible outputs, 64 ✕ 16 of which can be used to construct a fixed point input. That means that the chance of at least one fixed point existing is 63.21%.
Those odds are good enough that you should be looking for plain fixed points instead of cycles first, and it's been pointed out that you can do an exhaustive search in under a day.

Exploring for the sake of exploring is one thing, but don't outright waste your time.

Name: Anonymous 2013-03-07 21:35

>>120 do you think you could attack my 2048bit hash with an exhaustive search? ^^

Name: Anonymous 2013-03-07 21:52

few other little things.. Isn't finding a quine/cycle effectively a zero knowledge proof of a collision? (Neat huh?)
Substitution + Permutation = Hash + Translation.. but also (particularly with look-ups) if z = x hashed by y [z = y(x)], then z = y translated by x [also z=y(x)]..

Name: Anonymous 2013-03-07 22:11

though I haven't really seen a collisive translation before.. well, except as a bug ^^
So, i think S-block can be seen as either a fixed hash with variable input, or a variable translation with a fixed input..? =)

Name: Anonymous 2013-03-08 7:16

hey, so wait what this isn't a hash function..? xD

Name: Anonymous 2013-03-08 7:36

...unless its using D.E.S as the base of the hash..?
is it combining the encrypted blocks in there somewhere..?

Name: Anonymous 2013-03-08 8:00

>>123-127
You're a complete waste of space.

Have you considered reading a description of the algorithm you think you're going to cryptanalyse? It might be helpful.
crypt(3) repeatedly encrypts a block that starts out as 0, using the value being hashed to set the key and the salt to shit up the E-box a bit.

Name: Anonymous 2013-03-08 10:11

>>122

No, you cannot do an exhaustive search in under a day. What are you talking about? Even using the fastest implementation I know of, JTR's, I only get about ~5 million trips a second on an i3. Even with a recent, top-line CPU, and an optimized AVX algorithm, you'd get 50 million at best.

Even with the MTI GPU bruteforcer, it would take about a month with 2,000 dollars worth of GPUs.

I don't exactly have access to a supercomputing cluster.

Anyway, there's a chance it exists, but the ratio of fixed points over the space is absurdly low.

Cycles are easier to find since the probability of stumbling upon one randomly adds up the more rounds you do.

Doing some analysis to pick a ``better'' starting points would help. Even if it doesn't pan out, it's a reason to explore DES.

I'd check your numbers, as well.

Name: Anonymous 2013-03-08 10:35

>>129
Dude. Tripcode Explorer gets billions of trips per second on typical consumer hardware, and has for years. Get with the game.
My numbers are accurate.

Name: Anonymous 2013-03-08 10:40

>>130
Unless tripcode explorer was updated recently without me being aware of it, no it does not. It gets in the tens of millions at best on a CPU.

Here is a benchmark of Trip Explorer from late 2010: http://www.donutey.com/images/tripcodes/trip7.png

CPU performance has not gone up 100-fold in 3 years.

The fastest implementation is the one in MTY, which may be capable of performance in the billions with newer GPUs.

Name: Anonymous 2013-03-08 14:30

I can hear an EXPERT PROGRAMMER getting FUQQEN ANQERED in this thread.

Name: Anonymous 2013-03-08 14:37

>>130
My numbers are accurate.
I think he meant your dubs
HWBTC?

Name: Anonymous 2013-03-08 15:28

>>130
tripcode explorer and john the ripper uses http://www.darkside.com.au/bitslice/
inb4 jews

ordinary implementation of crypt looks incredibly slow, personally i couldn't get more than 2k t/s testing it while john and tripcode explorer have 1.5 m/s on the same pc, i could have some bottleneck though, i tried a couple different ways to generate passwords (random and trying all from 3 to 8 char long), sprintf or strcpy and two different implementations of crypt - built-in and source, the speed was +/- 5% of those 2k/s

Name: Anonymous 2013-03-08 20:11

>>134
Even with a pure-Python port of a 1980s version of crypt(8) I'm getting 7,400 trips per second. OpenSSL gets about 200,000 per core on the same machine. You're doing something very wrong.

Name: Anonymous 2013-03-08 22:51

>>128 i've looked at >>110, though i'm no expert C coder i can follow most of it..

So the key is constant?

Name: Anonymous 2013-03-09 4:27

>>135
python script run 8-12 k t/s on virtual machine on the same pc, 4-6 times faster than pure c with the same logic. so it's something about how c handles strings or rather how i cannot cope with it -_-
python's crypt module uses built-in linux crypt so the script itself just works with strings
still, crypt(3) is slow

Name: Anonymous 2013-03-09 6:07

>>136
The plaintext is constant. The key is the first eight characters of the input.

>>137
You're doing nothing to defeat the stereotype regarding people who can't figure out how to operate their shift key. Post your code so we can laugh at it.

Name: Anonymous 2013-03-09 6:24

>>138
i think stackoverflow is better place for you than prog, you want to improve other's code not even being asked for. if i cared of c and wanted advice i'd post my code there

also, out of curiosity, how fast is your implementation in pure c? i mean with crypt(3) algorithm

Name: Anonymous 2013-03-09 7:54

>>139
Like I said, my implementation with OpenSSL's DES_crypt gets about 200,000 trips per core. If you're asking how fast glibc's crypt is on my machine, I don't know and I don't intend to find out; there is no GNU software in my house and I intend to keep it that way. I can tell you now, though, that GNU's crypt is the slowest C implementation out there nowadays.

I asked for your code so we could laugh at it, not so I could improve it. If you're only getting 2,000 trips per seconds even with GNU crypt, you're beyond help.

Name: Anonymous 2013-03-09 7:59

>I can tell you now, though, that GNU's crypt is the slowest C implementation out there nowadays.

yes, but how much is it slower exactly. i don't care of your openssl implementation, anyway it's far far, tens times, worse worse than the algorithm which tripcode explorer and john the ripper use

Name: Anonymous 2013-03-09 8:42

>>141
No fucking shit. Are you seriously still under the impression you can teach anyone here anything about tripcodes?

Name: Anonymous 2013-03-09 9:28

>>142

lolwhat. i just asked how much faster than 2k t/s you think crypt(3)-based tripcode bruter could be being properly written in pure c and when you told about your ssl implementation instead i mentioned that it's neither what i asked nor something impressive

it's you who are trying to play c guru here

Name: Anonymous 2013-03-09 9:30

>>143
You really are a waste of space. Stop shitting up my textboard.

Name: Anonymous 2013-03-09 10:18

>>144
friendly tip, next time when you don't know the answer you can say something like 'dunno, but i guess ten times faster or so' or just be silent

Name: xyz !GmgU93SCyE!Onj4uB4yFGoqARg 2013-12-29 7:38

i cant use that

Don't change these.
Name: Email:
Entire Thread Thread List