= Сообщение: 3597 из 7125 ====================================== FTSC_PUBLIC = От : Rob Swindell 1:103/705 07 Mar 18 18:52:55 Кому : All 07 Mar 18 18:52:55 Тема : FTS-1027 (BinkP 1.0 CRAM) FGHI : area://FTSC_PUBLIC?msgid=29051.ftsc_pub@1:103/705+1f064d02 = Кодировка сообщения определена как: ASCII ================================== Ответ: area://FTSC_PUBLIC?msgid=2:5020/545+5aa0dd7c ============================================================================== In the development of a new binkp implementation (http://wiki.synchro.net/module:binkit), *we* came across a deficiency in the FTSC document: FTS-1027.
Regarding this text:
1.3 Generating and Transmitting Challenge Data ----------------------------------------------
Size and contents of challenge data are implementation-dependent, but it SHOULD be no smaller than 8 bytes and no bigger than 64 bytes
Let it be known that the reference binkp implementation, binkd, has (apparently) only ever sent a 16 byte CRAM challenge (no more, no less) and some implementations (e.g. Internet Rex) only work (succesfully authenticate) if the received challenge is exactly 16 bytes (no more, no less).
There's no mention of a 16 byte CRAM challenge (32 hex characters) in the specification, but 16 bytes appears to be exactly what all existing implementations actually send and probably all any implementation should *ever* send if they wish to be compatible will all known existing implementations.
I just felt this should be documented, if it isn't already, by the FTSC.
Credits to Mark Lewis and Stephen Hurd. --- SBBSecho 3.03-Win32 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
