> I have been following the recent LibreSSL developments quite active and > would like to contribute. > > I have some questions: > > - The accelerated assembly code for the crypto, is that gonna stay?
Of course. Why do you think anyone would try to break code which works? > - Why not use uint32_t and uint64_t all over (incl the APIs) instead of > custom XX_ULONG stuff? I believe Miod is working at improving this. It situation is far more complex than you could believe. My brain recoiled when I started to understand the classes of theoretical machines being supported. > AFAIK uint32_t and uint64_t are guaranteed 4 and 8 bytes long. Sigh. You don't see to understand the OpenSSL tree. It contains support for machines that have already turned into gas at the bottom of garbage dumps. > - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, > des etc.)? What problem are you trying to solve? > - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Why not? What is broken with it? Is this on the critical path? Do you think that introduces scary risk for people? Please read the current commit logs to understand the focus of the task.
