Dear alpine-devel mailing list,

I was looking into using a crypto-service to do Apline package build signatures (as opposed to using a key on disk) and in doing so stumbled across the fact that Alpine package signatures currently use SHA1 digests. After a quick search on https://lists.alpinelinux.org I didn’t see any prior discussions related to this fact and thus am posting this to the mailing list.

I wanted to start a dialog about the possibility of moving to using SHA2 digests (I would presume SHA256 would be the preferred option) for signatures as SHA1 is deemed insecure by many and is being phased out for most usage of PKI. This includes my use case, where the crypto-service I have deliberately no longer offers signatures with SHA1 digests and instead offers standard SHA2 digests.

If the community is interested I’m happy to submit a more formal RFC on this. But, as I’m relatively new to the mailing list, I figured it was best to start with just a dialog!

Cheers,
Ferris



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On 03/07/18 17:28, Ferris Ellis wrote:
> Dear alpine-devel mailing list,
> 
> I was looking into using a crypto-service to do Apline package build
> signatures (as opposed to using a key on disk) and in doing so
> stumbled across the fact that Alpine package signatures currently use
> SHA1 digests. After a quick search on https://lists.alpinelinux.org I
> didn’t see any prior discussions related to this fact and thus am
> posting this to the mailing list.
> 
> I wanted to start a dialog about the possibility of moving to using
> SHA2 digests (I would presume SHA256 would be the preferred option)
> for signatures as SHA1 is deemed insecure by many and is being phased
> out for most usage of PKI. This includes my use case, where the
> crypto-service I have deliberately no longer offers signatures with
> SHA1 digests and instead offers standard SHA2 digests.
> 
> If the community is interested I’m happy to submit a more formal RFC
> on this. But, as I’m relatively new to the mailing list, I figured it
> was best to start with just a dialog!
> 
> Cheers, Ferris


I proposed this in 2015:

https://code.foxkit.us/adelie/packages/raw/ebuild/sys-apps/apk-tools/files/apk-tools-2.6.6-use-sha256-signature.patch

We used this in very early builds of Adélie, and in fact, alpha1 was
shipped with all packages signed using SHA-256.  It wasn't accepted into
upstream apk-tools because there was no compatibility with SHA-1
packages.  I had considered making a backwards-compatible one (possibly
using SH2 instead of RSA as the file name), but life got in the way.

I'd be more than willing to work on this more if it is something the
community desires.

Best to you and yours,
--arw


-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

Hi

On Wed, 7 Mar 2018 18:28:49 -0500
Ferris Ellis <ferris@ferrisellis.com> wrote:

> I was looking into using a crypto-service to do Apline package build
> signatures (as opposed to using a key on disk) and in doing so
> stumbled across the fact that Alpine package signatures currently use
> SHA1 digests. After a quick search on https://lists.alpinelinux.org I
> didn’t see any prior discussions related to this fact and thus am
> posting this to the mailing list.
> 
> I wanted to start a dialog about the possibility of moving to using
> SHA2 digests (I would presume SHA256 would be the preferred option)
> for signatures as SHA1 is deemed insecure by many and is being phased
> out for most usage of PKI. This includes my use case, where the
> crypto-service I have deliberately no longer offers signatures with
> SHA1 digests and instead offers standard SHA2 digests.
> 
> If the community is interested I’m happy to submit a more formal RFC
> on this. But, as I’m relatively new to the mailing list, I figured it
> was best to start with just a dialog!

I have been working to update .apk and index formats to binary. I was
hoping to do the hash algorithm change there. While I do have the
design ready, and some code too, it's taking a bit more than expected.

I am willing to accept backwards compatible patches at this point even
for the current formats. The signatures could be pretty easily updated.
Just add a new prefix type to identify the signatures as rsa-sha256 or
similar.

However, sign only the control.tar.gz part of apk. That in turn
contains hash for the control.tar.gz part containing the package
metadata. Changing this 'identity hash' from sha1 to sha256 would be
more intrusive. Same applies to the individual file checksums kept in
the file database for audit purposes. However, control.tar.gz does have
stronger hash (sha256) for data.tar.gz which contains the actual file
data content.

Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

