On 05/17/2011 06:14 AM, brill...@viatech.com.cn wrote: > Thanks for your reply. > >> I have made enhanved versions of the SHA support including partial >> Nano support and proper optimizations for the earlier variant that >> does finalizing hashing only. They are both on OpenSSL RT. Latest >> versions of my patch set for 1.0-branch is at: >> http://git.alpinelinux.org/cgit/aports.git/tree/main/openssl >> >> Please take a look at my SHA patches, they should implement everything >> properly. RNG patches you might need to fix. > > In fact, I have read your patch for SHA, and it seems to complete everythin. > So my patch for SHA isimplemented based on it, and just a few modification is > applied. > If you don't mind, I would like to send my patch to you as soon as I finish > it.
Oh, ok. I can review at least the SHA part if needed. But you do still need to get attention of some openssl developer to get the code committed. >>> 2. The"via-mont.pl"seems no to be used, is there any taboo >> against it or some bad history I are missing ? If yes, please tell me. >> >> I think the OpenSSL core code is missing montgomery multiplication >> abstraction. It seems to be compile time option only to pick which >> implementation is used. So to get the montgomery stuff enabled by >> default, you'd probably also need to implement abstraction support for >> it. > > Thank you very much for your advice. > I just have a basic knowledge of OpenSSL, so I do not understand what the > "abstraction" means. I guess you mean that montgomery multiplication is not > exported to developers as a interface, such as engine, so I have to implement > by myself. If it is, that's really a tough problem for me. Correct. To do it properly, an interface is needed. However, that might be hard to get in. I think this is something the core developers needs to comment on... All the existing assembly stuff just do multiple implementations in single file. E.g. bn-586.pl has both: SSE2 and regular implementation, and a runtime check to see which one to use. I'm not sure if it's worth the trouble to convert it as engine module interface. But I think it'd make a lot sense to convert these essential functions to function pointers. So for e.g. bn_mul_mont symbol we should probably have: - bn_mul_mont (keep as function with basic cpu implementation for backwards compatibility) - bn_mul_mont_padlock (padlock implementation) - bn_mul_mont_sse2 (sse2 implementation) - bn_mul_mont_resolve (check CPU caps and commandline args, and changes the below symbol to best suitable version) - bn_mul_mont_ptr (or similarly named, which at startup points to _resolve) This also means converting most bn_mul_mont calls in the openssl code to bn_mul_mont_ptr calls. But this is slightly intrusive change, so better check first with core developers. >>> 3. If I want to submit a patch which implements modular >> multiplication and modular exponentiation by calling VIA PadLock >> hardware instruction, should I write it in a individual Perl script >> like "via-mont.pl", or wrap it in the RSA/DSA method to be implemented >> in PadLock engine ? Or both are required? >> >> They work on different levels of the openssl library. >> Implementing via-mont.pl would be probably easier. Doing the >> implementation only in RSA/DSA method of the padlock module would >> enable the multiplication acceleration only for certain operations of >> the library. So I'd probably go with via-mont.pl and adding the >> required abstraction layer. >> > That's a good news for me if you would like to go with the work for > abstraction layer. > Exactlly speaking, I just want to "padlock" engine in OpenSSL can use the > hardware-implemented modular multiplication and modular exponentiation, so I > prefer to doing the implemenation in RSA/DSA method of padlock engine. > However, I have to use some individual asm files in my implementation such as > supporting for WIN32 or WIN64, so perl script like "via-mont.pl" is also > needed to generate cross-platform code. Do you have any suggestion on my > implemenation? Thanks ! I think that's why they went with perl: it is used to produce the real assembly file for the platform which is then compiled using real assembler. So yes, both windows and linux work with the perl assembly. I think when openssl started there was no cross-platform assemblers like nasm (which might be more sensible option nowadays). - Timo ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
