SID_AUTH_INFO Signature

[Camel]

Well, it's 128 characters. That means that there's only 10^128 different possibilities. It shouldn't take more than a few hours to generate the one for your IP.

And since it's mod, I think there may be more than one correct number.

No. Just no.

It's 8^128, actually. That would take an astronomically long time to guess. Assuming you have a 2GHz processor, and you could generate and test a key in a single cycle, google calculator says:

8^128 / 2GHz in years = 6.2430045 × 1098 years

Without the private key, there's no point trying to generate one.

[sdfg]

Correct me if i'm wrong, but using the birthday attack principle couldn't you get that down to 8^64?

[iago]

Correct me if i'm wrong, but using the birthday attack principle couldn't you get that down to 8^64?

No, I don't think the birthday attack applies here, since you can't get them to encrypt arbitrary plaintext. Or something.

[Joe]

You can find an implementation somewhere on my wiki or, if nothing else, in JavaOp2.

<edit>

    // I don't really like this function being here, but I can't think of anywhere else it might belong :-/
    private void checkServerSignature(byte []sig, byte []ip) throws IOException
    {
        // The constants
        BigIntegerEx key = new BigIntegerEx(BigIntegerEx.LITTLE_ENDIAN, new byte[] { 0x01, 0x00, 0x01, 0x00 });
        BigIntegerEx mod = new BigIntegerEx(BigIntegerEx.LITTLE_ENDIAN, new byte[] 
        { 
                (byte) 0xD5, (byte) 0xA3, (byte) 0xD6, (byte) 0xAB, (byte) 0x0F, (byte) 0x0D, (byte) 0xC5, (byte) 0x0F, (byte) 0xC3, (byte) 0xFA, (byte) 0x6E, (byte) 0x78, (byte) 0x9D, (byte) 0x0B, (byte) 0xE3, (byte) 0x32,
                (byte) 0xB0, (byte) 0xFA, (byte) 0x20, (byte) 0xE8, (byte) 0x42, (byte) 0x19, (byte) 0xB4, (byte) 0xA1, (byte) 0x3A, (byte) 0x3B, (byte) 0xCD, (byte) 0x0E, (byte) 0x8F, (byte) 0xB5, (byte) 0x56, (byte) 0xB5,
                (byte) 0xDC, (byte) 0xE5, (byte) 0xC1, (byte) 0xFC, (byte) 0x2D, (byte) 0xBA, (byte) 0x56, (byte) 0x35, (byte) 0x29, (byte) 0x0F, (byte) 0x48, (byte) 0x0B, (byte) 0x15, (byte) 0x5A, (byte) 0x39, (byte) 0xFC,
                (byte) 0x88, (byte) 0x07, (byte) 0x43, (byte) 0x9E, (byte) 0xCB, (byte) 0xF3, (byte) 0xB8, (byte) 0x73, (byte) 0xC9, (byte) 0xE1, (byte) 0x77, (byte) 0xD5, (byte) 0xA1, (byte) 0x06, (byte) 0xA6, (byte) 0x20,
                (byte) 0xD0, (byte) 0x82, (byte) 0xC5, (byte) 0x2D, (byte) 0x4D, (byte) 0xD3, (byte) 0x25, (byte) 0xF4, (byte) 0xFD, (byte) 0x26, (byte) 0xFC, (byte) 0xE4, (byte) 0xC2, (byte) 0x00, (byte) 0xDD, (byte) 0x98,
                (byte) 0x2A, (byte) 0xF4, (byte) 0x3D, (byte) 0x5E, (byte) 0x08, (byte) 0x8A, (byte) 0xD3, (byte) 0x20, (byte) 0x41, (byte) 0x84, (byte) 0x32, (byte) 0x69, (byte) 0x8E, (byte) 0x8A, (byte) 0x34, (byte) 0x76,
                (byte) 0xEA, (byte) 0x16, (byte) 0x8E, (byte) 0x66, (byte) 0x40, (byte) 0xD9, (byte) 0x32, (byte) 0xB0, (byte) 0x2D, (byte) 0xF5, (byte) 0xBD, (byte) 0xE7, (byte) 0x57, (byte) 0x51, (byte) 0x78, (byte) 0x96,
                (byte) 0xC2, (byte) 0xED, (byte) 0x40, (byte) 0x41, (byte) 0xCC, (byte) 0x54, (byte) 0x9D, (byte) 0xFD, (byte) 0xB6, (byte) 0x8D, (byte) 0xC2, (byte) 0xBA, (byte) 0x7F, (byte) 0x69, (byte) 0x8D, (byte) 0xCF
        });
        
        // Do the calculation
        byte []result = new BigIntegerEx(BigIntegerEx.LITTLE_ENDIAN, sig).modPow(key, mod).toByteArray();
        
        for(int i = 0; i < 4; i++)
            if(result[i] != ip[i])
                throw new IOException("Error! Server failed validation check!");

        for(int i = 4; i < result.length; i++)
            if(result[i] != (byte) 0xBB)
                throw new IOException("Error! Server failed validation check!");

    }

Think you can figure it out from there?

Fixed?

[Camel]

Correct me if i'm wrong, but using the birthday attack principle couldn't you get that down to 8^64?

The birthday attack principle is based on the idea that hashing sqrt(hash strength) variations of each of two different inputs will (probably) result in a hash collision. A classic example is getting a digital signature on an evil message by requesting a signature on sqrt(strength) variants of an innocent message, and then testing each of those signatures for collision with sqrt(strength) variants of an evil message.

There are still O(strength) comparisons, simply fewer hashes.

I don't think the birthday attack applies here, since you can't get them to encrypt arbitrary plaintext. Or something.

The reason iago gave is sufficient to preclude the possibility of performing a birthday attack, but there's an even better reason: what the client expects to see is that the hash itself matches the IP address, not the message. The very nature of the birthday attack is finding hashing collisions, but the hash is invariant.