> 1) Openssl works correctly (no crash, correct detection), as far as I > can judge. By error-prone I mean, very defensively, that I (or > others) could make a mistake, or that future versions of openssl > could not work exactly the same way.
Well, this is effectively argument in favour of denying the control over capability vector[s]. I mean following this logic you should have no way to affect the outcome, not programmatically nor through environment variable. Because user can screw it up :-) > 2) I would agree with your argumentation. But some customers want > this anti-feature (no aes-ni), arguing that exactly those instruction > are not trustworthy. And the customer is always right. And following this logic no instruction is trustworthy, be it aesenc or any other, say pshufb used in bsaes, or even better example multiplication used in e.g. RSA. There is exactly as much proof of correctness of either. If you are concerned about using any specific instruction you should have bigger concern about using that processor at all. Or in other words if trusting a processor manufacturer is problematic, then you should manufacture own processor, with or without AES-NI, which OpenSSL will dutifully detect and abstain from calling procedures that would crash... I'd argue that even this ticket can be closed with "use no-asm" resolution. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
