= Сообщение: 3599 из 7125 ====================================== FTSC_PUBLIC = От : mark lewis 1:3634/12.73 08 Mar 18 07:21:14 Кому : Alexey Vissarionov 08 Mar 18 07:21:14 Тема : FTS-1027 (BinkP 1.0 CRAM) FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.73+5aa12d02 На : area://FTSC_PUBLIC?msgid=2:5020/545+5aa0dd7c = Кодировка сообщения определена как: CP437 ================================== ==============================================================================
On 2018 Mar 08 09:09:44, you wrote to Rob Swindell:
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
AV> 8 < 16 < 64
RS>> and probably all any implementation should *ever* send if they wish RS>> to be compatible will all known existing implementations.
AV> What if they wish to be compatible with the published standard based on AV> very popular reference implementation?
you miss the point... that point being that all current implementations transmit exactly 16 bytes... no more, no less... the spec is 13 years old... common practise does not meet the spec and the spec is not documenting common practise... at least one mailer refuses to work properly with CRAM-MD5 != 16 bytes... a sample of 388450 CRAM-MD5 strings taken over three years shows ALL of them are 16 bytes (aka 32 hex characters) long... none are shorter... none are longer until recently when one implementation used the whole allowed space and found this problem...
you also say about MD5 and SHA1 being compromised... true but those are the only ones the spec lists... if there are others, where are they listed and their implementation decribed?
the posting is made here to bring the problem to the attention of the FTSC so the documentation can be reviewed and updated...
)\/(ark
Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... When I get hungry, things die. --- * Origin: (1:3634/12.73)
