Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 55D40781925 for <~alpine/apk-tools@lists.alpinelinux.org>; Sun, 11 Oct 2020 08:21:15 +0000 (UTC) X-Originating-IP: 72.234.141.215 Received: from localhost (udp224251uds.hawaiiantel.net [72.234.141.215]) (Authenticated sender: mail@aparcar.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id AC15F1BF204; Sun, 11 Oct 2020 08:21:13 +0000 (UTC) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 To: "Timo Teras" Cc: <~alpine/apk-tools@lists.alpinelinux.org> Subject: Re: Support for alternative crypto libraries From: "Paul Spooren" Date: Sat, 10 Oct 2020 21:49:11 -1000 Message-Id: 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..sig`. But as the whole migration process within OpenWrt takes easily a year, I'd focus on v3 only. Best, Paul