Re: Open Source Embedded SSL - (License and Memory)

2003-12-06 Thread Matthew Byng-Maddick
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)

2003-12-05 Thread Peter Gutmann
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)

2003-11-29 Thread Bill Stewart
[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)

2003-11-28 Thread Ian Grigg
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)

2003-11-27 Thread J Harper
 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]