Hi >> Unfortunately I don't think it is as simple as that. If I understand the >> previous change correctly, Emilia has deliberately removed the error message >> as >> part of work to protect against timing attacks. The very act of adding an >> error >> to the error queue could introduce a measurable timing difference which >> (theorectically) could be exploited. > I think we need to clarify the documentation about what we expect > people to do when things like a padding error are detected. They > too need to respond in a way that doesn't leak any information > like time or which error was detected, or even that an error was > detected. This modification had some impact on softwares expecting to have an error code (in this case 06065064 but got only zeros). Of course it can be modified on the software side, but it is quite surprising to move to a fully undefined error code. My use case (actually node.js use case) was not directly a padding error, but a unit test checking the case of encrypting and decrypting with different keys. Having no "Bad Decrypt" error code is quite misleading.
Since if this function fails under different circumstances (final block length error, etc.), information about the reason of the failure are given to the caller it was surprising for a "non crypto guy" to have no error code in this specific case. Having return code A or return code B seems the same since this error code (A vs B, or 06065064 vs 00000000) can happen in only one case in this function. An error detected after the padding check loop. On the other hand there is the timing argument. I fully understand that pushing the error code before returning zero will slightly change the duration of the function. I was just hoping that impact would be negligible since it is outside of the "for" loop (which will have a constant execution time). I was certainly wrong and forgetting to take things in consideration, but if not I would prefer to have an error code I can use in my software :) Thus a last question... Would it be possible to have a constant time way to end this function by pushing or not an error message in queues ? I mean something like calling EVPerr anytime, pushing or not an actual error code. So it could return zero or not, having an error code in the queue if needed. And execution time would always be the same. I think this would help solving this issue, and this could help on situation like having a method doing something like : 1. call EVP_DecryptFinal_ex 2. check if return code is zero 3. push an error code to the queue 4. and return to its caller Such case would certainly lead to the same security risk as pushing the error from within EVP_DecryptFinal_ex method, right ? And it looks like it happens at least in function PEM_do_header (pem_lib.c at line 476 and following). Should this be removed also ? Kind regards, -- William http://www.wbonnet.net http://france.debian.net Association Debian France http://www.opencsw.org Community SoftWare for Solaris ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
