OpenSSH
[Top] [All Lists]

Re: Pawel Krupinski's ssh-decrypt ssh-encrypt proposal

To: openssh-unix-dev@mindrot.org
Subject: Re: Pawel Krupinski's ssh-decrypt ssh-encrypt proposal
From: Pawel Krupinski <pak76_ml@yahoo.co.uk>
Date: Thu, 23 Nov 2006 09:14:01 +0000 (GMT)
Delivered-to: sp-com-lists@consult.net
Delivered-to: openssh-unix-dev-list1@securepoint.com
Delivered-to: openssh-unix-dev-tmda@mindrot.org
Delivered-to: openssh-unix-dev@mindrot.org
List-archive: <http://lists.mindrot.org/pipermail/openssh-unix-dev>
List-help: <mailto:openssh-unix-dev-request@mindrot.org?subject=help>
List-id: Development of portable OpenSSH <openssh-unix-dev.mindrot.org>
List-post: <mailto:openssh-unix-dev@mindrot.org>
List-subscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=subscribe>
List-unsubscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=unsubscribe>
Sender: openssh-unix-dev-bounces+openssh-unix-dev-list1=securepoint.com@mindrot.org
Hi Peter,

> http://www.gentoo.org/proj/en/keychain/ may also be
interesting.

It is interesting and actually it is something I have
in my mind as a backup solution... 

In my case: we are using OpenSSH, so we have
infrastructure to support OpenSSH based solution. With
gpg we would have to create a new infrastrcuture from
scratch and the purpose of this infrastructure would
be exactly the same - cryptographic solution capable
to perform private/public key operations; therefore we
think it is just better for us to stick to OpenSSH -
we like to keep things simple.

If I fail to convince you, we either:
1. Support this solution internally (hopefully you are
not changing ssh-agent interface too often ;-)));
2. We will look into alternative solutions, such as
gpg based.

One question regarding keychain. Quoting the keychain
page: "It acts as a front-end to ssh-agent". Do you
guys work with them to make sure that patches/changes
to the API don't affect their solution? This is the
only thing that puts us off from the internal support,
so wondering how others handling it. 

> As for ssh-agent, I'm not sure I want it to do any 
> tricks. I trust it
> with my keys so I want it to be REALLY simple.

Well, not sure if I called it a trick - "give
passphrase once, use private key multiple times" is
what ssh-agent is for ;-)))
Currently there is another tool ssh-sign and using the
configuration file you can turn it on and off. The
same can be applied to ssh-{en|de}crypt.
If this change would require changes to API etc, I
wouldn't have put forward this solution, but as these
changes seems pretty easy, I think it is worth it.

Cheers,
- pak76



It seems there were some maintenance things going on
yesterday with the server, so I will repost my
yesterday's e-mail:

Hi,

Not sure if you had time to go through the code.
Changes I did to OpenSSH are rather limited - OpenSSH
is written in such a way that I didn't have to change
communication channel between applications and
ssh-agent. Implementation of the ssh-decrypt was as
easy as establishing a new message, search the keys
and decrypting using the private key.

As I said it was just a very quick PoC, but if it is
of interest to OpenSSH, I can develop it correctly
over the next few days and have it up and ready on
Monday.

One question regarding the interface. As ssh-agent can
have multiple keys, what would be the best way to
determine which one to use ? Sending the public part?
Currently I'm trying out all keys and it is not the
best possible option...

Thanks,
pak76


Send instant messages to your online friends http://uk.messenger.yahoo.com 
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

<Prev in Thread] Current Thread [Next in Thread>