Open Source Embedded SSL - Export Questions
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
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)
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)
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
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
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
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
