TRIPCODE QUINE!!!!

Can you hack it /PROG/?

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

>>121
Is it really, though?

Look, there are 64⁸ candidates for tripcode's fixed points ([a-zA-Z0-9./]{8}). Each of those can produce 64⁹ ✕ 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.

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

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)]..

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..? =)

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

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

>>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.

>>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.

>>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.

>>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.

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

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

>>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

>>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.

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

So the key is constant?

>>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

>>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.

>>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

>>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.

>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

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

>>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

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

>>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

i cant use that