> I really shouldn't have to say this, but just because something hasn't > been > reported doesn't mean it's not a real problem. Someone could easily be > affected > by one of these bugs where crypto drivers produce the wrong output, and > never > notice it because their use case doesn't involve checking the output > against > another implementation. Or, perhaps they noticed but never reported it > upstream. Or perhaps they didn't have the time or skill to debug the > problem so > just they disabled the broken driver, or used No Crypto instead. > > That's why we have tests -- so bugs can be detected immediately rather > than > maybe years out in the field after causing critical security > vulnerabilities. > I understand where you're coming from. My first assumption was that perhaps this corner of the API was not used at all, in which case the specification and testmgr could simply be updated to remove it. I suppose that's not entirely the case. But the few (?) users relying on this functionality could still be changed to use an alternative approach such as extracting the output IV from the packet data so any uses NOT needing this output IV are not bothered with it. That may actually help the performance of software implementations as well. Somehow, somewhere, that data must be duplicated, which takes time. In any, we already came up with the alternative approach of having some kind of "I_DONT_NEED_IVOUT" flag provided by the user. Regards, Pascal
