TRIPCODE QUINE!!!!

Can you hack it /PROG/?

anus

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

>>82
Kids say the darndest things!

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

american public education at its finest

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

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

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

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

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

64⁸ = 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.

>>90
^^ faggot

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

>>91
Imageboard effluent.

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

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

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

>>96
there there

>>97
that that

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.

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?

>>100
J was the set of translation inputs j_i that are applied to each x_i in X for i = 1, ..., N, where x_i + j_i = y_i 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 j_i for x_i 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.

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

>>101

Err, sorry. Mistake. The following:
where x_i + j_i = y_i in Y.

Should be:

where (x_i + j_i) mod N = y_i 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.

>>103

``Closed string'', perhaps.

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

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

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

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

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

x₁ = f(x₀) = f[sup]0(x)
x₂ = f(x₁) = f[sup]1(x)
x₃ = f(x₂) = f[sup]2(x)
...
x_n+1 = f(x_n) = 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 fⁿ(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:
fⁿ(X) set of all possible unique cycles
and C is equal to A, taking away all the elements that have a vector c₀ = {v₁, v₀, ... v_n} where v₁ 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.

>>108

Fuck.


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

x₁ = f(x₀) = f⁰(x)
x₂ = f(x₁) = f¹(x)
x₃ = f(x₂) = f²(x)
...
x_n+1 = f(x_n) = fⁿ(x)

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

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.

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

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

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

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

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

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

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

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

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

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