dropping standalone ecl builds

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dropping standalone ecl builds

Franziskus Kiefer
Hi all,

we intend to drop support for standalone ecl builds in NSS [1]. Before
doing this we'd like to get feedback if anyone's still doing this.

So if you're still building ecl, please let us know.

Cheers,
Franziskus

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1274967
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: dropping standalone ecl builds

Hanno Böck-4
Hi,

On Thu, 26 May 2016 11:27:04 +0200
Franziskus Kiefer <[hidden email]> wrote:

> we intend to drop support for standalone ecl builds in NSS [1]. Before
> doing this we'd like to get feedback if anyone's still doing this.
>
> So if you're still building ecl, please let us know.

I recently used the ecl standalone build to fuzz elliptic curve
implementations. While this didn't find bugs in nss, it found a couple
in another TLS implementation (Nettle) [1].

The fuzzing code is here:
https://github.com/hannob/bignum-fuzz/blob/master/point-fuzz.c

As far as I can see the low level elliptic curve calculation functions
aren't exposed as public functions in NSS itself. Therefore removing the
possibility to build libecl would make it significantly harder to test
the underlying functionality. Therefore I'd strongly oppose removing it
unless there is any alternative for testing that's equally simple and
that I'm not aware of.

[1]
https://blog.fuzzing-project.org/38-Miscomputations-of-elliptic-curve-scalar-multiplications-in-Nettle.html

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dropping standalone ecl builds

Franziskus Kiefer
Hi Hanno,

thanks for your feedback. That's a great use-case of ecl as standalone
library. Removal of ecl as a library is part of a bigger effort to clean up
NSS and make it easier to use.

As far as I can see the low level elliptic curve calculation functions
> aren't exposed as public functions in NSS itself.


You're right. But dropping ecl builds goes together with the work in [1],
which allows you to build NSS with FREEBL_TEST=1 (the exact name might
change) that provides you with an NSS build (a freebl library) that exposes
all internal functions. This makes testing of NSS (in particular freebl
internals) simpler and allows you to do for example the things you used the
standalone ecl library for.

Would this work for you? The only difference would be the library you link
against and that you have to build all of NSS.

Cheers,
Franziskus

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1253910


On Tue, May 31, 2016 at 3:05 AM, Hanno Böck <[hidden email]> wrote:

> Hi,
>
> On Thu, 26 May 2016 11:27:04 +0200
> Franziskus Kiefer <[hidden email]> wrote:
>
> > we intend to drop support for standalone ecl builds in NSS [1]. Before
> > doing this we'd like to get feedback if anyone's still doing this.
> >
> > So if you're still building ecl, please let us know.
>
> I recently used the ecl standalone build to fuzz elliptic curve
> implementations. While this didn't find bugs in nss, it found a couple
> in another TLS implementation (Nettle) [1].
>
> The fuzzing code is here:
> https://github.com/hannob/bignum-fuzz/blob/master/point-fuzz.c
>
> As far as I can see the low level elliptic curve calculation functions
> aren't exposed as public functions in NSS itself. Therefore removing the
> possibility to build libecl would make it significantly harder to test
> the underlying functionality. Therefore I'd strongly oppose removing it
> unless there is any alternative for testing that's equally simple and
> that I'm not aware of.
>
> [1]
>
> https://blog.fuzzing-project.org/38-Miscomputations-of-elliptic-curve-scalar-multiplications-in-Nettle.html
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: [hidden email]
> GPG: BBB51E42
>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: dropping standalone ecl builds

Hanno Böck-4
On Tue, 31 May 2016 07:56:21 +0200
Franziskus Kiefer <[hidden email]> wrote:

> thanks for your feedback. That's a great use-case of ecl as standalone
> library. Removal of ecl as a library is part of a bigger effort to
> clean up NSS and make it easier to use.
>
> As far as I can see the low level elliptic curve calculation functions
> > aren't exposed as public functions in NSS itself.  
>
>
> You're right. But dropping ecl builds goes together with the work in
> [1], which allows you to build NSS with FREEBL_TEST=1 (the exact name
> might change) that provides you with an NSS build (a freebl library)
> that exposes all internal functions. This makes testing of NSS (in
> particular freebl internals) simpler and allows you to do for example
> the things you used the standalone ecl library for.
>
> Would this work for you? The only difference would be the library you
> link against and that you have to build all of NSS.
Based on my experience the build of NSS is much murkier than the build
of libmpi/libecl. Of course this is an issue on its own which maybe
should be improved in general.

I always found it very convenient that libmpi/libecl could be built as
a static library (.a) very easily with custom cflag/cc settings.

As far as I'm aware there is no easy way to do this with nss. Also
cflags/cc variable handling seems rather unusual and things like USE_64
complicate things.

If things were as simple as
make FREEBL_TEST=1 CC=[something] CXX=[something] libnss.a
then I'd be happy, but I think it ain't that easy right now.

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dropping standalone ecl builds

Franziskus Kiefer
>
> If things were as simple as
> make FREEBL_TEST=1 CC=[something] CXX=[something] libnss.a
> then I'd be happy, but I think it ain't that easy right now.


NSS in general doesn't support a lot of statical linking.  But if you're ok
with dynamical linking it's pretty easy. I just tested your use case
(point-fuzz.c) and it works just fine.
Building NSS is pretty straight forward using make nss_build_all (for your
use case you want to set FREEBL_TEST=1 once the patch landed, and probably
USE_64=1). Then you can link against libfreebl3.so (dylib/dll).
(There are currently some oddities that doesn't allow you to use CC/CXX
properly in some cases, but that's a separate issue that hopefully gets
fixed soon.)


On Sat, Jun 4, 2016 at 3:38 PM, Hanno Böck <[hidden email]> wrote:

> On Tue, 31 May 2016 07:56:21 +0200
> Franziskus Kiefer <[hidden email]> wrote:
>
> > thanks for your feedback. That's a great use-case of ecl as standalone
> > library. Removal of ecl as a library is part of a bigger effort to
> > clean up NSS and make it easier to use.
> >
> > As far as I can see the low level elliptic curve calculation functions
> > > aren't exposed as public functions in NSS itself.
> >
> >
> > You're right. But dropping ecl builds goes together with the work in
> > [1], which allows you to build NSS with FREEBL_TEST=1 (the exact name
> > might change) that provides you with an NSS build (a freebl library)
> > that exposes all internal functions. This makes testing of NSS (in
> > particular freebl internals) simpler and allows you to do for example
> > the things you used the standalone ecl library for.
> >
> > Would this work for you? The only difference would be the library you
> > link against and that you have to build all of NSS.
>
> Based on my experience the build of NSS is much murkier than the build
> of libmpi/libecl. Of course this is an issue on its own which maybe
> should be improved in general.
>
> I always found it very convenient that libmpi/libecl could be built as
> a static library (.a) very easily with custom cflag/cc settings.
>
> As far as I'm aware there is no easy way to do this with nss. Also
> cflags/cc variable handling seems rather unusual and things like USE_64
> complicate things.
>
> If things were as simple as
> make FREEBL_TEST=1 CC=[something] CXX=[something] libnss.a
> then I'd be happy, but I think it ain't that easy right now.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: [hidden email]
> GPG: BBB51E42
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto