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 [EMAIL PROTECTED]