I suggest BLAKE2b.

https://monocypher.org/manual/crypto_blake2b.html#DESCRIPTION

Faster than MD5, as secure as SHA3.

On Thursday, March 8, 2018, Timo Teras <timo.teras@iki.fi> wrote:
> Hi
>
> On Wed, 7 Mar 2018 18:28:49 -0500
> Ferris Ellis <ferris@ferrisellis.com> wrote:
>
>> I was looking into using a crypto-service to do Apline package build
>> signatures (as opposed to using a key on disk) and in doing so
>> stumbled across the fact that Alpine package signatures currently use
>> SHA1 digests. After a quick search on https://lists.alpinelinux.org I
>> didn’t see any prior discussions related to this fact and thus am
>> posting this to the mailing list.
>>
>> I wanted to start a dialog about the possibility of moving to using
>> SHA2 digests (I would presume SHA256 would be the preferred option)
>> for signatures as SHA1 is deemed insecure by many and is being phased
>> out for most usage of PKI. This includes my use case, where the
>> crypto-service I have deliberately no longer offers signatures with
>> SHA1 digests and instead offers standard SHA2 digests.
>>
>> If the community is interested I’m happy to submit a more formal RFC
>> on this. But, as I’m relatively new to the mailing list, I figured it
>> was best to start with just a dialog!
>
> I have been working to update .apk and index formats to binary. I was
> hoping to do the hash algorithm change there. While I do have the
> design ready, and some code too, it's taking a bit more than expected.
>
> I am willing to accept backwards compatible patches at this point even
> for the current formats. The signatures could be pretty easily updated.
> Just add a new prefix type to identify the signatures as rsa-sha256 or
> similar.
>
> However, sign only the control.tar.gz part of apk. That in turn
> contains hash for the control.tar.gz part containing the package
> metadata. Changing this 'identity hash' from sha1 to sha256 would be
> more intrusive. Same applies to the individual file checksums kept in
> the file database for audit purposes. However, control.tar.gz does have
> stronger hash (sha256) for data.tar.gz which contains the actual file
> data content.
>
> Timo
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>

> On Mar 7, 2018, at 7:07 PM, A. Wilcox <awilfox@adelielinux.org> wrote:
> 
>> On 03/07/18 17:28, Ferris Ellis wrote:
>> ...
>> 
>> I wanted to start a dialog about the possibility of moving to using
>> SHA2 digests (I would presume SHA256 would be the preferred option)
>> for signatures as SHA1 is deemed insecure by many and is being phased
>> out for most usage of PKI. This includes my use case, where the
>> crypto-service I have deliberately no longer offers signatures with
>> SHA1 digests and instead offers standard SHA2 digests.
>> 
>> ...
> 
> I proposed this in 2015:
> 
> https://code.foxkit.us/adelie/packages/raw/ebuild/sys-apps/apk-tools/files/apk-tools-2.6.6-use-sha256-signature.patch
> 
> We used this in very early builds of Adélie, and in fact, alpha1 was
> shipped with all packages signed using SHA-256.  It wasn't accepted into
> upstream apk-tools because there was no compatibility with SHA-1
> packages.  I had considered making a backwards-compatible one (possibly
> using SH2 instead of RSA as the file name), but life got in the way.
> 
> I'd be more than willing to work on this more if it is something the
> community desires.

This is great A. Wilcox! I for one think it would be a very worthwhile addition. Though I think backward compatibility may be easier than changing the file name. I’m not deeply familiar with all things OpenSSL, but my understanding is that the signature is encoded in ASN1. If so then the signature itself will state which hash was used! You could then simply have a config somewhere for apk stating which hashes you trusted.

Cheers,
Ferris



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

