Open Source Embedded SSL - (License and Memory)

[Bill Tompkins]

On Thu, 2003-12-04 at 20:15, Peter Gutmann wrote:

> How common is it to find an embedded system sophisticated enough to have a TCP
> stack and ethernet interface (and running SSL), but not sophisticated enough
> to have a malloc() implementation?  I've always assumed that anything with the
> former will also have the latter (I know there are some highly constrained
> embedded platforms used in some web-enabled widgets, but they usually don't
> run SSL).

I can't speak to how common it is, but there are applications that
require crypto, and that require some sort of negotiation protocol, that
don't use TCP or Ethernet.  For example- wireless apps, or various
non-ethernet multi-drop wired interfaces.  While these applications do
require some sort of communications stack, it might be less
sophisticated than what you're used to seeing with TCP/IP (and might be
mostly implemented in off-CPU hardware).

For systems like this, there's probably no requirement to use SSL
(unless it is talking through a gateway to some TCP device), but there
is a requirement for the underlying crypto library, and some protocol
that uses it.  As you've mentioned here before, designing a protocol
that is as secure as SSL is hard, and there's no sense re-inventing the
wheel, so why not use SSL?

Certainly, any system big enough to use SSL could have a simple block
allocator.  My complaint is with the non-determinancy (and implied error
checking/handling) that accompany variably-sized allocations and
reallocations.  As John Gilmore pointed out to me in an email, if the
library were simple enough to use static buffers, but did use memory
allocation, then the user could pre-determine the sizes and times of
memory allocation and write a simple block allocator to suit the
requirements of the library.  In this case, the behavior of the library
would again be deterministic.

I don't mean to be making a big deal about the memory allocation issue;
it's probably more a pet peeve of mine than an industry-wide concern. 
But it is something that would concern me if I was trying to do some
formal analysis to certify an embedded device (although I'm certainly no
expert on such things), or make a device that was simply never allowed
to fail or reset.

-Bill


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com