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: Problems with GPG El Gamal signing keys?

2003-11-27 Thread Enzo Michelangeli

- 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?

2003-11-27 Thread Anton Stiglic

- 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)

2003-11-27 Thread J Harper
 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]