Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Subject: Support for alternative crypto libraries
From: "Paul Spooren" <mail@aparcar.org>
To: <~alpine/apk-tools@lists.alpinelinux.org>
Date: Sat, 10 Oct 2020 10:40:48 -1000
Message-Id: <C69I2YOYQ0T1.1RY2XOLX1TMKX@dawn>

Hi all,

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.

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.

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.

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.

Best,
Paul


[1]: https://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://git.openwrt.org/?p=3Dproject/usign.git
[3]: https://github.com/jedisct1/libhydrogen