Eric Murray wrote:
On Wed, Jan 10, 2001 at 07:59:13AM -0700, Gé Weijers wrote:
On Tue, Jan 09, 2001 at 03:42:45PM -0800, Xiao, Peter wrote:
Hi, I am currently looking for crypto implementation that can fit into small footprint (in the order of 50K or less) devices. Ideally, an SSL type of protocol meets my requirements but it is almost impossible to implement it within 50K even with selected cipher suites. So, I am looking for alternatives (either symmetric key or public key based). I was thinking about WTLS but looks like its implementation can not be significantly smaller than that of TLS since it is also based on Public Key cryptography (I am wondering how it fits into a cellphone). Can any one tell me what is the approximate size of the client implementation of WTLS. Also, would anyone send some pointers to me regarding what I am looking for.
It's not the public-key operations themselves that use the space. I've managed to squeeze OAEP-formatted RSA encryption into less than 20K. The public key was hard-wired, though. You probably want to stay away from ASN.1 formatted data if space is a concern.
I have been doing some work on this recently, and also have gotten good, results, specifically, PKCS#1 RSA multi-prime on a Palm is 16.5k (1024-2 17.63sec, 1024-3 9.6sec, palm IIIx (68xxx 20mhz)), or more interestingly 18k on a Psion (ARM7 36mhz, 1024-3 private in 0.18sec and 1024-2 in 0.34sec). I'm waiting for ARM (or SH3/4 or anything other than 68xxx) to take over the world. It make the choice of public key algorithm based on CPU load less irrelevant when low end devices have this sort of grunt. I am interested in knowing how small EC can be for both public/private operations. Any public information or peoples experiences?
Unfortunately anything that uses X.509 (like SSL) will require it. It's possible to write small X.509/ASN.1 decoding packages. One that I wrote for a small-device SSL package takes about 11k code (gcc on Intel PIII) and it's not very optimized- there's lots of room to squeeze it down farther than the original application required.
Similar experiences here, we have an ASN.1 encoder/decoder in 8k. I have not tries the really complex stuff yet, like SET (and hopefully never will :-). It is nice to have an ASN.1 encoder this small but rather obviously it requires a bit of work per ASN.1 data type. eric (who has a day job at eay@rsasecurity.com.au)