Submiting patch for nrpe

[Stephen Strudwick]

> Double-encrypting isn't really an extra-layer; there are some theoretical
> attacks that suggest that double encryption can be harmful.  No idea if it is
> in the this particular case; however, just using OpenSSL or GnuTLS to do both
> client/server authentication, and data encryption is the easiest solution.

Yep I got this wrong :) I forgot about the meet in the middle attack.

using the same cipher it seems triple encryption using 2 keys offers a
gain, but double encryption dosnt.

I dont know how this applies to using 2 different ciphers (and only 1
key)and whether the meet in the middle attack can be applied.

>From what Ive read I think it would. In fact the encryption would only be
as strong as the weakest cipher I beleive ?

So maybe it is best to keep SSL and BF apart.

At least we know the strengths and weaknesses of each cipher on its own.

-
Stephen Strudwick
Advanced Development Engineer
Development Group, Product Development
PIPEX Communications
http://www.pipexcommunications.net/

Mobile: 07906 191256
Direct: 020 8957 1217

On Wed, 21 Jan 2004, Mark Ferlatte wrote:

> Stephen Strudwick said on Wed, Jan 21, 2004 at 06:01:21PM +0000:
> > I dont see cpu cycles really being a problem, certainly not server
> > side, possibly it could add up a bit client side where nagios is
> > installed. But its just a handshake and exchange of 1k packets every 5
> > mins per server.
>
> Your servers are beefier than mine (or you have way fewer clients).  :)
>
> > I wouldnt have thought it was wasted cpu cycles either, you would be
> > adding an extra layer of security, but more importantly providing some
> > kind of authentication lacking atm because of no certificates.
>
> Double-encrypting isn't really an extra-layer; there are some theoretical
> attacks that suggest that double encryption can be harmful.  No idea if it is
> in the this particular case; however, just using OpenSSL or GnuTLS to do both
> client/server authentication, and data encryption is the easiest solution.
>
> > Anyway, im no expert on SSL/TLS, but im trying when I have spare moments
> > to read as much as possible, if im wrong, try to point me in the right
> > direction as to why.
>
> I think it's just more work to do both; if you are going to implement TLS, then
> you don't need seperate blowfish.
>
> > For me the problem atm is the lack of certificates. I would have preferred
> > this approach, but I dont know enough about SSL/TLS and I didnt have the
> > time to learn/experiment and implement.
> >
> > I went with blowfish because I knew I could get something
> > secure, reliable and already fully tested working in a few days.
>
> Fair enough.  I don't mean to suggest that your patch isn't useful.
>
> From an admin perspective, though, the fewer distinct security mechanisms I
> have to deal with and worry about, the better.  TLS is a well known mechanism
> that is well understood, and there are good libraries that are well tested.
>
> (There's a bit of a license issue with OpenSSL and GPL'd code that could be a
> problem, but I think it just requires Ethan to put a note in the license file
> saying "This is under the GPL, but you can link to OpenSSL also if you want.").
>
> Okay, that's enough out of me, since I don't have a TLS patch to submit.  :)
>
> M
>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn