Subj : FTS-1027 (BinkP 1.0 CRAM)
To   : Alexey Vissarionov
From : mark lewis
Date : Thu Mar 08 2018 07:21 am


 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)

.