> On 5 Aug 2016, at 18:09, James Murphy <james.murphy.debian at 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
Alex Bligh wrote:>> On 5 Aug 2016, at 18:09, James Murphy<james.murphy.debian at 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
> On 5 Aug 2016, at 18:40, Ben Lindstrom <mouring at 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
On Aug 5, 2016, at 10:40 AM, Ben Lindstrom <mouring at offwriting.org> wrote:> Alex Bligh wrote: >>> On 5 Aug 2016, at 18:09, James Murphy<james.murphy.debian at 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 ronf at timeheart.net