On-line engine blitz tourney July

[hgm]

I think I got it! Openseal encrypting is this:

Code: Select all

int crypt(char *s,int l)
{
        int n;
        struct timeval tv;
        s[l++]='\x18';
        gettimeofday(&tv,NULL);
        l+=sprintf(&s[l],"%ld",(tv.tv_sec%10000)*1000+tv.tv_usec/1000);
        s[l++]='\x19';
        for(;l%12;l++)
                s[l]='1';
#define SC(A,B) s[B]^=s[A]^=s[B],s[A]^=s[B]
        for(n=0;n<l;n+=12)
                SC(n,n+11), SC(n+2,n+9), SC(n+4,n+7);
        for(n=0;n<l;n++)
                s[n]=((s[n]|0x80)^key[n%50])-32;
        s[l++]='\x80';
        s[l++]='\x0a';
        return l;
}

So it pads the line with '1's to a multiple of 12, so it can do the transpositions, and then appends a 0x80 and a linefeed. The crux is the character in front of the linefeed. From this you have to strip the sign bit, and what is left (0 here) is then the offset in the key you have to use for decrypting the message. The official timeseal seems to use random numbers here, both for the padding and for the offset.

[hgm]

OK, the server is back up, and now does all timeseal decoding internally. It still spawns the decoder process, but just never uses it. There is some logic there for when to attempt decoding, though, and I don't want to remove that before I have figured out what exactly it does.

I understand now that my previous fix for preventing crashes of the timeseal decoder, namely clipping the line to a size that doesn't crash the decoder, will not really work satisfactory. That is, it will prevent the crash, but because the end will be (with time-stamp and key offset) missing it cannot possibly decode the line. So the ICS will think the user is suddenly sending non-timeseal encrypted data, and will switch off decrypting for that user for the future. I guess what I should really do is just ignore the too-long line. Or, now that I do decoding myself, make sure it works on lines of any length.

But at least for now, we should be 'back in business'. Feel free to try it!

[Joost Buijs]

OK, the server is back up, and now does all timeseal decoding internally. It still spawns the decoder process, but just never uses it. There is some logic there for when to attempt decoding, though, and I don't want to remove that before I have figured out what exactly it does.

I understand now that my previous fix for preventing crashes of the timeseal decoder, namely clipping the line to a size that doesn't crash the decoder, will not really work satisfactory. That is, it will prevent the crash, but because the end will be (with time-stamp and key offset) missing it cannot possibly decode the line. So the ICS will think the user is suddenly sending non-timeseal encrypted data, and will switch off decrypting for that user for the future. I guess what I should really do is just ignore the too-long line. Or, now that I do decoding myself, make sure it works on lines of any length.

But at least for now, we should be 'back in business'. Feel free to try it!

Well done, it works!

There is a lot of unknown functionality in the timeseal daemon, I decompiled it with Hex-rays, and there are dozens of tables (which looks like random numbers and others which look like indices) and many subroutines, I wonder where all this stuff is needed for.

If you wish I can mail you the decompiled file, but it will take a lot of effort to find out what everything does.

[jdart]

I'm glad there is progress on a fix.

I found this on github, it is an open source implementation:

https://github.com/fbergo/zseal

and it says it implements "v2" of timeseal and that openseal implements "v1." I am not sure what the difference is, but I guess FICS at least supports both?

--Jon