Re: Open Source Embedded SSL - Export Questions

2003-11-29 Thread Bill Stewart
At 02:45 PM 11/27/2003 +1100, Greg Rose wrote:
At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
RC4 is extremely weak for some applications.
A block cipher is greatly preferable.
I'm afraid that I can't agree with this howling logical error.
RC4 is showing its age, but there are other stream ciphers
that are acceptable, and there are block ciphers
(such as FEAL, same vintage as RC4) that aren't even vaguely secure.
Well, to be more precise,
RC4 has restrictions on the ways you can use it that
make its crypto strength fail very badly if you violate them,
and because it's an XOR stream cypher there are sometimes
things you can't do with it that you could do with a block cypher.
RC4 does also have the historical problem that people sometimes
decide to use it with 40-bit keys because they can...
OTOH, of course being a block cypher isn't enough to guarantee
either strength or usefulness, e.g. bass-o-matic.






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


Re: Open Source Embedded SSL - Export Questions

2003-11-27 Thread Greg Rose
At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
RC4 is extremely weak for some applications.  A block cipher is greatly
preferable.
I'm afraid that I can't agree with this howling logical error. RC4 is 
showing its age, but there are other stream ciphers that are acceptable, 
and there are block ciphers (such as FEAL, same vintage as RC4) that aren't 
even vaguely secure.

Greg.

Greg Rose   INTERNET: [EMAIL PROTECTED]
Qualcomm Australia  VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source Embedded SSL - Export Questions

2003-11-27 Thread Thor Lancelot Simon
On Thu, Nov 27, 2003 at 02:45:47PM +1100, Greg Rose wrote:
 At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
 RC4 is extremely weak for some applications.  A block cipher is greatly
 preferable.
 
 I'm afraid that I can't agree with this howling logical error. RC4 is 
 showing its age, but there are other stream ciphers that are acceptable, 

Sorry if I mislead -- that was intended as two separate statements, and I
was also in a bit of a hurry.

Yes, of course there are applications for which a stream cipher is preferable
to a block cipher.  However, in my experience, programmers often choose RC4
(or another fast stream cipher) by using speed as their only criterion, and
then end up applying it in applications in which a block cipher would be a
better choice.

Thor

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


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread Bill Tompkins
On Mon, 2003-11-24 at 21:06, J Harper wrote:

...snip...
 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.
...snip

http://www.bxa.doc.gov/Encryption/
is the US Dept of Commerce site that has the regulations

http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html
has the details about what letter you send where for Publicly
Available source code.  You'll want to read the regulations to verify
that the code does qualify as publicly available, etc...

No, I'm not a lawyer, and no, this was not legal advice.

I am, however, an embedded software developer, and am looking forward to
seeing the code :)  I'm guessing the details of the software and license
are already set, but just in case they aren't, I've got a couple of
requests:

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.

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.

Thanks in advance for the code release,

-Bill

-
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 - Export Questions

2003-11-26 Thread Rich Salz
 We've implemented a small version of SSL that we plan to release as
 open source by year's end.

Great!

 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.

http://www.bxa.doc.gov/Encryption; Google for crypto export
turned it up as the third item.  Yes, open source is pretty easy
to export.  (Even for binaries, it's not like the bad old days;
the regulations are pretty realistic now.  For example, there's
really no such thing as export strength any more.)

 On a different, but similar legal note,
 what current patent/trademark issues have people run across with the
 algorithms mentioned above?

Well, for the ones you mentioned, RSA and 3DES are unencumberd.
RC4 is a trademark owned by RSA Data Security.  So don't violate their
trademark.
/r$
--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html


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


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], J Harper writes:

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

I understand the need to conserve space; that said, I strongly urge you 
to consider AES as well.  If this is for embedded systems, it will live 
for a long time, and I expect AES to displace 3DES in the near future.

--Steve Bellovin, http://www.research.att.com/~smb


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


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread Thor Lancelot Simon
On Wed, Nov 26, 2003 at 02:56:40PM -0800, J Harper wrote:
 Great feedback, let me elaborate.  I realize that AES is implemented in
 hardware for many platforms as well.  I'll mention a bit more about our
 cryptography architecture below.  Do you know why AES is so popular in
 embedded?  ARC4 is faster in software and extremely small code size.  It

RC4 is extremely weak for some applications.  A block cipher is greatly
preferable.

There isn't _quite_ a speed/strength tradeoff in cryptography, but any
time you choose algorithms based purely on speed, you'd better get really,
really suspicious about the strength of what you're producing.

Thor

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


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread Sidney Markowitz
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]


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]