1
$\begingroup$

An application that I maintain uses Sparkle Update to update itself. I expect attacks from high level attackers (China, USA's NSA, etc.) and have some questions about how secure the cryptography Sparkle uses actually is. Specific examples of good practices would be much appreciated.

  1. Creating public/private signing keys.

Sparkle uses the following to create public/private signing keys:

openssl dsaparam 2048 < /dev/urandom > dsaparam.pem
openssl gendsa dsaparam.pem -out dsa_priv.pem
openssl dsa -in dsa_priv.pem -pubout -out dsa_pub.pem

1.1 Is using "/dev/urandom" a good idea on OS X?

1.2 Are there any other problems here? (I will probably generate a 4096-bit or larger key instead of the 2048-bit one.)

  1. Signing the application

Sparkle protects from forged updates by signing the updates. It uses the following to generate a signature:

openssl dgst    -sha1 -binary < in-file | openssl dgst -dss1 -sign private-key-file

Would changing it to

openssl dgst  -sha256 -binary < in-file | openssl dgst -dss1 -sign private-key-file

(and changing the signature verification to verify the signature on a SHA256 hash, of course)

be enough to avoid the weakness in SHA1?

Or is there also a problem with "openssl dgst -dss1"?

Thanks in advance.

Improve this question
$\endgroup$
3
  • $\begingroup$ I don't feel confident enough to adventure a full answer here, but here are a few thoughts: you seem thorough and well meaning, and as such I hope that you keep in mind that crypto (and in particular this specific control) is just a (very powerful) tool that needs to be chained with other controls (such as access control and a policy for updating the OpenSSL library, just to name two that are critical). For the specific case, it is my understanding that /dev/urandom is a reliable randomness source, but if the application is very critical, you might want to review generators of true randomness. $\endgroup$
    – Sergio A. Figueroa
    Commented Mar 9, 2016 at 16:29
  • $\begingroup$ On the other hand, it is important to keep in mind what you achieve with a specific control. Will you use raw public keys or certificates? Will you verify the signature and then send application traffic in plaintext? Past this considerations, yes, choose SHA256 over SHA1 for the signature without a doubt. $\endgroup$
    – Sergio A. Figueroa
    Commented Mar 9, 2016 at 16:34
  • $\begingroup$ Sparkle has has vulnerabilities due to insecure update URLs. AIUI the known vulnerabilities have been fixed in the latest version, but it'd still be a good idea to use an https update URL and key pinning. $\endgroup$
    – Gordon Davisson
    Commented Mar 10, 2016 at 17:04

1 Answer 1

Reset to default
1
$\begingroup$

Is using /dev/urandom a good idea on OS X?

Yes. /dev/urandom is the preferred way to get random values on all modern unixes. Arguments that /dev/random are more secure is a complete myth.

Are there any other problems here? (I will probably generate a 4096-bit or larger key instead of the 2048-bit one.)

2048 bits is considered secure and likely will be until ~2030. 4096 bits is overkill — the next logical step is 3072 bits, which is roughly equivalent to a 128-bit symmetric key.

Would changing it to [SHA-256] be enough to avoid the weakness in SHA1?

Probably. But SHA-1 collisions are only just now starting to become computationally feasible. It's worth trying to get upstream to migrate onto a more resistant hash function.

Improve this answer
$\endgroup$
1
  • $\begingroup$ openssl dsaparam N doesn't use stdin at all; default seeding is set by the builder or packager for the platform who should know what's best, but if you want to add to it you use option -rand. dgst -dss1 is only needed on versions below 1.0.0, namely 0.9.8, which as of two months ago is unsupported upstream; and 0.9.8 only generates FIPS186-0:2 subgroup of 160 bits, which means larger group is basically wasted, although you should use 2048 because that's now minimum per 800-57 and 800-131 etc and checklisters will scream for it, whereas most don't know to look at subgroup. $\endgroup$
    – dave_thompson_085
    Commented Mar 10, 2016 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.