Preferences...
Hello ! To set the preferences, this can help: ?? ? Cipher-Algos:? Digest-Algos:? Compress-Algos: ? ?? ? ? ? Z0 Uncompressed ? ? S1 IDEA ? H1 MD5 ? Z1 ZIP ? ? S2 3DES ? H2 SHA1 ? Z2 ZLIB ? ? S3 CAST5? H3 RIPEMD160? Z3 BZIP2? ? S4 BLOWFISH ? ? ? ? ? ? ? ? ? ? ? ? S7 AES ? ? ? ? S8 AES192 ? H8 SHA256 ? ? ? S9 AES256 ? H9 SHA384 ? ? ? S10 TWOFISH ? H10 SHA512 ? ? ? S11 CAMELLIA128 ? H11 SHA224 ? ? ? S12 CAMELLIA192 ? ? ? ? S13 CAMELLIA256 ? ? ? ?? Those are my settings in GPG.CONF: default-preference-list S7 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z3 Z2 Z0 personal-cipher-preferences S7 S1 S10 S3 S4 S2 S9 S8 personal-digest-preferences H3 H8 H9 H10 H11 H2 H1 personal-compress-preferences Z1 Z3 Z2 Z0 -- Laurent Jumet KeyID: 0xCFAF704C ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert J. Hansen escribió: > David Shaw wrote: >> If someone wants to know how to set their preference list, they're not >> trying for new and fun ways to violate the spec. Well, since I made the question, I must agree with that point of view, since my concern was -being the receiving end- how to modify my preferences without making my key unusable or at least, less-usable. However, it is true I should not give for granted I will always receive messages using my preferences (and that is the reason why I finally added the IDEA library to my GPG... just in case... but I don't intend to use it). I almost forgot the cipher-algo command, since when I saw it is a very good way to produce a message the recipient can't decrypt... but well, without changing anything, there is always the option somebody can send me a message using whirlpool... I am trying to say, while the cipher-algo thing was not what I was asking for, it is not a bad thing to remember people, from time to time, the sender can manage to send messages useless for the receiver... > No, but they may be operating on the assumption their preference list > matters. (Which it very often doesn't; encrypting-to-self and another > recipient means there's a 50/50 chance their preference list will be > treated as a cap set. It would appear this ought to be made clear in > the docs.) What do you mean? I didn't understand the "cap set" concept, or at least, the meaning of these words (I think probably is due my lack of vocabulary...). Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJI1ywUAAoJEMV4f6PvczxAxjcIAIp91bEO0/EUgJ7HObr8tFwa AjYX2FatS2iQSVEMZ57raMaMlfQE1C9f/Mtr1sIvsrY3wJQvlxVXWAiAZdFIx261 fYQ2bXeYR55j54VC975O01CUg5g9jCFAVZJsOiHb68J4ZSuwhXt3QkdX+HuB0GmD 4WnnSnxJRUGfo5mOWAVhEDCKK6Y3/JWqMT0xsx+hQl72+Faf82h/Jya0JwtYuDiB C1Tht16KV6SgTSA7uBWKcNxHeW4qg7oVt/ewNMf4HzCeNnwEprbG1OWn1pb9NtUl V0Qt/u8S1pwZ1g7winaJZyk4HDMyAgDYyClZvvbVxmo3Os+1ArO0vsccYczBPTA= =IeBC -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Sep 21, 2008, at 11:57 PM, Robert J. Hansen wrote: David Shaw wrote: If someone wants to know how to set their preference list, they're not trying for new and fun ways to violate the spec. No, but they may be operating on the assumption their preference list matters. (Which it very often doesn't; encrypting-to-self and another recipient means there's a 50/50 chance their preference list will be treated as a cap set. It would appear this ought to be made clear in the docs.) I'd welcome docs that make it clear, but I question how easily it could be made "clear" in something pithy enough for a man page. If you make it simple enough to fit in the man page, you will get scolded for not covering some obscure case with v2 keys or something. If you make it complete, it's too big for an already large man page. I'd be content with something that says "List algorithms in the order in which you'd like to see them used. If you don't include 3DES, GPG will add it automatically at the end. Note that there are many factors that go into choosing an algorithm, and so GPG may or may not follow your chosen order for a given message. However, it will only ever choose an algorithm that is on the list of every recipient key. See also the INTEROPERABILITY section." GnuPG's preference lists are arcane and counterintuitive, and the source of a great deal of frustration. If they are so horrible, suggest a different way to handle them. Better to fix it in code rather than document something you feel is confusing. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
David Shaw wrote: > If someone wants to know how to set their preference list, they're not > trying for new and fun ways to violate the spec. No, but they may be operating on the assumption their preference list matters. (Which it very often doesn't; encrypting-to-self and another recipient means there's a 50/50 chance their preference list will be treated as a cap set. It would appear this ought to be made clear in the docs.) GnuPG's preference lists are arcane and counterintuitive, and the source of a great deal of frustration. If it would help to get some documentation written outlining precisely how it works and why, I would be happy to stop the bikeshedding and actually write it up. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Sep 21, 2008, at 10:30 PM, Kevin Hilton wrote: If you never want to see that algorithm used ever, leave it off the list completely. Not to beat a dead horse, but this statement isn't exactly true. The sender can force the use of a particular algorithm that is not on the list. I take objection to the use of the work "never". Oh, for crying out loud. The sender can do whatever the sender likes. That's what is so nice about being the sender. The sender can send unencrypted, but we don't mention that option. The sender could also choose to encapsulate their message in a text-to-speech MP3, but we don't mention that option either. Heck, there could be some bug in the sender's program that causes it to use the wrong algorithm, and again we don't mention that. I'm not going to prefix every single statement I make with an "Except in the case where the sender is intentionally violating the spec and is ignoring all the warning messages telling them to knock it off" We need to have some baseline of communication here, and avoid taking something that is really very simple and making it tragically complex. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Sep 21, 2008, at 10:52 PM, Kevin Hilton wrote: I'm not here to create an argument, however the option(s) cipher-algo digest-algo is specifically addressed within the documentation. I know. I wrote the part of the documentation that told people not to use them. GPG is a very flexible program, and as such, it gives you tens of ways to do things wrong. All of these method are off by default, and generally protected by strong warning messages that tell people when they're shooting themselves in the foot. People frequently write in to this list needing help on some simple question. My heart always sinks when I see some of the responses that take a simple question, and over-answer it in such a way as to guarantee that this poor person is going to be utterly baffled as to what is going on. If someone wants to know how to set their preference list, they're not trying for new and fun ways to violate the spec. Why even mention that it is possible to violate the spec? How does it help the questioner to know that "if you use the flag that you're not supposed to use, and ignore the warnings telling you to not use it... hey, you can get GPG to do something illegal"? To make this even more silly, you actually took the trouble to remove the part of my quote where I said WHY it was a bad idea. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Sep 21, 2008, at 7:34 PM, reynt0 wrote:
On Thu, 18 Sep 2008, David Shaw wrote:
. . .
1) Take the intersection of all recipients preference lists. This
rules out any algorithms that would be unusable by someone.
2) Elect a "decider". The decider is the one person whose ordered
list we will honor the rankings for. If the user has specified a
personal-*-prefs list, then the user is the decider. If the user
has not specified a list, then the last recipient key is used.
3) Walk the decider preference list from highest ranked to lowest
ranked - as soon as we hit an algorithm that is part of the
intersection from step #1, stop.
. . .
I'm a little confused, maybe because I'm not sure who all
"user" might refer to, or maybe :^) because my mind wants
to understand the system according to what my mind wants to
think would make sense to it. I have thought the process was:
("S" is sender; "R1", "R2", are receiver(s); "M" is message)
S has basic ordered acceptance list as Ps; as does each R as
Pr1, Pr2, and so on. S maybe has personal-*-prefs list as
Pps; each R maybe does, Ppr1, Ppr2, etc. The cipher used
for M is chosen by: 1st find simple intersection of the
ciphers listed in all the various P, this gives an unordered
set. 2nd, from the ciphers in that intersection set, choose
whichever ranks highest in Pps, if there is a Pps; otherwise
choose whichever shows up first in Ps; and in any case
ignoring all the Ppr1, Ppr2, etc and any ordering in the
Pr1, Pr2, etc.
Is this wrong?
Partially. You need to remember that the "sender" preferences are not
relevant here. OpenPGP has no concept of a sender. All it knows are
keys, and there is no particular requirement for a secret key to be
involved when sending a message. For example, who is the sender here?
gpg -r receiver1 -r receiver2 --encrypt my-file.txt
Using your nomenclature, here's the algorithm:
1) Take the intersection of the various PrXes. This gives an
unordered set.
2) If there is a Pps, choose the highest ranked entry in Pps that also
exists in the intersection
3) If there is no Pps, choose the highest ranked entry in Pr1 that
also exists in the intersection
Note that Ps, and any PprXes are irrelevant and in fact are unknown or
unknowable at the time of encryption.
David
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
I'm not here to create an argument, however the option(s) cipher-algo digest-algo is specifically addressed within the documentation. All the scenarios you are speaking about are extremely unrealistic, not documented in the documentation, and would take extreme measures to fulfill. I except your statement that we need a basic level of communication, however I think this basic level begins by discussing the possible switches which are discussed and documented specifically within the documentation. I am very much a novice in answering question on this mailing list, however I think your rant was unjustified and inappropriate. I'm not making any claims or false statements or presumptions other than those specifically discussed within the documentation. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
> If you never want to see that algorithm used ever, leave it > off the list completely. Not to beat a dead horse, but this statement isn't exactly true. The sender can force the use of a particular algorithm that is not on the list. I take objection to the use of the work "never". -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Sep 21, 2008, at 8:27 PM, Faramir wrote: David Shaw escribió: ... This is not true. GPG will never use a cipher that the recipient does not prefer. It may not use the recipient's #1 choice, but it will always use something from the recipient's list. By the way... if I use setpref to set my encryption algorithms to AES256 and AES128, does it mean people won't be able to use, let's say, 3DES to send encrypted messages to, even if they are incapable of using AES? I mean... if I forget to add some algo, would I be making my key less compatible with other OpenPGP software? No. Every preference list has 3DES in it. If you don't include it yourself, GPG adds it automatically to the end. If you set your preferred algorithms to AES256 and AES128, you're really setting it to AES256, AES128, and 3DES. I ask this question because, while maybe I would rather receive messages with some algorithms, that doesn't mean I don't want to use other algorithms if the preferred ones are not available... I figure the answer is "no, the sender still can use the algo's you forgot to add to your preferences list", but I want to be sure before doing any change... No, that is not the case. The sender cannot use any algorithm that you don't include in your preference list. To do so would violate OpenPGP, and cause major interoperability problems as the sender doesn't know if you even have the algorithm in question. The whole point of a preference list is that you list the algorithms in the order in which you prefer them. If you prefer some algorithms more, put them earlier. If you prefer some algorithms less, put them later. If you never want to see that algorithm used ever, leave it off the list completely. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
> By the way... if I use setpref to set my encryption algorithms to > AES256 and AES128, does it mean people won't be able to use, let's say, > 3DES to send encrypted messages to, even if they are incapable of using > AES? I mean... if I forget to add some algo, would I be making my key > less compatible with other OpenPGP software? The prefs associated with your key, is advertising to the sender what you would prefer. However the capabilities to decode an encrypted version is really determined by your gpg version and what ciphers it was associated with. Unless you force an algorithm -- with the cipher-algo preference, if your personal-preference list and the preferences associated with the public key (showpref or pref) have no matches in common (this is not a union of the sets), then 3DES is chosen by default. I believe all gnupg version since inception have had the capablities to decode 3DES encrypted messages as dictated by the OpenPGP RFC specifications. (I could be wrong on this very last statement). The use of personal-cipher-preferences rather than cipher-algo is preferred, since it prevents the problem of sending an encrypted communication that the recipient can not decode. If there is a null union of the personal-cipher-preferences and the key preferences, then 3DES is chosen. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Shaw escribió: ... > This is not true. GPG will never use a cipher that the recipient does > not prefer. It may not use the recipient's #1 choice, but it will > always use something from the recipient's list. By the way... if I use setpref to set my encryption algorithms to AES256 and AES128, does it mean people won't be able to use, let's say, 3DES to send encrypted messages to, even if they are incapable of using AES? I mean... if I forget to add some algo, would I be making my key less compatible with other OpenPGP software? I ask this question because, while maybe I would rather receive messages with some algorithms, that doesn't mean I don't want to use other algorithms if the preferred ones are not available... I figure the answer is "no, the sender still can use the algo's you forgot to add to your preferences list", but I want to be sure before doing any change... Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJI1uZYAAoJEMV4f6PvczxAQMMH/jvex8uHcRwPEdtA8OA6w+dP pjT3lbr/1l72LnnSOdT/WluHlNW1RI4Jl7eMXs1XWlwUrSLsq2Ma4hrU6MtZ+6NZ //8qoPkCAWvtsLcosS9jVU8J4/cajubvKgTjmT+X/+Kq/hTuMxiP+VVs17i0jDo6 iwhBMMyxMDrZPPf+oLaUx9PouY+i3xFIetjNSIytMb4FkhbSFlaxHNxa2f594Lqg gs2fb56gC6vshVcjasX/CidiygIsjhCXxLrwf70TTiN1qh+1jnrE9OiZMklKQacK b35K80Gq5q+ohPiIXKH6j1kA210GSngZev3nYAvDdTQIv3H/pCC7eZm+b9+G6Cc= =cv62 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
On Thu, 18 Sep 2008, David Shaw wrote:
. . .
1) Take the intersection of all recipients preference lists. This rules out
any algorithms that would be unusable by someone.
2) Elect a "decider". The decider is the one person whose ordered list we
will honor the rankings for. If the user has specified a personal-*-prefs
list, then the user is the decider. If the user has not specified a list,
then the last recipient key is used.
3) Walk the decider preference list from highest ranked to lowest ranked - as
soon as we hit an algorithm that is part of the intersection from step #1,
stop.
. . .
I'm a little confused, maybe because I'm not sure who all
"user" might refer to, or maybe :^) because my mind wants
to understand the system according to what my mind wants to
think would make sense to it. I have thought the process was:
("S" is sender; "R1", "R2", are receiver(s); "M" is message)
S has basic ordered acceptance list as Ps; as does each R as
Pr1, Pr2, and so on. S maybe has personal-*-prefs list as
Pps; each R maybe does, Ppr1, Ppr2, etc. The cipher used
for M is chosen by: 1st find simple intersection of the
ciphers listed in all the various P, this gives an unordered
set. 2nd, from the ciphers in that intersection set, choose
whichever ranks highest in Pps, if there is a Pps; otherwise
choose whichever shows up first in Ps; and in any case
ignoring all the Ppr1, Ppr2, etc and any ordering in the
Pr1, Pr2, etc.
Is this wrong?
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: header field causing problem
Thanks. I'll let the sender know. By the way, he says it was using Thunberbird with Enigmail to create the message. --- On Sat, 9/20/08, David Shaw <[EMAIL PROTECTED]> wrote: > From: David Shaw <[EMAIL PROTECTED]> > Subject: Re: header field causing problem > To: gnupg-users@gnupg.org > Date: Saturday, September 20, 2008, 6:56 PM > On Sat, Sep 20, 2008 at 02:24:01PM -0700, [EMAIL PROTECTED] > wrote: > > I got a message that gpg failed to decrypt. It looked > something like this: > > > > -BEGIN PGP MESSAGE- > > Charset: ISO-8859-1 > > > > Version: GnuPG v1.4.9 (MingW32) > > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > > > hQQOAx8Jy... > > -END PGP MESSAGE- > > It looks like the message was slightly corrupt. > Specifically, there > is a blank line after the "Charset" header and > before the "Version" > header. That's an invalid file - there is supposed to > be only one > blank line, and it comes right before the base64 data. > > I'm not sure what generated that message. I know it > claims to be GPG > 1.4.9, but GPG doesn't use the Charset header, so at > least that line > must have come from elsewhere. > > David > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
