Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
To: "Timo Teras" <timo.teras@iki.fi>
Cc: <~alpine/apk-tools@lists.alpinelinux.org>
Subject: Re: Support for alternative crypto libraries
From: "Paul Spooren" <mail@aparcar.org>
Date: Sat, 10 Oct 2020 21:49:11 -1000
Message-Id: <C69WAPL9SHXO.36XTXYSB2UCOJ@dawn>
In-Reply-To: <20201011100031.005fbd8c@vostro.wlan>

Hi,

On Sat Oct 10, 2020 at 9:00 PM HST, Timo Teras wrote:
> > Are there any intentions or interest to allow different libraries for
> > either use case? I'm asking because I'd like to see APK as a
> > replacement for OpenWrts current package manager (`opkg`), but the
> > libssl/libcrypto combination is to heavy for most WiFi routers.
>
> Nice! So far our "embedded" has been low end ARMv6+ chips. Generally
> RPI1/2 being the target. And in fact running apk with full alpine
> indexes there is starting to be slowing down. So this was another
> motivation for the v3 changes.
>
> I understand you are interested running on even more resource
> constrained environment. And I'd be happy to support where possible. I
> understand this might also mean additional options to reduce index size
> etc.

Yes, it would be very helpful if you could give me some pointers where
other parts could be stripped down.

>
> > OpenWrt traditionally uses unencrypted HTTP to download packages and
> > verifies them via a `signify`[1] fork called `usign`[2]. Both public
> > keys and signatures are extremely small, ideal for embedded devices.
> >=20
> > To be *OpenWrt compatible* I'd like to integrate a curve based
> > signature method, e.g. Ed25519 like `signify` or Curve25519/Gimli
> > based like `libhydrogen`[3]. The latter comes with its own secure
> > hashing mechanism and takes about 50Kb as a shared library.
>
> Which hash? Would it make sense then to use that hash for file
> integrity checks during extraction and 'audit' command?

I think the `libhydrogen` could be *too modern*[1], as in not trivial to
use with openssl. It's maybe more of a all or nothing approach, which
I'd be fine with, as v3 seems to change things from group up anyway.

[1]: https://github.com/jedisct1/libhydrogen/wiki/Generic-hashing#algorithm


>
> It might make sense to make Ed25519 the default for both builds.

So maybe it makes more sense to use tweetnacl[2] instead of libhydrogen.
It's also small, uses ed25519[3] and sha-512[4], would therefore be a
compatible with tools like signify and usign.

Maybe someone with more cryptographic insights should step up here and
make a statement.

[2]: https://tweetnacl.cr.yp.to/
[3]: https://nacl.cr.yp.to/sign.html
[4]: https://nacl.cr.yp.to/hash.html

>
> I assume the same crypto primitives are available also from openssl?
> Preferable then the openssl would be exetended to support also these.

Openssl does seem to support ed25519[5], however CLI support is
currently missing.

Apart from the primitives, we should agree on a key and signature
format. I'd suggest to follow the same structure as signify does[6].=20

[5]: https://www.openssl.org/docs/manmaster/man7/Ed25519.html
[6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

>
> > Looking at the APK code some wrappers around the hashing/verifying
> > could do the trick, some `ifndef` within `libfetch` could disable
> > HTTPS support (and thereby lose the `libopenssl` dependency.
> >=20
> > As v3 seems to be changing quite some things, if now is the right time
> > to discuss such changes.
>
> Yes. Thin wrappers in separate file, perhaps in the new apk_trust.h or
> separate apk_crypto.h depending how much it ends up being in code lines.

I'll look into that, good pointer.

>
> Optionally disabling https in libfetch also sounds acceptable.

Great. In fact we're looking libfetch entirely with a smaller OpenWrt
libary, but that shouldn't be scope of this thread.

>
> As noted the v3 is currently in state of flux, and I'm hoping to next
> start reworking the info/search/list type applets that do read-only
> operations.
>
> So for the adb format these are welcome now. I still need let some time
> to pass to see if we can make the new package format (Adb based) happen
> sooner than later, and the adb changes alone would be enough. Depending
> on time pressure and how things go, we can consider also amending the
> current .apk format (but obviously I'd want to avoid that if possible).

I looked shortly into that and we could simply add another signature in
the format `.SIGN.SIGNIFY.<fingerprint>.sig`. But as the whole migration
process within OpenWrt takes easily a year, I'd focus on v3 only.

Best,
Paul