code of conduct signing procedure forces signer to open themselves up to possible attack

[Allison Karlitskaya]

Currently, in order to sign a code of conduct I am asked to download a copy of the document and generate a gpg clearsignature of it. I then upload the clearsignature. Launchpad checks the following:

  1. The document has been signed by a GPG key on file.
  2. The signature is valid.
  3. The SHA1 sum of the original document is the same as the SHA1 sum of the document that I've signed.

The problem is check #3.

If I sign any document that is presented to me then I am opening myself up to the possibility of a birthday attack. Without getting into too many technical details, a birthday attack (in this context) is a method of obtaining two documents that hash to the same value with substantially less difficulty than obtaining a document that hashes to a given value.

Specifically, someone could generate a text document which states "I agree to give all of my money to Alice" and one that looks surprisingly like a valid code of conduct. By then making minor changes to each of the two documents (introduction of white space, changing line wrapping, changes in wording, etc) the attacker can use the principle of a birthday attack to find two documents with the same hash value.

By signing the document as it is presented to me I am now effectively signing both documents (and therefore agreeing to give all of my money to Alice).

For this reason, it is recommended by many security experts that before signing any document that is presented to you to be signed, you make some cosmetic adjustments to it (insertion of white space, etc) in order to change the hash value and prevent yourself from being attacked in this way. This approach is recommended, for example, by Bruce Schneier (Counterpane).

Launchpad should support the verification of signed codes of conduct which have had cosmetic changes made to them. Until the time that such a feature is introduced, everyone would be wise to refuse to sign the code.

[James Henstridge (jamesh)]

Supporting this would be fairly easy: just run split() on the signed document and the original document (this will split on any sequence of whitespace). If the two sequences of words match, then we should accept the signature.

This would also cover the cases where people copy and paste the CoC from the website and add or remove a newline somewhere.

Handling rewording won't happen though (we may have translated versions in the future though).

[Allison Karlitskaya (desrt)]

I've talked to elmo about this and he's unwilling to move on the issue.

This bug is therefore preventing me from receiving mail at my ubuntu.com email address.

[Allison Karlitskaya (desrt)]

Ian Jackson has indicated to me that he believes the problem to be somewhat worse than I originally stated in light of the recent attacks against SHA-1 (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html). This attack gives a further 2^11 reduction in complexity on finding hash collisions for the full-blown SHA-1 as used in GPG.

[Martin Pool (mbp)]

I am not convinced this is a practically important launchpad bug, rather than a GPG bug. Perhaps GPG should add a nonce to the data used in creating the signature.

[Steve Alexander (stevea)]

Martin is right that this isn't all that important in practice. IWJ pointed out that people can use a separate key for sigining the CoC if they want to.

We should add stripping-CoC-comparison code, so that whitespace doesn't matter (or any whitespace is considered as a single space, to avoid runningwordstogether to make it mean something else).

We should also add a line to the end of the CoC that goes something like:

  Optional line of text to make the document unique: [add some letters and numbers here]