crypto implementation for small footprint devices
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. Thanks in advance!! Peter
what kind of platform? are you counting on an internal processor, or are you just storing a key to be acted on via a second device? need more info. pz -----Original Message----- From: owner-cypherpunks@Algebra.COM [mailto:owner-cypherpunks@Algebra.COM]On Behalf Of Xiao, Peter Sent: Tuesday, January 09, 2001 6:43 PM To: 'coderpunks@toad.com'; cypherpunks@toad.com Subject: crypto implementation for small footprint devices 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. Thanks in advance!! Peter
* Xiao, Peter <pxiao@Liberate.com> [20010109 16:01]:
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.
How small of footprint? 50K (presuming you mean in currency) isn't really a measurement of footprint size to me. :) Would something along the lines of a Java iButton <URL:http://www.ibutton.com/> match your requirements? It truly depends on what you need the device to be capable of...and I don't just mean the crypto implementation but is this a device to be self-powered? How do you need to interface with it? Etc. -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us> Geek Research LLC - <URL:http://www.geekresearch.com/> IP Network Engineering and Consulting
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.
Thanks in advance!!
Peter
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. Gé -- -- Gé Weijers Voice: (614)485-2900 Sun Microsystems Fax: (614)485-2929 Server Appliance Business Unit 1160 Dublin Rd., Ste 100, Columbus OH 43215
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.
Thanks in advance!!
Peter
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.
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. Encoding ASN.1 really eats space though, because of the nested nature of complex ASN.1... unless you do some tricks like I did in US patent 6,111,660. Using this trick, we were able to encode SET messages (really ugly ASN.1) using only 4 bytes more than the size of the final message. So we could comfortably run client-side SET in less than 24k of RAM. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5
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)
Similar experiences here, we have an ASN.1 encoder/decoder in 8k.
At CertCo we used a slightly modified version of the Umich BER decoder that can now be found within openldap. I don't know how big it was, but it fit into a Chrysalis card with a whole bunch of other certco firmware. /r$
Encoding ASN.1 really eats space though, because of the nested nature of complex ASN.1... unless you do some tricks like I did in US patent 6,111,660.
It sure looks like the Umich LDAP library is prior art which invalidates most, if not all, of the independant claims. (At least 1 and 6, which are the key ones.) This library was documented in RFC 1823, published in August 1995. /r$
participants (7)
-
Eric Murray -
Eric Young -
Gé Weijers -
Josh Richards -
Phillip Zakas -
Rich Salz -
Xiao, Peter