Re: Open Source Embedded SSL - (License and Memory)
On Thu, Dec 04, 2003 at 10:32:32PM -0500, Bill Tompkins wrote: > 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). [Bill went on to say that you might use SSL for such things, as it's had lots of design effort]. If you're using wireless then SSL isn't really an option, unless you layer something like TCP over the top. A large part of SSL's anti-replay security relies on it running on a reliable channel, so sequence numbers monotonically increase at a constant rate. (this is also for attempted message injection). Also, AIUI, *any* crypto failure causes a shutdown of the protocol, rather than it just being ignored, as it might be in an unreliable stream. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
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]
RE: Open Source Embedded SSL - (License and Memory)
"J Harper" <[EMAIL PROTECTED]> writes: >>2) Make it functional on systems without memory allocation. Did I >>mention that I work on (very) small embedded systems? Having fixed >>spaces for variables is useful when you want something to run >>deterministically for a long time with no resets, and I have yet to >>find a free bignum library that didn't want to use malloc all the >>time. > >We have implemented a block allocation scheme for our device Web services >product that would probably solve this issue. Queues of various structure >sizes are held within a single chunk of memory. 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). My code will run without malloc() in general, but assumes that if you have a TCP stack and ethernet then you're also going to have malloc() support. For the non-malloc platforms, it's written to grab memory in a FIFO manner, so you can get away with a simple brk-style allocator. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
[Moderator's note: I'd really like to shut down the "What license?" debate --Perry] At 12:52 AM 11/27/2003 -0800, J Harper wrote: > 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but > for embedded software, especially in the security domain, it's a > killer. I'm supposed to allow users to modify the software that runs > on their secure token? And on a small platform where there won't be > such things as loadable modules, or even process separation, the > (L)GPL really does become viral. This is, I think, why Red Hat > releases eCos under a non-GPL (but still open source) license. We're aware of these issues. How do other people on the group feel? That's an obvious call for a BSD / C-News style license - You're free to copy it but leave our copyright notice in. - You acknowledge that you got it for free and that any consequences, no matter how horrible, of what you do with it are not our responsibility. - You're free to change it, but only if you include a notice that you changed it. - Maybe something about you must either distribute the licensed source code for no more than a copying/handling charge or else a pointer to the original. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Open Source Embedded SSL - (License and Memory)
J Harper wrote: > > > 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but > > > for embedded software, especially in the security domain, it's a > > killer. I'm supposed to allow users to modify the software that runs > > on their secure token? And on a small platform where there won't be > > such things as loadable modules, or even process separation, the > > (L)GPL really does become viral. This is, I think, why Red Hat > > releases eCos under a non-GPL (but still open source) license. > > We're aware of these issues. How do other people on the group feel? I think this applies more generally, but especially for crypto software, because of the legal environment and the complicated usage to which it is often put. Placing any burdens of a non-technical nature on the user is generally a downer. Crypto-newbies are often unsure and under rather intense pressure to get something out. If uncertainties of code licensing issue are added, it can have a marked effect on the results. The general result is a choice between no crypto and poorly done crypto. (Rarely is good crypto done in the first instance.) Opinions differ on this point, but I generally err on the side of recommending less than perfect crypto, which can be repaired later on at a lower cost. It's a lot easier to sell a manager on "replacing poor crypto" when it becomes needed than on "we need to add a crypto layer." For that reason, we (Cryptix) have always placed all our code under a BSD style licence, except a few cases where it has been placed under public domain (AES). Our view has always been, "with crypto, the least barriers the better." In essence, "get it out there" is the mantra. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
>>> 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, >> >> We're aware of these issues. How do other people on the group feel? > >Speaking frankly: You should read up on what common licenses >imply and make your own decision, depending on what your goals >are. While doing so, you might want to question the assertion >that LGPL is "viral". I'm familiar with the various standard licenses. And your advice is sound, we'll pick one that aligns with our goals for the release. I guess this could be viewed as a religious issue, but I'm interested in the usage issue, especially for the small footprint space. If Bill's view of GPL is a common one in embedded, it is worth us taking into account. For us as a company releasing source, licenses with copyleft will reduce the risk of forking and have other benefits. The "viral" nature of GPL in embedded, however, I think is a valid concern. I think Peter Gutmann's cryptlib is GPL compatible, what has been the embedded/corporate response to it? J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
> 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but > for embedded software, especially in the security domain, it's a > killer. I'm supposed to allow users to modify the software that runs > on their secure token? And on a small platform where there won't be > such things as loadable modules, or even process separation, the > (L)GPL really does become viral. This is, I think, why Red Hat > releases eCos under a non-GPL (but still open source) license. We're aware of these issues. How do other people on the group feel? > 2) Make it functional on systems without memory allocation. Did I > mention that I work on (very) small embedded systems? Having fixed > spaces for variables is useful when you want something to run > deterministically for a long time with no resets, and I have yet to > find a free bignum library that didn't want to use malloc all the > time. We have implemented a block allocation scheme for our device Web services product that would probably solve this issue. Queues of various structure sizes are held within a single chunk of memory. This has the nice side effect of cleaning up any leaked memory when freed. If the demand is there we'll consider releasing the source for this as well. Doing an apache style per-session memory pool for SSL sessions would be a nice way to make sure all memory was freed after each SSL session closes. For now we use the classic #define sslMalloc malloc, and let you swap in your own implementation if desired. J Harper PeerSec Networks http://www.peersec.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
