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
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: Problems with GPG El Gamal signing keys?
- Original Message - From: Perry E.Metzger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 27, 2003 7:24 AM Subject: 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.deoe=UTF-8output=gplain Can anyone confirm these reports? There is an official announcement: http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
- Original Message - From: Perry E.Metzger [EMAIL PROTECTED] 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.deoe=UTF-8output=gplain Can anyone confirm these reports? The note talks about GPG Elgamal encryption and signature schemes using small value of k (where k is the random value that you pick for each signature, each encryption). For encryption choosing a small k is o.k. (by small I mean something like 160 bits when you have a 1024 bit prime), but this was never recommended for the signature scheme, and the note states that this would in fact be a security vulnerability. The note says that with one signature using a certain private key x, generated using a small random k, you can compute the private key x. So if you are also using this key for decryption, the private key found could also be used to decrypt everything that was encrypted to you. I haven't put any taught yet in how you would retrieve the private key given the signature (I just read this email), but it sounds plausible. One thing I can confirm however is that GnuPG 1.2.3 (the latest version available from the GnuPG we site) indeed has is that both the encryption and signature schemes use a small k. If you have the source code, just take a look at cipher/elgamal.c, there is a function gen_k( MPI p ) that is called by both do_encrypt(...) and sign(...) functions. In the function gen_k, k is chosen to be of size nbits, where nbits is smaller than the size of the prime. Look at the comment in the code: /* IMO using a k much lesser than p is sufficient and it greatly * improves the encryption performance. We use Wiener's table * and add a large safety margin. */ nbits = wiener_map( orig_nbits ) * 3 / 2; wiener_map maps sizes of primes to sizes for k and q. For example, for a 1024 bit prime, the function will return 165, so in this case nbits would be 165*3/2 = 247. I give credit to Phong Nguyen which the note says was the person who observed this and came up with the attack. --Anton - 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]
