Hitoshi Mitake <mitake@xxxxxxxxxxxxxxxxxxxxx> writes: > Because strlen(challenge_64) is the upper limit of length of challenge. > So tail part of challenge may not be filled by EVP_DecodeBlock(), > non-zero filled buffer produces not NULL terminated string. > I've confused once by this problem before. If you know the length of the decoded thing, then you would just know how much to hash. Doesn't the EVP_DecodeBlock() give you that number? Why do you need a NUL termination to begin with? Because you pretend as if you do not have the actual length, you run strlen() instead. I am not that familiar with the API to EVP_* functions, but I'd be surprised if it were designed in such a stupid way to force you to write into a pre-zeroed buffer. By the way, if you use strlen() on a pre-cleared and overallocated buffer, doesn't your ENCODED_SIZE(n) have to be one byte longer than what you are computing? Looking for EVP_DecodeBlock in http://www.google.com/codesearch seems to find usage examples of varying quality. Your favorite isync-0.5 stores the result in "len", but it entirely ignores it and does the same silly calloc() and strlen(). Usage example in OpenSSL's own x509spki stores the return value in spki_len and uses that as the length of the stuff to call another function, which looks much more reasonable. From this observation and a bit of reading of the manual, my understanding is that the function gives you the number of bytes written in the buffer. So does EncodeBlock(), I would think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html