openssh unix dev - Jan 2016 - Alternate Open Source Crypto Solution in OpenSSH

On Mon, 4 Jan 2016, Peter Stuge wrote:
> Hi Kaleb,
> 
> Kaleb Himes wrote:
> > OpenSSH port Location:
https://github.com/kaleb-himes/openssh-portable.git
> 
> I'm afraid this repository is too messy to be useful. :\
> 
> You need to use the features offered by git to preserve commit ids if
> anyone else besides yourself is going to be able to work with this,
> in particular developers who otherwise work with the upstream repo.
> 
> If you are interested in contributing your work to the project then
> you have to rebase your changes on top of the current upstream code.
There's another problem - I just noticed that WolfSSL is GPL. We have
no interest in adding support for a GPL crypto library.

-d

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.


On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 4 Jan 2016, Peter Stuge wrote:
>
> > Hi Kaleb,
> >
> > Kaleb Himes wrote:
> > > OpenSSH port Location:
> https://github.com/kaleb-himes/openssh-portable.git
> >
> > I'm afraid this repository is too messy to be useful. :\
> >
> > You need to use the features offered by git to preserve commit ids if
> > anyone else besides yourself is going to be able to work with this,
> > in particular developers who otherwise work with the upstream repo.
> >
> > If you are interested in contributing your work to the project then
> > you have to rebase your changes on top of the current upstream code.
>
> There's another problem - I just noticed that WolfSSL is GPL. We have
> no interest in adding support for a GPL crypto library.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.


On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 4 Jan 2016, Peter Stuge wrote:
>
> > Hi Kaleb,
> >
> > Kaleb Himes wrote:
> > > OpenSSH port Location:
> https://github.com/kaleb-himes/openssh-portable.git
> >
> > I'm afraid this repository is too messy to be useful. :\
> >
> > You need to use the features offered by git to preserve commit ids if
> > anyone else besides yourself is going to be able to work with this,
> > in particular developers who otherwise work with the upstream repo.
> >
> > If you are interested in contributing your work to the project then
> > you have to rebase your changes on top of the current upstream code.
>
> There's another problem - I just noticed that WolfSSL is GPL. We have
> no interest in adding support for a GPL crypto library.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

On Mon 2016-01-04 20:35:05 -0500, Bostjan Skufca wrote:
> Would it make sense to refactor (if it is not done yet) openssh to use
> generic API for communicating with any SSL implementation? Or is the
> general stance on this subject "the new SSL implementation should
provide
> openssl-compatible API to be usable with openssh"?
OpenSSH doesn't use any of the "SSL" (or TLS) features of OpenSSL.
It
just uses it for its library of cryptoprimitives.  There have been
several mentions of possibly swapping out crypto libraries in the past
(a few in the last few months iirc), but it is currently not designed
with such a platform-independent crypto-primitive API in mind.

Damien, you said you're uninterested in linking to a GPL library -- is
OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
nettle, which is licensed LGPL-2.1+, and has a very nice API for
cryptoprimitives)

     --dkg

On Tue, 5 Jan 2016, Bostjan Skufca wrote:
> (I did not look at the code yet, begging forgiveness:)
> 
> How well structured is OpenSSH if one would want to use alternative SSL
> implementation? Or, if I rephrase the question - how married is OpenSSH to
> OpenSSL?
> 
> Would it make sense to refactor (if it is not done yet) openssh to use
> generic API for communicating with any SSL implementation? Or is the
> general stance on this subject "the new SSL implementation should
provide
> openssl-compatible API to be usable with openssh"?
> 
> I have no interest in any side of the argument, just curious.
We're happy to factor out the openssl API, and I've started doing so:

https://github.com/djmdjm/openssh-openbsd/tree/openssl-wrap

This is doing some of the harder parts first: DH and BIGNUM, though
the latter only in KEX. I'd like to wrap all BIGNUM use eventually
though.

Replacing symmetric ciphers and MACs are considerably easier, since
most use of them is via cipher.h and digest.h APIs.

-d