Date: Sun, 11 Oct 2020 10:00:31 +0300
From: Timo Teras <timo.teras@iki.fi>
To: "Paul Spooren" <mail@aparcar.org>
Cc: <~alpine/apk-tools@lists.alpinelinux.org>
Subject: Re: Support for alternative crypto libraries
Message-ID: <20201011100031.005fbd8c@vostro.wlan>
In-Reply-To: <C69I2YOYQ0T1.1RY2XOLX1TMKX@dawn>
References: <C69I2YOYQ0T1.1RY2XOLX1TMKX@dawn>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

On Sat, 10 Oct 2020 10:40:48 -1000
"Paul Spooren" <mail@aparcar.org> wrote:

> I'm new to this list and hope this RFC like question is fine!
> 
> >From my understanding APKs security is entirely based on
> >`libopenssl`,  
> used for both HTTPS in `libfetch` and for package signature validation
> via public keys.

Correct. openssl (or libressl) has been de facto standard for the
targets we've had so far.

> 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.

> 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.
> 
> 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?

It might make sense to make Ed25519 the default for both builds.

I assume the same crypto primitives are available also from openssl?
Preferable then the openssl would be exetended to support also these.

> 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.
> 
> 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.

Optionally disabling https in libfetch also sounds acceptable.

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).

Cheers,
Timo