Speaking for myself here, but as far as LibreSSL is concerned, I'd say my opinion has a certain weight.
> - The accelerated assembly code for the crypto, is that gonna stay? Yes. Including existing code for platforms OpenBSD itself does not run on (e.g. s390). > - Why not use uint32_t and uint64_t all over (incl the APIs) instead of > custom XX_ULONG stuff? I am undecided about this. I have started doing this in one of my trees, and found the result no more readable than the initial code. These ALGORITHM_LONG types stress the fact that they are internal to the algorithm and should not be used (or scarcely used) in public interfaces. > - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, > des etc.)? In the apps, yes, eventually, at least for the algorithms no serious crypto library can afford not embedding. > - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Yes. I am currently working on benchmarking the various code generation option, algorithm by algorithm and platform by platform, to pick the best possible defaults, and it is likely that some platforms will perform better with that define, while some platforms won't. On the other hand, I am seriously considering getting rid of MD32_XARRAY (which was only used for HP's compiler on HP-UX), but, again, not until I've checked the generated code and its performance. Miod
