Re: Open Source Embedded SSL - Export Questions
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
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
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
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 - Export Questions
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
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 seems that trademark issues can be avoided and so cost should not be an issue. If RSA is selling RC4, I can't imagine it being very expensive due to a widely known algorithm that generates the same bytestream. Hasn't RC4 been milked dry yet :-) ? Perhaps AES is easy to implement in hardware, and doing so can reduce power requirements and offload the main processor, although one would think that the same argument could be made for ARC4, plus there is additional cost per device for the codec chip. My guess is that AES is patent free and provides better security than ARC4, which is prompting its use: http://www.faqs.org/rfcs/rfc3268.html We've designed the interface so it's easy to add new cipher suites, such as TLS_RSA_WITH_AES_128_CBC_SHA. We have also layered the cryptography provider interface so it's easy to plug in specific implementations in place of the ones we provide. For example, if running on PocketPC, one could use the MS Crypto implementation to reduce code size. Alternatively, "engine" supported algorithms in OpenSSL could be linked in for higher performance. We are trying, however to provide the right feature set out of the box, so AES should definitely go on the list. The RFC above mentions that AES is an additional cipher suite for TLS. Our implementation initially supports only SSLv3. We can do some testing, but do you know whether or not it is possible to negotiate to an AES suite over SSLv3? My guess is no, because the RFC mentions the SHA HMAC for TLS, not SSLv3's HMAC. We've implemented SSLv3 because we wanted the most compatible version of SSL that was still secure. Adding optional TLS support would not be a big deal, but we don't plan it for first release. J - Original Message - From: "Steven M. Bellovin" <[EMAIL PROTECTED]> To: "J Harper" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 26, 2003 12:09 PM Subject: Re: Open Source Embedded SSL - Export Questions > 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
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
> 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
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
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
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]
