RS> In the development of a new binkp implementation RS> (http://wiki.synchro.net/module:binkit), *we* came across a RS> deficiency in the FTSC document: FTS-1027. RS> Regarding this text: RS> 1.3 Generating and Transmitting Challenge Data RS> Size and contents of challenge data are implementation-dependent, but RS> it SHOULD be no smaller than 8 bytes and no bigger than 64 bytes
64 to 512 bits... that resembles one pretty good cryptographic transform.
RS> Let it be known that the reference binkp implementation, binkd, has RS> (apparently) only ever sent a 16 byte CRAM challenge (no more, no RS> less)
IIRC, that's some random data whitened by MD5 hash function. Now MD5 is proven to be unsafe(*), so the implementations should replace it with not-yet-broken crypto-safe functions like SHA2 or Skein.
RS> and some implementations (e.g. Internet Rex) only work (succesfully RS> authenticate) if the received challenge is exactly 16 bytes (no more, RS> no less).
That's a bug. Have you reported it to the developers of those mailers?
RS> There's no mention of a 16 byte CRAM challenge (32 hex characters) RS> in the specification, but 16 bytes appears to be exactly what all RS> existing implementations actually send
8 < 16 < 64
RS> and probably all any implementation should *ever* send if they wish RS> to be compatible will all known existing implementations.
What if they wish to be compatible with the published standard based on very popular reference implementation?
RS> I just felt this should be documented, if it isn't already, by the RS> FTSC.
Over 80% of all IBN-capable systems use binkd, so its' behavior still is the current practice, which is exactly documented by FTSC.
