I've done this sort of thing back before 2000. I'd label my approach back then as 'force brutish' as it was a mix of using the build system and some code changes.
The trick is to search the configure system for a *hardware* (CPU!) which is identical or at least very similar to your embedded one. Do an initial cross-compile and expect lost of trouble along the way, but that's okay. TIP for memoryspace-challenged systems (such as embedded systems): check out all the noxyz options in the configure script (and grep for the OPENSSL_NO.* #defines which are thus set up this way) to ensure you already have a minimal sized build. You may need to add extra #defines to cut out more bits of OpenSSL code when the space is really really tight in there, but that need was much bigger back in Y2K as OpenSSL had fewer sections that way than it has today. The next part of the trick was twofold: I wrote a shell script which find/grep-ped the source tree and sed-ed all the system header files in there according to a sed script I set up. After all, few embedded boxes like that have such headers as unixstd.h (obviously), but you will find on embedded systems like that, which often lack a RTL or only a minimal subset, that you'll have to 'treat' all the system #includes. So I wrapped them in conditional compilation code (IIRC) and then made sure the embedded system-targeting makefiles would include that #define in the compiler invocation. Then the other part is concocting a posix-like RTL API + implementation of your own: for example, OpenSSL uses the FILE stream I/O API (fopen/fread/fclose/etc.) in some places, so you'll have - when you need those bits - to 'roll your own', e.g. by writing those functions which address a memory area in Flash memory instead, for example. It is highly dependent on your embedded system, after all. When you are 'clean' about it, you might want to add your own supported systems in the configure platform tables. This then becomes an iterative process, where you re-run configure, check linker reports for missing system APIs demanded by OpenSSL and meanwhile check you've got the bits that are important to you and none of the rest. And any which way I turn this: as long as your embedded systems are not supported in the official distro, you'll always have some sort of merging to do. I 'solved' this by creating a combo of a UNIX diff/patch file for the internal tweaks and a automated script which would do all the heavy munching of those system header file #includes and other 'generic / system' bits in the code tree. The added bonus of that was that it was 'export safe' at the same time as there wasn't a single line of crypto in the kit. My project was based on the (useful) assumption that this code would always be *cross-compiled* from a Unix host system, so awk, sh and such were fine. This was commercial work and the NDA never got lifted, so I can't share the code, even if I could, but I hope you now have a good idea about how one could do this. One style. It has been done, and it worked, for several embedded embedded platforms, including ARM. The company I did this for was EbsNet (EtcBin) : http://www.ebsnetinc.com/software-documents.php?id=66 I haven't kept track really, so I don't know if they still use my work of old as a base for their current product as it seems they've MSWin stuff in there as well now. Heck, it's been 9 years. Or was it 10? Anyway, despite you say you don't need the SSL part, they always offered full source code as part of their products, so you might want to ask them about it. I know they already supported ARM back then, so I would be amazed when they'd not have that anymore. Often paying for [part of] the work that way may be cheaper than you doing the exercise all over again yourself. (And yes, I am aware they offer an SSL stack, but if it still is OpenSSL-based, they VERY probably have the option to cut out the SSL part entirely and thus have you compile only the RSA bits.) Now that I checked their site, I see almost all the folks I worked with back then are on the about page photograph. Nice bunch, very friendly. Loved being there. (Since you picked OpenSSL as your starting point, I assumed a few things. When you just want RSA code and no particulars about it, there is the old rsaref code around on the net and then there's the various crypto libraries, i.e. the ones _without_ SSL, such as cryptlib (from Peter Gutmann IIRC). Me, I'm an OpenSSL adept, so I don't bother with the others. I use it for all things crypto overhere.) -- Met vriendelijke groeten / Best regards, Ger Hobbelt (Later on I redid a small part of this for my own purposes, where I was (ahem) 'cross-compiling' from a Win32 host platform to embedded i86. That code is not useful here, as the embedded OS had file I/O and the lot.) -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
