Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: devel

--blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg]

 

 

GnuPG devel RSS feed   Index | Next | Previous | View Threaded


dkg at fifthhorseman

May 7, 2009, 9:11 AM

Post #1 of 5 (691 views)
Permalink
--blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg]

On 05/07/2009 11:34 AM, David Shaw wrote:
> So, thus far, the plan sounds like:
>
> --blacklist-digest-algo (name or number)
> --no-blacklist-digest-algo (name or number)
>
> Repeating the blacklist-digest-algo option can be done to add more than
> one algorithm to the blacklist. no-blacklist-digest-algo can be used to
> remove something from the list. Whoever gets in last (add to the list
> or remove from the list) wins.
>
> A blacklisted digest will cause signature verification to fail with an
> appropriate error message along the lines of "digest algorithm is
> blacklisted" (internally, GPG_ERR_BLACKLISTED_DIGEST or the like).
>
> A key certification created with a blacklisted digest will not be part
> of the web of trust.
>
> A blacklisted digest will also not be usable when creating a
> signature/certification, with the same sort of error returned.
>
> This does not affect the use of the digest in things like --print-md.
>
> gpg --version will flag blacklisted algorithms by putting them in
> [brackets].

This is a good summary, and sounds like a very useful feature proposal.

While we're defining this, do we want to also define
--blacklist-cipher-algo ? Semantically, i imagine that adding a cipher
to the blacklist would result in the following:

* nothing would ever be encrypted over the blacklisted cipher
* when decrypting data encrypted by a blacklisted cipher, gpg would
emit a warning.

If blacklist-cipher-algo is at all controversial, i'm fine with tabling
the discussion on it. I don't want it to divert attention from the
blacklist-digest-algo proposal, which seems a higher priority to me.

--dkg
Attachments: signature.asc (0.87 KB)


dshaw at jabberwocky

May 7, 2009, 10:25 AM

Post #2 of 5 (642 views)
Permalink
Re: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] [In reply to]

On May 7, 2009, at 12:11 PM, Daniel Kahn Gillmor wrote:

> While we're defining this, do we want to also define
> --blacklist-cipher-algo ? Semantically, i imagine that adding a
> cipher
> to the blacklist would result in the following:
>
> * nothing would ever be encrypted over the blacklisted cipher
> * when decrypting data encrypted by a blacklisted cipher, gpg would
> emit a warning.

We effectively have this now. If you take the cipher out of both your
on-key preferences and your personal-cipher-preferences, then other
people will not use it when encrypting to you, and you will not use it
when encrypting to other people. GPG will even print a warning if
someone uses it to encrypt to you ("WARNING: cipher algorithm such-and-
such not found in recipient preferences").

The only difference I see between this and a possible blacklist-cipher-
algo is that presumably you could blacklist 3DES, which you can't
remove from preferences.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


wk at gnupg

May 7, 2009, 10:31 AM

Post #3 of 5 (641 views)
Permalink
Re: --blacklist-digest-algo plans [In reply to]

On Thu, 7 May 2009 18:11, dkg [at] fifthhorseman said:

> While we're defining this, do we want to also define
> --blacklist-cipher-algo ? Semantically, i imagine that adding a cipher
> to the blacklist would result in the following:
>
> * nothing would ever be encrypted over the blacklisted cipher

That can be done with --disable-cipher-algo.

> * when decrypting data encrypted by a blacklisted cipher, gpg would
> emit a warning.

That might make sense. However, I don't see a use case.



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


jmoore3rd at bellsouth

May 7, 2009, 11:10 AM

Post #4 of 5 (643 views)
Permalink
Re: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] [In reply to]

David Shaw wrote:

> We effectively have this now. If you take the cipher out of both your
> on-key preferences and your personal-cipher-preferences, then other
> people will not use it when encrypting to you, and you will not use it
> when encrypting to other people. GPG will even print a warning if
> someone uses it to encrypt to you ("WARNING: cipher algorithm
> such-and-such not found in recipient preferences").

Err..... This presupposes that _all_ Correspondents re-Import/Refresh
One's Key with the "re-preferenced" Copy. Good Luck with that.

JOHN :-\
Timestamp: Thursday 07 May 2009, 14:09 --400 (Eastern Daylight Time)
Attachments: signature.asc (0.64 KB)


dshaw at jabberwocky

May 7, 2009, 12:28 PM

Post #5 of 5 (642 views)
Permalink
Re: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] [In reply to]

On May 7, 2009, at 2:10 PM, John W. Moore III wrote:

> David Shaw wrote:
>
>> We effectively have this now. If you take the cipher out of both
>> your
>> on-key preferences and your personal-cipher-preferences, then other
>> people will not use it when encrypting to you, and you will not use
>> it
>> when encrypting to other people. GPG will even print a warning if
>> someone uses it to encrypt to you ("WARNING: cipher algorithm
>> such-and-such not found in recipient preferences").
>
> Err..... This presupposes that _all_ Correspondents re-Import/Refresh
> One's Key with the "re-preferenced" Copy. Good Luck with that.

No, it does not change the situation at all.

In the "preferences" case, you won't generate a message with the
cipher in question. If you get a message with the cipher in question,
you will decrypt it but will display a warning.

In the "blacklist" case, you still won't generate a message with the
cipher in question. And if you get a message with the cipher in
question, you will still decrypt it, and will still display a warning.

The only difference between the two is that in the "preferences" case,
you at least told people not to use the cipher. Sure, they may not
have gotten the update, or may choose to ignore you, but even if they
do, the effect is the same on your side.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

GnuPG devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.