Open Source Embedded SSL - Export Questions

2003-11-25 Thread J Harper
Hi All,

We've implemented a small version of SSL that we plan to release as open source by 
year's end.  I've seen some discussion on this group indicating that this would be 
useful in the embedded environments, given the current landscape of larger 
implementations such as OpenSSL (Crypto++, etc).  We developed this ourselves (using 
some of the crypto routines in Tom's libtomcrypt) as part of our Web services based 
device management software because we needed to keep our own footprint small, and I 
imagine there are others looking to do the same.

Once our code is released, we welcome feedback in terms of additional requirements, 
gotchas, etc. (and if you want to jump in now, that's fine too).  But before we can 
release, we need to understand the export issues (we're a US based company).  An 
overview of what we're developed for the first release:

SSLv3 protocol implementation
Simple ASN.1 parsing
Cipher suites:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

We're not looking for official legal advice, just some pointers to current online 
resources of how to go about registering our product in the US.  I've seen posts that 
for SSL implementations you just need to send a letter to the government, but 
haven't come across an official government checklist and address.  We may be able to 
weaken the code down using the export ciphers, but I doubt end users will be 
interested in that level of encryption.  Plus, if we do have to limit key lengths, it 
seems a bit arbitrary with open source code, since users can simply change a few lines 
of code and have full strength crypto.  Are there any special provisions for source 
release (short of getting a tattoo, singing an mp3 or sending a model rocket over to 
Mexico - kidding, kidding)?

We'd appreciate feedback or pointers to documentation on the steps required for 
government registration and an approximate timeframe for the process.  On a different, 
but similar legal note, what current patent/trademark issues have people run across 
with the algorithms mentioned above?  RSA patents expired a few years ago and our ARC4 
implementation is not trademarked as far as I understand (although most books on the 
subject seem a bit squirrelly).  Open source crypto libraries include implementations 
of these and other disputed algorithms including DSS and ECC, so I'm wondering how 
they handled the situation.

Thanks,

J Harper
PeerSec Networks
http://www.peersec.com
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread J Harper
Thanks.  Pretty simple for open source code.  Single email to two addresses
once we have code available online.
http://www.bxa.doc.gov/Encryption/pubavailencsourcecodenofify.html
(yes, notify is spelled wrong)

What about the patent/trademark issues?

- Original Message -
From: Sidney Markowitz [EMAIL PROTECTED]
To: J Harper [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2003 5:23 PM
Subject: Re: Open Source Embedded SSL - Export Questions


 J Harper wrote:
  pointers to documentation on the steps required for government
registration

 The official site for this is at

 http://www.bxa.doc.gov/Encryption/Default.htm

   -- sidney



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source Embedded SSL - (AES)

2003-11-26 Thread J Harper
I've just taken a look.  This OCB mode for AES looks really interesting.
Encryption and MAC in one pass! Wait, OCB is patented.  That's not in
the spirit of AES :-)  I suppose one could do a user defined cipher
suite for AES OCB, if both client and server knew about it.  Anyway...
must focus on current release.

Any word on whether it's OK to use the TLS AES cipher suite with SSLv3?

J

-Original Message-
From: Sidney Markowitz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2003 5:13 PM
To: J Harper
Cc: [EMAIL PROTECTED]
Subject: Re: Open Source Embedded SSL - Export Questions


As a separate issue from whether you want to implement AES, if you do 
decide to implement it look at Brian Gladman's code at 
http://fp.gladman.plus.com/cryptography_technology/rijndael/

It is the fastest free implementation of AES that I know of, and has a 
good history and credentials behind it as you can see from the 
background information linked from that web page.

  -- sidney


-
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]


MatrixSSL Embedded SSL/TLS

2004-05-08 Thread J Harper
For those of you who are interested in the coding aspects of crypto, I'd
like to announce that our small footprint SSL/TLS library, MatrixSSL is
available for download at http://www.matrixssl.org

With a footprint under 50KB, MatrixSSL not only meets device requirements,
it also provides a protocol implementation that is easy to read and
understand.  Some unique benefits for the cryptography community are:

+ Clean, clear implementation makes bugs and security issues easier to spot
and fix
+ Focused, well documented implementation of SSL is a good teaching tool
+ Open Source ensures potential backdoors and security issues can be found
+ Compact implementation of a standard security protocol removes an excuse
for homegrown solutions

I'm interested in your feedback about MatrixSSL.  We are actively working to
make sure this a unique solution that solves some of the issues preventing
adoption of standard security protocols in Internet enabled devices.

J Harper
PeerSec Networks
http://www.peersec.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Humorous anti-SSL PR

2004-07-15 Thread J Harper
This barely deserves mention, but is worth it for the humor:
Information Security Expert says SSL (Secure Socket Layer) is Nothing More
Than a Condom that Just Protects the Pipe
http://www.prweb.com/releases/2004/7/prweb141248.htm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Cryptography and the Open Source Security Debate

2004-07-22 Thread J Harper
There doesn't appear to be a discussion forum related to the Web post, so
I'll reply here.

We've gone through a similar thought process at my company.  We have a
commercial security product (MatrixSSL), but provide an open source version
for many of the good points Daniel makes.  There are a few additional
reasons that the general open-source conclusion isn't as clear cut however.

One of the benefits of having security algorithms open source is that the
code can be better trusted in terms of back doors.  So while Daniel may
trust the NSA, others may not.  Standard software typically isn't treated
with the same positive paranoia, and therefore doesn't often have the same
requirement.  Back doors in closed source networked software, for example
can be somewhat tested for through network protocol analysis and controlled
through firewalls.  Cryptography must be trusted at an algorithm level,
since protocol analysis of the resultant data (should be) very difficult.

A larger problem with the expansion from cryptographic algorithm benefits to
open source benefits in general is one of pure code size.  The number of
lines of code of both Windows and Linux distributions is 30-40 million.  The
number of developers that 1. bother reading the code, 2. can actually
understand it, 3. have the expertise and motivation to suggest/correct
problems is a very small subset of developers for either proprietary or open
source solutions.  Developers that understand the complex interactions
between software components are even fewer.  When it comes down to it, a
very small set of people becomes trusted in whatever code area they
specialize in.  Crypto algorithms are typically on the order of 1000 lines
of code, with a large portion containing static key blocks.  Experts looking
at an open crypto algorithm require a great deal of expertise, but can also
be much more focused in their analysis.

 Do you trust both the talent and moral integrity of the company you are
 getting your closed source software from so much that you think the
 products they are supplying you are superior (from a security standpoint)
 to those that can be created via peer review and attack by tens of
 thousands?
This question is less related to the crypto specific conclusion, so I'll
keep it short.  The power of capitalism to produce competition and better
products is underestimated here.  Market pressure is growing for closed
source to become more secure, and when money is at stake, the products will
improve.  Peer review by tens of thousands of largely unpaid, untrained
developers vs. a corporation's all important shareholder value in this
increasingly security conscious market is a much more even fight than one
might expect.  This is why we have combined both sides of the debate to
produce a dual licensed product that has the security benefits of open
source, with the market responsibility of a commercial product.

J Harper
PeerSec Networks
http://www.peersec.com

- Original Message - 
From: R. A. Hettinga [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 9:46 AM
Subject: Cryptography and the Open Source Security Debate


 http://www.osopinion.com/print.php?sid=1792


 osViews | osOpinion

 Cryptography and the Open Source Security Debate

 Articles / Security
 Date: Jul 20, 2004 - 01:03 AM


 Contributed by: Daniel R. Miessler
  :: Open Content

 If you follow technology trends, you're probably aware of the two schools
 of thought with regard to security and/or cryptography. Does cryptography
 and security solutions become more secure as the number of eyes pouring
 over its source code increases or is a private solution which leverages
 security through obscurity provide a more secure environment?

  Daniel R. Miessler submitted the following editorial to
osOpinion/osViews,
 which offers some compelling arguments for both scenarios. In the end, his
 well thought out opinion, comes to a universal conclusion.
  --

  I've been reading Bruce Schneier's Book on cryptography for the last
 couple of days, and one of the main concepts in the text struck me as
 interesting.

  One of the points of discussion when looking at the security of a given
 algorithm is its exposure to scrutiny. Bruce explicitly states that no one
 should ever trust a proprietary algorithm. He states that with few
 exceptions, the only relatively secure algorithms are those that have
stood
 the test of time while being poured over by thousands of cryptanalysts.

 Similar Situations

  What struck me is the similarity between this mode of thought and that of
 the open source community on the topic of security. In that debate there
is
 much disagreement about which is better - open or closed -, while in the
 crypto world it's considered common knowledge that open is better.
 According to the crypto paradigm, having any measure of an algorithm's
 security based on the fact that it's a secret is generally a bad thing.
 There, keys are what makes the system