Encrypt /decrypta file with ssh keys.

[Colin Leavett-Brown]

Hello, I needed to share some secret info with one or two specific
individuals and wrote a short wrapper script to encrypt/decrypt files
using ssh keys (everyone has at least one pair). In searching, I found
others wanting this functionality and borrowed heavily from this doc
"http://www.czeskis.com/random/openssl-encrypt-file.html" in writing the
script. I am willing to share the code if anyone is interested.

--
Colin Leavett-Brown
Physics and Astronomy
University of Victoria
250-472-4085

_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Alex Bligh]

> On 5 Aug 2016, at 16:30, Colin Leavett-Brown <cr...@uvic.ca> wrote:
>
> Hello, I needed to share some secret info with one or two specific individuals and wrote a short wrapper script to encrypt/decrypt files using ssh keys (everyone has at least one pair). In searching, I found others wanting this functionality and borrowed heavily from this doc "http://www.czeskis.com/random/openssl-encrypt-file.html" in writing the script. I am willing to share the code if anyone is interested.

I was asking for this functionality only yesterday. My particular use was to encrypt a file with someone else's public key, to send to them so they could decrypt with their private key.

If ssh (or some accompanying binary) could do this out the box, it would be great.

--
Alex Bligh

[Colin Leavett-Brown]

As per Alex's suggestion, attached is the proof of concept "sfile"
script. If there is anyone out there with great C skills who can
recreate this functionality "out of the box", I think there would be a
few happy campers (at least two, anyways).



-------- Forwarded Message --------
Subject: Re: Encrypt /decrypta file with ssh keys.
Date: Fri, 5 Aug 2016 17:24:35 +0100
From: Alex Bligh <al...@alex.org.uk>
To: Colin Leavett-Brown <cr...@uvic.ca>
CC: Alex Bligh <al...@alex.org.uk>



Colin,

> On 5 Aug 2016, at 17:03, Colin Leavett-Brown <cr...@uvic.ca> wrote:
>
> Hi Alex, I think this should be part of Openssh. Do you want to try the wrapper? I've attached the code and it does exactly what you want. Let us know what you think. "sfile" without any parms will tell you how to use it. Colin.

I read the code. Interesting. I suspect you will need to rewrite it in C (without relying on distro specific things like readlink -f) and paying close attention to e.g. minimising temporary files, ensuring they are created with the right modes and deleted on signals etc. in order to get it submitted. I think I might make the magic code longer so it can be more easily detected by 'file' etc. But it's an interesting proof of concept - TBH I'd just post it to the list as such.

Alex

>
>
> On 16-08-05 08:50 AM, Alex Bligh wrote:
>>> On 5 Aug 2016, at 16:30, Colin Leavett-Brown <cr...@uvic.ca> wrote:
>>>
>>> Hello, I needed to share some secret info with one or two specific individuals and wrote a short wrapper script to encrypt/decrypt files using ssh keys (everyone has at least one pair). In searching, I found others wanting this functionality and borrowed heavily from this doc "http://www.czeskis.com/random/openssl-encrypt-file.html" in writing the script. I am willing to share the code if anyone is interested.
>> I was asking for this functionality only yesterday. My particular use was to encrypt a file with someone else's public key, to send to them so they could decrypt with their private key.
>>
>> If ssh (or some accompanying binary) could do this out the box, it would be great.
>>
>
> --

> Colin Leavett-Brown
> Physics and Astronomy
> University of Victoria
> 250-472-4085
>

> <sfile.txt>

--
Alex Bligh

[James Murphy]

The more mainstream thing to do is just use gpg, which has this
functionality already built in. Is this not suitable for your use case?

[Colin Leavett-Brown]

As the encrypter, you can use someone's shared public key knowing that
only they can decrypt it. If I use GPG, I somehow have to give them the key.


On 16-08-05 10:19 AM, Jack Dodds wrote:
> Respectful question:
>
> What would be the advantage of this over GPG, which is expressly
> designed for encryption/decryption/signing of files?
>
> Jack Dodds

[Alex Bligh]

> On 5 Aug 2016, at 18:09, James Murphy <james.mur...@gmail.com> wrote:
>
> The more mainstream thing to do is just use gpg, which has this
> functionality already built in. Is this not suitable for your use case?

The advantage of Colin's approach is that gpg requires out of band exchange
of gpg keys separately from ssh keys. If you already have ssh keys
distributed (which might be in an automated environment for instance),
it would be very useful.

Of course if you already have gpg keys set up and exchanged, gpg
would be just fine.

--
Alex Bligh

[Ben Lindstrom]

