Re: encrypting files with SSH???

In comp.unix.admin Pham Nuwen <privateaddress1@libertydice.org> wrote:

> No, I didn't stutter, nor am I unaware of PGP, GPG, etc....

> Has anyone seen or used SSH or a SSH based tool to encrypt a file? I've
> been specifically asked to see if this is possible. The idea being that
> we want to take a file and encrypt it, and then send it across a network
> link, and then manually decrypted at the other end, rather than having
> the encryption/decryption done on the fly, as it usually is. (don't ask
> why, I'm not sold on the idea myself, but the theory from our programer
> is that this will speed up the transfer time, I know, I know,...)

> I honestly can't think of a reason this couldn't be done, but having
> never seen. or heard of it I'm at a bit of a loss where to start.

> basically I'd think it would be something like:

> scp -l user filename.txt filename.ssh
correct

> but obviously that isn't it as while it 'works' the output is unencrypted.
The file is encrypted _while transferred_ and decrypted when it arrives to
the destination.

Sniff the link and see for yourself ( unless your sshd is configured to
accept null-encryption )

> --
> ================================================== ==========


--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

In article <bhe06m$15iv$4@nyheter.ipsec.se>, <phn@icke-reklam.ipsec.nu> wrote:
>In comp.unix.admin Pham Nuwen <privateaddress1@libertydice.org> wrote:
>> scp -l user filename.txt filename.ssh
>correct
>
>> but obviously that isn't it as while it 'works' the output is unencrypted.
>The file is encrypted _while transferred_ and decrypted when it arrives to
>the destination.
>
>Sniff the link and see for yourself ( unless your sshd is configured to
>accept null-encryption )

What link? The source and destination files are both local, nothing goes
over the link.

He wants to save the encrypted version in a local file so that he can then
copy it multiple times without having to re-encrypt it each time.

Question for the OP: when you try to decrypt it at each destination, how do
you expect that to work? When SSH is encrypting traffic between two hosts,
it makes use of a public-key encryption algorithm to exchange the
encryption key. But if you use SSH locally, and then transfer the file
using a non-crypto protocol, how is the remote system going to find out
what key to use to decrypt it?

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

In comp.unix.admin Barry Margolin <barry.margolin@level3.com> wrote:
> In article <bhe06m$15iv$4@nyheter.ipsec.se>, <phn@icke-reklam.ipsec.nu> wrote:
>>In comp.unix.admin Pham Nuwen <privateaddress1@libertydice.org> wrote:
>>> scp -l user filename.txt filename.ssh
>>correct
>>
>>> but obviously that isn't it as while it 'works' the output is unencrypted.
>>The file is encrypted _while transferred_ and decrypted when it arrives to
>>the destination.
>>
>>Sniff the link and see for yourself ( unless your sshd is configured to
>>accept null-encryption )

> What link? The source and destination files are both local, nothing goes
> over the link.

Thanks barry, i missed that !



> He wants to save the encrypted version in a local file so that he can then
> copy it multiple times without having to re-encrypt it each time.

> Question for the OP: when you try to decrypt it at each destination, how do
> you expect that to work? When SSH is encrypting traffic between two hosts,
> it makes use of a public-key encryption algorithm to exchange the
> encryption key. But if you use SSH locally, and then transfer the file
> using a non-crypto protocol, how is the remote system going to find out
> what key to use to decrypt it?

Valid point. And diffie-hellman works on the concept of TWO participants,
there is no way to involve many particimants.

In the above i'd vote for a repeated scp to each destination. The extra
cpu-work is a small solvable problem, just add more cpu.

> --
> Barry Margolin, barry.margolin@level3.com
> Level(3), Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

Barry Margolin wrote:
> He wants to save the encrypted version in a local file

Correct.

> so that he can then copy it multiple times without having to
> re-encrypt it each time.

That was speculation by another poster.

> Question for the OP: when you try to decrypt it at each destination,
> how do you expect that to work? When SSH is encrypting traffic
> between two hosts, it makes use of a public-key encryption algorithm
> to exchange the encryption key. But if you use SSH locally, and then
> transfer the file using a non-crypto protocol, how is the remote
> system going to find out what key to use to decrypt it?

I was expecting that the key used would have to reside on the
destination (sort of like how key based authentication works now with
authorized_keys2) and would need to be specified in the command line.

However it was shear conjecture, and as I expected SSH can't do this,
from all appearances. I do think I'm going to pose the question to the
OpenSSH guys though, as this is a potentially nice feature, even if it
is somewhat duplicating PGP/GPG functionality.

--
================================================== ==========