Hey all,
ryonaloli from the irc channel pointed out that the current APK key
size was of 1024. Is there a particular reason that it has stayed at
this size? Also is there any signatures for the ISO releases we
couldn't find any.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 22 Nov 2014 03:13:40 -0800
Orion <systmkor@gmail.com> wrote:
> ryonaloli from the irc channel pointed out that the current APK key> size was of 1024. Is there a particular reason that it has stayed at> this size? Also is there any signatures for the ISO releases we> couldn't find any.
The official Alpine package signing keys are RSA 2048 bits. I checked
all keys from edge all the way back to 2.4, and they are all RSA 2048.
Though, it would be probably good time to start doing EC-DSA signatures
soon. Should probably be a target for alpine-3.2.
/Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
> The official Alpine package signing keys are RSA 2048 bits. I checked> all keys from edge all the way back to 2.4, and they are all RSA 2048.
My appologies. I will do a better check next time. Thank you for
checking that far back.
> Though, it would be probably good time to start doing EC-DSA> signatures soon. Should probably be a target for alpine-3.2.
Sounds like a good idea to me. Is there any given best practices for
EC-DSA and signing?
Also I still can't find the signatures for the ISO releases or a
signature of the hashes.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sun, 23 Nov 2014 21:57:45 -0800
Orion <systmkor@gmail.com> wrote:
> > Though, it would be probably good time to start doing EC-DSA> > signatures soon. Should probably be a target for alpine-3.2.> > Sounds like a good idea to me. Is there any given best practices for> EC-DSA and signing?
There are several. I would probably just go ahead using the openssl the
same way as for RSA. That is to generate ASN1 encoded raw signatures.
For other parameters, I'm considering to use the NIST standard curves .
Ed25519/Curve25519 would be interesting, but seems openssl (at
least any release version) does not support it yet.
The recommended combinations for interoperability seem to be (in PGP,
SSL/TLS, CMS, IKEv2 and other standards):
EC NIST P-256 (equals ~3072 RSA), SHA2-256, AES-128
EC NIST P-384 (equals ~7680 RSA), SHA2-348, AES-192
EC NIST P-521 (equals ~15360 RSA), SHA2-512, AES-256
In our case it's signatures, so just picking a curve + digest would do.
Of these P256 is usually MUST, P521 is SHOULD, and P384 is MAY. So I'm
thinking on going with P256 + SHA2-256 as next step.
> Also I still can't find the signatures for the ISO releases or a> signature of the hashes.
Unfortunately no. This is something we should do (or more like, should
have been doing for a long time). I think doing detached PGP-signatures
like others would be the way to go.
ncopa, any thoughts?
/Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 24 Nov 2014 08:19:02 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Sun, 23 Nov 2014 21:57:45 -0800> Orion <systmkor@gmail.com> wrote:> > > Also I still can't find the signatures for the ISO releases or a> > signature of the hashes.> > Unfortunately no. This is something we should do (or more like, should> have been doing for a long time). I think doing detached PGP-signatures> like others would be the way to go.> > ncopa, any thoughts?
I agree with you. We should have done it long time ago. Not that it is
an excuse but gnupg-2.0 had portability issues with musl (or more
precice, PTH had). Now that gnupg-2.1 is out, there are not even bad
excuses for not doing it.
I created issue #3541 as a reminder.
http://bugs.alpinelinux.org/issues/3541
Thanks!
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---