> On Mar 8, 2018, at 7:53 AM, Timo Teras <timo.teras@iki.fi> wrote:
> 
> On Wed, 7 Mar 2018 18:28:49 -0500
> Ferris Ellis <ferris@ferrisellis.com> wrote:
> 
>> ...
>> 
>> I wanted to start a dialog about the possibility of moving to using
>> SHA2 digests (I would presume SHA256 would be the preferred option)
>> for signatures as SHA1 is deemed insecure by many and is being phased
>> out for most usage of PKI. This includes my use case, where the
>> crypto-service I have deliberately no longer offers signatures with
>> SHA1 digests and instead offers standard SHA2 digests.
>> 
>> ...
> 
> I have been working to update .apk and index formats to binary. I was
> hoping to do the hash algorithm change there. While I do have the
> design ready, and some code too, it's taking a bit more than expected.
> 
> I am willing to accept backwards compatible patches at this point even
> for the current formats. The signatures could be pretty easily updated.
> Just add a new prefix type to identify the signatures as rsa-sha256 or
> similar.
> 
> However, sign only the control.tar.gz part of apk. That in turn
> contains hash for the control.tar.gz part containing the package
> metadata. Changing this 'identity hash' from sha1 to sha256 would be
> more intrusive. Same applies to the individual file checksums kept in
> the file database for audit purposes. However, control.tar.gz does have
> stronger hash (sha256) for data.tar.gz which contains the actual file
> data content.
> 
> Timo

Timo, thanks for sharing! I’m a little confused by your message. Can you clarify what each of the hashes are? Including the ‘identity hash’ and ‘individual file checksums’? I’m still new to the internals of apk packaging and am only aware of two hashes:

1. The RSA signature hash uses SHA1 as the hash for control.tar.gz.
2. Inside control.tar.gz is the .PKGINFO file which contains a SHA2-256 hash of data.tar.gz

Also, as I mentioned in my last reply to A. Wilcox, I think since the RSA signature is ASN1 encoded. If so you shouldn’t need a new prefix type, as the ASN1 blob states the hash that it contains. But please correct me if I’m wrong on this! Just trying to be of help :)

Cheers,
Ferris

---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Fri, 9 Mar 2018 08:02:50 -0500
Ferris Ellis <ferris@ferrisellis.com> wrote:

> Timo, thanks for sharing! I’m a little confused by your message. Can
> you clarify what each of the hashes are? Including the ‘identity
> hash’ and ‘individual file checksums’? I’m still new to the internals
> of apk packaging and am only aware of two hashes:
> 
> 1. The RSA signature hash uses SHA1 as the hash for control.tar.gz.

Yes. The SHA1 hash for control.tar.gz is also the "identity hash" which
is stored in index files. If .apk installed from repository, the
signature itself is not currently verified, instead the following
happens:
 1. Index file's signature is verified
 2. .apk files 'identity hash' or control.tar.gz hash is verified to
 match against the index file's given SHA1 hash of the package

> 2. Inside control.tar.gz is the .PKGINFO file which contains a
> SHA2-256 hash of data.tar.gz

Correct.

Additionally the PAX tar header contains SHA1 hash for each individual
file. It is not verified during extraction, but it is stored in the
installed database, and used for 'apk audit' which determines the
integrity of current system.

> Also, as I mentioned in my last reply to A. Wilcox, I think since the
> RSA signature is ASN1 encoded. If so you shouldn’t need a new prefix
> type, as the ASN1 blob states the hash that it contains. But please
> correct me if I’m wrong on this! Just trying to be of help :)

Yeah, that would probably work nicely.

So again, doing sha256 signatures is probably simple as the above. But
changing the index file's hash of package's control.tar.gz would be
non-trivial due to backwards compatibility issues. It will also
increase the index size considerably; this would increase apk runtime
memory requirements and have performance side-effects. This is one of
the main issues I want to resolve in the new file formats.

Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Fri, 9 Mar 2018 08:02:50 -0500
Ferris Ellis <ferris@ferrisellis.com> wrote:

> Also, as I mentioned in my last reply to A. Wilcox, I think since the
> RSA signature is ASN1 encoded. If so you shouldn’t need a new prefix
> type, as the ASN1 blob states the hash that it contains. But please
> correct me if I’m wrong on this! Just trying to be of help :)

I was just looking at the code again, and we did add support for sha256
and sha512 + rsa signatures earlier. It detects the signature type from
the filename (RSA, RSA256, RSA512).

The signature it self is raw output of "openssl dgst -sha -sign
pkey.pem" output, and IIRC it is not asn1 but the raw signature for the
mechanism selected.

Cheers,
Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---