I am in the late stages of implementing DKIM in my mail server package, but have run into problems with the calculation of body hashes.
I have developed a testing tool that calculates the various inputs required for a DKIM signature - headers in the correct order, body hash, placeholder DKIM-Signature header and so forth. But when I test this tool against sample messages from my mailbox from a variety of mail service suppliers, the body hash I calculate seems invariably to be different from the bh= tag pair in those sample messages. It does not seem to matter if the message specifies simple or relaxed canonicalization, and I have repeatedly gone over my code to make sure I am presenting the proper data to the hashing algorithm (for simple body canonicalization, I understand this to be nothing more than presenting the lines in the body unchanged except for normalization to network line terminations if necessary, and making sure that any CRLF pairs beyond the last line containing actual message data are not passed to the algorithm). I am generating the body hash from the raw hashing data and rendering it in BASE64. To keep things as simple as possible, I have been choosing examples that have no l= tag and hashing the entire body. I am confident in my SHA-256 implementation, but in the name of being thorough, have compared its output with no fewer than six online hash generators, all of which agree with the output my implementation produces. The only thing I could point to here is that the code from which my SHA-256 implementation is taken claims conformance to FIPS-180-2, where RFC6376 section cites FIPS-180-3; as far as I have been able to determine, SHA-256 did not change between these two versions of FIPS-180 - the 2008 (3) variant included SHA-224, but did not alter any of the characteristics of SHA-256 from the 2004 (2) variant. I stress that this problem has nothing to do with signing, or with key generation - it is simply the calculation of the body hash. I am not at this stage working on testing the header hash calculation - there are more moving parts required there, and I am working on the assumption that whatever I might be getting wrong in the body hash calculation I am probably also getting wrong in the header calculation: I am hopeful that fixing the one will make dealing with any issues in the other rather easier. I have gone through the errata for RFC6376 and have noted in particular the amendments to the pseudocode in section 3.7. There do not appear to be other errata that would have a direct bearing on this problem. I was wondering if anyone on this list might be willing to help with either of two things that could assist in working out what's going on: 1: Any advice on common traps into which new implementors might fall. 2: Any collections or examples of completely definitive message bodies and their matching hash calculations (I cannot rule out the possibility that the messages I am using as samples may have been somehow altered, or the possibility of them having invalid bh= tag pairs). Having incontrovertible examples I can use in testing would remove one area of doubt. Any assistance anyone might be willing to offer would be gratefully received. -- David Harris -- ------------------ David Harris -+- Pegasus Mail ---------------------- Box 5451, Dunedin, New Zealand | e-mail: [email protected] Phone: Number provided on request only. Thought for the day: A diplomat is a man who can convince his wife she'd look stout in a fur coat. _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
