Re: [gentoo-security] Securing portage --- an OpenBSD approach

[Brian G. Peterson]

On Friday 12 November 2004 10:16 am, Klaus Wagner wrote:
> On Fri, Nov 12, 2004 at 09:54:11AM -0600, Brian G. Peterson wrote:
> > wouldn't public-key rsync over ssh be a lower CPU load option than rsync
> > over SSL?
>
> I don't think so, because internally ssh is using ssl.

No, ssh and SSL are two distinct protocols. ssh encrypts its packets directly, 
using a variety of algorithms, some of which (the session encryption 
algorithms) overlap with SSL, but the *protocol* and *packet layout* are 
quite different.

> (in both cases an ssl cipher)

As I said, these are not SSL ciphers, but simply encryption algorithms that 
are independent of any particular protocol that uses them.

In my experience, ssh implementations are much more CPU-efficient than OpenSSL 
is when usign the same algorithms.

> ssh (at least in newer versions) is using very strong ciphers by default,
> which stress the cpu even more (AES 256 or better).

SSH uses a two-factor encryption approach, the authentication phase uses a 
password or a public/private key pair to establish the trust relationship and 
to exchange a session key.  The session key can be done using any number of 
algorithms, AES is common, but there are many more, several of them faster 
than AES.  The *server* decides which algorithms and the strength of the 
algorithm to offer.  For use in securing communications with the mirror, even 
a very small (56 bit) key would be fine, becasue the *data* is essentially 
public, not confidential, and you only need to protect it in transit between 
the two servers.  Even a 56 bit key can't be broken via brute force quickly 
enough for use in a man-in-the middle attack.

The only thing we need to do here is make sure that the data is not tampered 
with in transit, if man in the middle attack is the concern.

Regards,

 - Brian

--
gentoo-security@g.o mailing list