1 |
On Friday 12 November 2004 10:16 am, Klaus Wagner wrote: |
2 |
> On Fri, Nov 12, 2004 at 09:54:11AM -0600, Brian G. Peterson wrote: |
3 |
> > wouldn't public-key rsync over ssh be a lower CPU load option than rsync |
4 |
> > over SSL? |
5 |
> |
6 |
> I don't think so, because internally ssh is using ssl. |
7 |
|
8 |
No, ssh and SSL are two distinct protocols. ssh encrypts its packets directly, |
9 |
using a variety of algorithms, some of which (the session encryption |
10 |
algorithms) overlap with SSL, but the *protocol* and *packet layout* are |
11 |
quite different. |
12 |
|
13 |
> (in both cases an ssl cipher) |
14 |
|
15 |
As I said, these are not SSL ciphers, but simply encryption algorithms that |
16 |
are independent of any particular protocol that uses them. |
17 |
|
18 |
In my experience, ssh implementations are much more CPU-efficient than OpenSSL |
19 |
is when usign the same algorithms. |
20 |
|
21 |
> ssh (at least in newer versions) is using very strong ciphers by default, |
22 |
> which stress the cpu even more (AES 256 or better). |
23 |
|
24 |
SSH uses a two-factor encryption approach, the authentication phase uses a |
25 |
password or a public/private key pair to establish the trust relationship and |
26 |
to exchange a session key. The session key can be done using any number of |
27 |
algorithms, AES is common, but there are many more, several of them faster |
28 |
than AES. The *server* decides which algorithms and the strength of the |
29 |
algorithm to offer. For use in securing communications with the mirror, even |
30 |
a very small (56 bit) key would be fine, becasue the *data* is essentially |
31 |
public, not confidential, and you only need to protect it in transit between |
32 |
the two servers. Even a 56 bit key can't be broken via brute force quickly |
33 |
enough for use in a man-in-the middle attack. |
34 |
|
35 |
The only thing we need to do here is make sure that the data is not tampered |
36 |
with in transit, if man in the middle attack is the concern. |
37 |
|
38 |
Regards, |
39 |
|
40 |
- Brian |
41 |
|
42 |
-- |
43 |
gentoo-security@g.o mailing list |