Subject: Support for alternative crypto libraries

From: "Paul Spooren" <[email-masked]>
Date: Sat, 10 Oct 2020 10:40:48 -1000

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=project/usign.git
[3]: https://github.com/jedisct1/libhydrogen

---

From: Timo Teras <[email-masked]>
Date: Sun, 11 Oct 2020 10:00:31 +0300

Hi,

On Sat, 10 Oct 2020 10:40:48 -1000

> used for both HTTPS in `libfetch` and for package signature validation

Correct. openssl (or libressl) has been de facto standard for the
targets we've had so far.

> 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.

> 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.
> 

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

---

From: "Paul Spooren" <[email-masked]>
Date: Sat, 10 Oct 2020 21:49:11 -1000

Hi,

> understand this might also mean additional options to reduce index size

Yes, it would be very helpful if you could give me some pointers where
other parts could be stripped down.

> 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

> 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]. 

[5]: https://www.openssl.org/docs/manmaster/man7/Ed25519.html
[6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

> 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.

> 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

---

From: Timo Teras <[email-masked]>
Date: Sun, 11 Oct 2020 14:14:39 +0300

On Sat, 10 Oct 2020 21:49:11 -1000
"Paul Spooren" <[email-masked]> 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
> > constrained environment. And I'd be happy to support where
> > possible. I understand this might also mean additional options to
> > reduce index size etc.  
> 

That really depends on what requirements you have. We can consider
making optional everything that is considered extra (e.g. not needed
for package dependencies or installation). Could include
description, maintainer, origin, reference urls, etc. Or is some of
this something you need to display somewhere?

> 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
> 
> 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.
> 

I have currently no strong opinion what the alternative library should
be. As long as it satisfied your size requirement and is suitable
enough API to be usable in the current code base without major
refactoring.

> Openssl does seem to support ed25519[5], however CLI support is

Yes.

> [6]: https://github.com/aperezdc/signify/blob/master/signify.c#L54

Currently key generation is not in scope for apk. And I think I would
like to keep it like that. Make apk use keys generated by other tools

We could fairly easily support multiple key formats if needed. But
currently it's using openssl pkey infrastructure to load PEM private
keys which seems to be fairly standard solution. I think adding support
for signify keys should not be a problem.

However, the signatures are embedded as part of the file structures, so
trying to make them compatible when you cannot anyway use the external
tool sounds little bit unnecessary complication. The code for adb
signatures has already been written. But if there's strong(er) reasons
to adjust that, it is still possible.

> > > 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.  
> 

Right. That may deserve it's own thread. I would be happy to look at
replacing the libfetch too. I am not full satisfied with it as-is.
Options being fixing libfetch, finding something else, or in worst case
writing something to replace it.

The history is that originally apk fork+execed wget with fallback to
busybox wget. We sought for library that would be easy enough to link
in statically and support enough of http things. We ended up with
libfetch and it's fairly ok. Though we've needed to fix certain things
in it in-tree for linux.

I think the current feature set is basic http support, https support
which should be optional, basic authentication, if-modified-since,
cache-control, netrc, connection pooling, proxy support (via
environment variables).

The things I am additional looking for are no extra memcpys, so the
data could be directly received to user given buffer when possible;
automatic retries in case of connections problems (potentially
supporting switching mirrors), proper buffering for request sending,
and potentially http/2 support.

> > 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.

Yes, I think adding the new signature in v2 packages is not problem.
Anything with new signature specifier there should be ok. I would just
like to avoid getting these package out at all if possible.

The main motivation in V3 package format is that the manifest is
signed, and the signed-manifest is directly copied to installed-db.
This allows later on 'apk audit' to verify the signatures and whole
filesystem retroactive against the original asymmetric signatures.

Timo