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 - 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]
Reference for Sealed Storage component of Trusted Computing?
Hi! Would anybody have a specific patent or patent application reference for the Sealed Storage component of the "Trusted Computing" initiatives (see Seth Schoen, Trusted Computing: Promise and Risk, at http://www.eff.org/Infra/trusted_computing/20031001_tc.php)? The description of this scheme reminds me the all-or-nothing discussions that occurred in the sci.crypt newsgroup a few years ago. Thanks in advance. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Problems with GPG El Gamal signing keys?
Some notes have been floating around claiming that there are bugs in GPG's use of El Gamal keys. For example, see: http://groups.google.com/groups?selm=E1AOvTM-0001nY-00%40alberti.g10code.de&oe=UTF-8&output=gplain Can anyone confirm these reports? -- Perry E. Metzger[EMAIL PROTECTED] - 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]
lockable trapdoor one-way function
Does anyone know of a trapdoor one-way function whose trapdoor can be locked after use? It can be done with secure hardware and/or distributed trust, just delete the trapdoor key, and prove (somehow?) you've deleted it. It looks hard to do in "trust-the-math-only" mode... -- Peter Fairbrother - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Are there...one-way encryption algorithms
Bodo Moeller wrote: > The Pohlig-Hellman cipher is the modular scheme that you describe, but > observe there is a connection to the protocol above: that protocol > works only if encryption and decryption has a certain commutativity > property (decrypting B(A(M)) with key A must leave B(M), not > just some A^-1(B(A(M))) that might look entirely different), and > the Pohlig-Hellman cipher has this property. A useful property for all sorts of things. I'm using P-H to improve Golle et al's universal encryption methods, http://www.zenadsl6186.zen.co.uk/ICURpaper3.pdf but it's a pity that Pohlig-Hellman is still slow, and that there isn't a faster algorithm with similar properties. There's lots of potential uses for one of those :) -- Peter Fairbrother - 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: Cryptophone locks out snoopers
Ian Grigg wrote: > (link is very slow:) > http://theregister.co.uk/content/68/34096.html > > > Cryptophone locks out snoopers > By electricnews.net > Posted: 20/11/2003 at 10:16 GMT I see the source release has been put back... again. - 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]
