Page 5 of 5
Re: On-line engine blitz tourney July
Posted: Mon Aug 06, 2018 7:49 pm
by 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.
Re: On-line engine blitz tourney July
Posted: Mon Aug 06, 2018 8:48 pm
by 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!
Re: On-line engine blitz tourney July
Posted: Mon Aug 06, 2018 10:11 pm
by Joost Buijs
hgm wrote: ↑Mon Aug 06, 2018 8:48 pm
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.
Re: On-line engine blitz tourney July
Posted: Mon Aug 06, 2018 10:54 pm
by 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