[SM-Discuss] Compromise on signatures
Seth Alan Woolley
seth at positivism.org
Mon Aug 29 20:52:32 EDT 2005
On Mon, Aug 29, 2005 at 07:22:43PM -0400, Sergey A. Lipnevich wrote:
> Hi All,
> I can think of the following compromise that would hopefully satisfy all sides.
> 1. Sorcery keeps support for hashes and signatures, both optional, but with
> possibility to be restricted by users of individual systems. Here's one for the
We're working on adding a number of choice features in a new sorcery
menu for the existing system, this shouldn't be much more work.
If hashes are not policied out, I plan on adding support for gpg
--print-md and openssl dgst support in addition to hashsum support.
I've already got a backup plan.
> 2. When this option becomes available, we move to digitally sign every
> repository commit. In effect, this will also sign a hash that is stored in
> DETAILS. Should a tarball or both tarball and hash value become compromised,
> our repository will help detect that. For added protection, we can also include
> the size of tarball into DETAILS, effectively signing it as well.
size of tarball doing what exactly?
> This way, we will do exactly what is claimed on that Web page: sign package
> receipt without signing the contents.
a signature is merely an asymmetric encryption of a hash.
What you propose is to make an asymmetric encryption of a hash which includes a hash.
Is this level of indirection that meaningful to you?
> How does appeal to everyone?
Signatures the vast majority of the time ensure transportation security,
not execution security.
They never have meant execution security in the free software world. A
friend of mine was working on including binary signatures into linux
when he worked for Trustix, but the project never carried in the
corporate world, and Microsoft has included binary signature support in
ActiveX and its own .Net framework (parted out as updates to existing
systems and soon to possibly be mandatory in later versions of the OS).
That kind of signature assertion is vastly different than the common use
of PGP in the free software world. Even then, how would they know it's
secure? The fact is, they didn't.
We're NOT doing that kind of validation. Redhat signs their binaries
and srpms -- are they attesting to the security? Nope, just
transportation security. In fact, Microsoft has been the greatest
misinformer of the utility of digital signatures. Digital signatures
make not a secure system.
FIPS 186, the DSA standard: http://www.itl.nist.gov/fipspubs/fip186.htm
digital signatures = integrity, non-repudiatio
"This standard specifies a Digital Signature Algorithm (DSA) which can
be used to generate a digital signature. Digital signatures are used to
detect unauthorized modifications to data"...
integrity (does the whole thing get there uncorrupted? what we're mainly
..."and to authenticate the
identity of the signatory."...
authentication (is it really from us? preventing MIM attacks)
..." In addition, the recipient of signed data can
use a digital signature in proving to a third party that the signature
was in fact generated by the signatory. This is known as nonrepudiation
since the signatory cannot, at a later time, repudiate the signature."
non-repudiation (similar to authentication)
regular hashes can only do integrity. They cannot authenticate in the
form we use them (but c.f. challenge authentication, requiring two-way
communication and an already shared secret unique to each user).
Thus they are ideally situated to our task.
That you believe that there's some sort of transcendental property to
digital signatures confounds me.
If you're concerned about signing things -- generating a special key for
signing and including the signature inside the spell, distributed with
it, signed by our private key, protects against people distributing it
Would you prefer we use openssl routines and PKCS to do the same exact
As far as your compromise, I have an implementation suggestion:
I'm willing to add code to sorcery to check for a DETAILS.asc file (or a
$SPELL.asc file with signatures of all files but $SPELL.asc) that uses
the key pointed to by SPELL_GPG=blah.gpg inside the DETAILS file.
If you're willing to sign your spells like that, that's an adequate
compromise for me, but it would be an error if you DID NOT include
SPELL_GPG=sergey.gpg (and an .asc file) and DID use a SOURCE_HASH in a
spell at the same time under the new policy.
But I don't know how other people will like it :)
> SM-Discuss mailing list
> SM-Discuss at lists.ibiblio.org
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050829/725d5cbd/attachment.bin
More information about the SM-Discuss