[stunnel-users] key+cert+dh risks

Jean-Yves F. Barbier 12ukwn at gmail.com
Sat Feb 12 14:32:19 CET 2011

On Sat, 12 Feb 2011 14:16:00 +0100, Ludolf Holzheid
<lholzheid at bihl-wiedemann.de> wrote:

> On Fri, 2011-02-11 23:40:10 +0100, Jean-Yves F. Barbier wrote:
> > Hi list,
> > 
> > I'm using stunnel between two machines only, so is there a risk to reuse
> > the server stunnel.pem on the client? (and if it's risky, why?)
> I wouldn't want to have our server's private key on a windows netbook
> of one of our sales people, but if the two machines are in a trusted
> environment and the file permissions are set properly, I don' see any
> reason why this could be a problem.

Fortunately we only use real OS :)
> Though I think I understood the concept of PKI, I don't know the first
> thing about the mathematics used for asymmetric encryption -- maybe
> using the same key on both ends is a strange corner case I'm not aware
> of. I don't expect this to be the cases, but I don't know.
> As far as I understood, the private key is used at session setup only
> (for negotiating the session key, which is newly created for each
> session). This is to reduce the amount of data that could be used to
> 'guess' the private key. If you use the same key pair on both ends,
> this doubles this data. However, I don't think this raises the chances
> of success for guessing the private key to a real-world likelihood.

Hmmm, so it looks like may the entropy may be higher with 2 different keys.

> If I had to set up an SSL-secured point-to-point tunnel, my first idea
> would be to use different key pairs on both sides (thinking of the
> point-to-point tunnel as a special case of multi-client tunnels),
> but I'm not aware of any real reason not to do so.
> HTH,

Thanks Ludolf, you made me reconsider and I think I'll use 2 différent keys
(that was pure lazyness: on an athlonXP-2600+ a dhparam of 4096 bytes is
*very* long to calculate.)

                printk("ufs_read_super: fucking Sun blows me\n");
		-- /usr/src/linux/fs/ufs/ufs_super.c

More information about the stunnel-users mailing list