On 07/ 2/10 01:55 AM, Darren J Moffat wrote:
On 02/07/2010 02:55, Brock Pytlik wrote:
There is no reason to use md5 today, and there are
others that OpenSSL supports like md2 and md4 that should
definitely not be used.
I'd recommend only supporting sha256,384,512 and maybe sha1.
It would actually be good to have the signature algorithm
being part of the policy.
I'm not opposed to adding another signature-policy which allows the user
to decide on acceptable or unacceptable policies. I purposefully
designed the policy infrastructure to allow other methods to be added in
the future.
As for which digests we support. I'd like to understand better why we
would ever want to forbid a user from using a particular digest which we
could support. I would've though providing a sane default would be
enough. Further, if openssl decides to remove sha1, for example, I
didn't want to be in a situation where we had promised a bug-for-bug
substitute for the removed functionality.
I'd be happy to document our suggestions (like "While openssl currently
supports the md2, md4, md5, and sha1 hashing algorithms, we strongly
recommend against using them.") If a user/publisher is making a
conscious decision to use a different algorithm, should we breaking them
when we could do what they want?
Users shouldn't be making that choice because they don't know what
they are doing in this area most of the time. There is a very good
reason why governments put a lot of funding into cryptography and
standards bodies such as NIST/FIPS and their equivalents outside the US.
md2 and md4 are broken. MD5 and SHA1 are weaker than first thought
and are out of favour by the crypto community.
When dealing with crypto algorithms it is advisable to be flexible in
your code so you can easily adapt to newer algorithms and deal with
deprecating algorithms when they are broken or otherwise go out of
favour. However it is also very important to stop users hurting
themselves by allowing them to choose known broken algorithms.
Given that in this case there are no backwards compatibility issues
really the only acceptable choices are sha256/384/512 and personally I
don't see much need for anything other than sha256.
I very strongly recommend against mentioning anything about OpenSSL -
it is an implementation detail not part of the interface of pkg(5).
Ok, I recognize consensus when I see it. I'll rewrite this section of
the man page.
The important thing though is that by not storing the fact you
are using rsa to sign the hash it is harder to extend this
to Elliptic Curve (or DSA) later.
While we could always treat the absence of the tag as meaning
rsa-sha256, I agree having this tag present from the beginning would be
useful.
One question w/ regard to that tag, would just having rsa be sufficient
given that pkg.hashalg notes that it's sha256? Or can you have a hash
algorithm of sha256 and then use rsa-sha384 as the signature algorithm?
That seems nonsensical to me, but I'm flying by the seat of my pants
here a bit.
In theory yes you can do that but it wouldn't be normal in a case like
this.
You have to specific both the digest (hash) algorithm and the signing
algorithm. So rsa-sha256, dsa-sha256, ecdsa-sha256 are the types of
things we expect to see now, and post 2013 we will start seeing
ecdsa-sha3.
Ok, just to make sure there's no confusion, there will be a pkg.hashalg
attribute on the action which has a value like, "sha256" and then a
pkg.sigalg attribute which has a value like "rsa-sha256", instead of "rsa".
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
