ntpd requires stripping out the HEX: prefix from SHA1 and SHA256 hex keys to interwork with chrond server

I am new to this business, and could not find the answers to the following: - In order for ntpd client to sync up with chronyd server using a hex key value, I found that I need to strip out the HEX: prefix from the hex keys used by chronyd before I upload this key file to my ntpd client. Is this is a known fact about this type of interworking, or a specific issue with my client? - ntpd requires full key length when using hex keys, i.e., SHA-1 has to be 40-hex symbols, SHA-256 64-hex symbols. Is this design intent of ntpd, and a known practice used by IT when generating and configuring ntpd keys? - ntpd implementation assumes (even in latest version ntp4.2.8p17) that if strlen(key) 20 characters, then it is treated as hex format. 1) Why 20 is the boundary limit to make this segregation? Gathering from RFCs, MD5 digest is 128 bits, SHA-1 digest is 160 bits, SHA256 is 256, etc. Was the 20-characters limit based on early implementation of ntpd when MD5 and SHA-1 were only on mind? 2) Is this 20-character limit known and expected by IT folks in industry, and accepted as a de-facto standard? 3) What repercussions can you think of if this limit is changed to be based on key type, i.e., if SHA-1 then limit is 20, if SHA-256 then limit is 32,... Could this cause backward compatibility issues?