>> 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?
Because it is a huge amount of code. I am naieve about this subject and *thought* that todays compilers do a lot better optimising than in the past and that therefore the assembly code is a hurden instead of an asset. >> - 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. I thought that the idea of LibreSSL was to get rid of all the obsolete OpenSSL stuff. With (u)int*_t that could work. But I agree with the sigh. >> - Can we eliminate "#ifdef OPENSSL_NO_AES" and that for all the crypto (bf, >> des etc.)? > > What problem are you trying to solve? Eliminating #ifdefs. That's all. >> - 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? It is just a question. I looked at aes_locl.h and found that 4 #defines are not used (MAXKC, MAXKB, MAXNR and u16) and it also #includes 3 header files that aren't used in this header file. So I thought that maybe this macros is something of the past and could be eliminated also. With it is a lot of code. That's why I asked. > Please read the current commit logs to understand the focus of the task. Ok. @Miod Vallat, thanks for the info.