Alex Bligh wrote:
>> On 5 Aug 2016, at 18:09, James Murphy<james.mur...@gmail.com> wrote:
>>
>> The more mainstream thing to do is just use gpg, which has this
>> functionality already built in. Is this not suitable for your use case?
>
> The advantage of Colin's approach is that gpg requires out of band exchange
> of gpg keys separately from ssh keys. If you already have ssh keys
> distributed (which might be in an automated environment for instance),
> it would be very useful.
>
> Of course if you already have gpg keys set up and exchanged, gpg
> would be just fine.
>

The downside to this approach is your using keys created for signing for
encryption now. Which
means you've leaked additional information about the key material. Thus
slightly weakening the
security of your key.

Which isn't really a smart thing to do.

Ben

[Daniel Kahn Gillmor]

On Fri 2016-08-05 11:30:17 -0400, Colin Leavett-Brown wrote:
> Hello, I needed to share some secret info with one or two specific
> individuals and wrote a short wrapper script to encrypt/decrypt files
> using ssh keys (everyone has at least one pair). In searching, I found
> others wanting this functionality and borrowed heavily from this doc
> "http://www.czeskis.com/random/openssl-encrypt-file.html" in writing the
> script. I am willing to share the code if anyone is interested.

I'd recommend *not* doing this kind of cross-protocol use of key
material. There are often attacks that you don't expect when you reuse
keys like this.

For example, consider a variant of the ssh protocol (or a bug in an
implementation) that allows the ssh server to select the message that
the client has to sign in order to authenticate.

an ssh server that gets ahold of an encrypted message of the type you're
proposing might be able to transform the encrypted session key into an
authentication message. the next time the user goes to log in, in
addition to authenticating, it is effectively offering the server the
secret needed to decrypt the stored message.

I'm not saying this attack works directly with ssh as-implemented. (i
actually suspect it doesn't, because i believe ssh's authenticatin
mechanism should require contributory behavior from both parties over
the message to be signed, though i haven't reviewed it recently enough
to be sure), but (a) implementation bugs happen, and (b) sometimes
protocols have weaknesses that we don't understand at first glance.

Key reuse across application domains will expose the user to classes of
bug and attack that we really don't understand well and are difficult to
reason about systematically. It's generally ill-advised.

That said, you can still bind keys together and associate them with
other keys. OpenPGP is an example of that -- you can bind your SSH key
into your OpenPGP key as a subkey, and then it will be associated with a
bunch of other keys, each of which can be designated for a specific
purpose.

--dkg

[Alex Bligh]

> On 5 Aug 2016, at 18:40, Ben Lindstrom <mou...@offwriting.org> wrote:
>
> The downside to this approach is your using keys created for signing for encryption now. Which
> means you've leaked additional information about the key material. Thus slightly weakening the
> security of your key.
>
> Which isn't really a smart thing to do.

I've not looked deeply at Colin's code, but it seems to be creating a random symmetric
key and only encrypting that. It's not (directly) encrypting the files (that's done
with the symmetric key). If that's the case, a plaintext attack etc. is going to
be pretty hard, because the only thing the key is used for is encrypting a large
random number. I think that's actually pretty safe (signing is after all
encrypting the result of a hash function), but no doubt more experienced
cryptographers can comment.

--
Alex Bligh

[Ron Frederick]

On Aug 5, 2016, at 10:40 AM, Ben Lindstrom <mou...@offwriting.org> wrote:

> Alex Bligh wrote:
>>> On 5 Aug 2016, at 18:09, James Murphy<james.mur...@gmail.com> wrote:
>>>
>>> The more mainstream thing to do is just use gpg, which has this
>>> functionality already built in. Is this not suitable for your use case?
>>
>> The advantage of Colin's approach is that gpg requires out of band exchange
>> of gpg keys separately from ssh keys. If you already have ssh keys
>> distributed (which might be in an automated environment for instance),
>> it would be very useful.
>>
>> Of course if you already have gpg keys set up and exchanged, gpg
>> would be just fine.
>>

> The downside to this approach is your using keys created for signing for encryption now. Which
> means you've leaked additional information about the key material. Thus slightly weakening the
> security of your key.
>
> Which isn't really a smart thing to do.

Since public key crypto is being used here, you also can’t encrypt something larger than the key size directly. You’d have to create a symmetric key, encrypt the data with that, and then encrypt the symmetric key with the public key. You’d then need to also define a container format for that. It looks like the “sfile” code does all that, but at that point why not use “openssl cms”? It will work with the same public keys used by SSH and already provides a standard format for this encoding.
--
Ron Frederick
ro...@timeheart.net