Oh, sorry. I made a mistake in 'Key-Type:' line. Right one :
Key-Type: eddsa
On Sun, Feb 25, 2018 at 2:16 AM, Yan Fiz wrote:
> Hello,
>
> When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
> doesn't apply 'encrypt' usage, expire date a
Hello,
When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
doesn't apply 'encrypt' usage, expire date and preferences. There is no
problem with RSA.
Regards.
(PS : My example key numbers were padded with X and Y)
$ gpg --batch --gen-key
Key-Type: ecdsa
Key-Cur
Hello,
When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
doesn't apply 'encrypt' usage, expire date and preferences. There is no
problem with RSA.
Regards.
(PS : My example key numbers were padded with X and Y)
$ gpg --batch --gen-key
Key-Type: ecdsa
Key-Cur
e sets cipher, hash and compression preferences for a key at
the time it is generated.
> --list-config
> --gpgconf-list
> --gpgconf-test
I haven't played with these so much, so I'll leave that for someone
else to answer.
> And how could i use this one ? :
> --personal-cipher
onfig
--gpgconf-list
--gpgconf-test
And how could i use this one ? :
--personal-cipher-preferences string
Is it possible to set preferences for the gnupg software globally ? Or maybe it
is possible just for a key especially ?
Preferences are recorded inside the keys ? Or in the gnupg software ?
Wh
On 08-04-2014 20:21, David Shaw wrote:
>> However, is there a way to remove it from the exported key only - to
>> keep the size of the exported key as small as possible? The export
>> options didn't do that as list-packets showed.
>
> Sure:
>
> --export-options export-clean
Thanks, that worke
On Apr 8, 2014, at 1:48 AM, Johan Wevers wrote:
> On 07-04-2014 15:16, David Shaw wrote:
>
>> When you change preferences you add another selfsig for your
>> user ID that contains the new preferences.
>
>> If you want to make the old preferences go away completely,
&
There is also the clean command which cleans up old self sigs (among other
things like unusable sigs, e.g. expired signatures).
On Tue, Apr 8, 2014 at 1:48 AM, Johan Wevers wrote:
> On 07-04-2014 15:16, David Shaw wrote:
>
> > When you change preferences you add another self
On 07-04-2014 15:16, David Shaw wrote:
> When you change preferences you add another selfsig for your
> user ID that contains the new preferences.
> If you want to make the old preferences go away completely,
> you can simply delete the old selfsig via delsig
Yers, that removes i
On Apr 7, 2014, at 2:06 AM, Johan Wevers wrote:
> Hallo,
>
> I changed the preferences for my gpg key to add the new Camelia ciphers
> and move IDEA more backward as I got problems with people with old pgp
> keys using old gnupg versions claiming they supported it but actually
&
Hallo,
I changed the preferences for my gpg key to add the new Camelia ciphers
and move IDEA more backward as I got problems with people with old pgp
keys using old gnupg versions claiming they supported it but actually
didn't support it.
However, when I export the key it now contains
Hello *,
I am interested in a way of obtaining key preferences information using GPGME
API. Being more specific, my target is represented by the last 4 lines of the
output of the command "gpg -edit-key showpref", the cipher, digest,
compression and features lines. Is it even p
On 25-Sep-08, at 01:32 , Robert J. Hansen wrote:
It should be noted the MitM requires more memory than exists in the
world, with more chosen plaintexts than have ever been encrypted
with DES.
If you're assuming the attacker has literally global computational
resources and can make you send
On 25-Sep-08, at 01:32 , Robert J. Hansen wrote:
It should be noted the MitM requires more memory than exists in the
world, with more chosen plaintexts than have ever been encrypted
with DES.
If you're assuming the attacker has literally global computational
resources and can make you send
Bill Royds wrote:
> three times, but it has an effective key length of 112 bits (even though
> there are 168 key bits) because of a meet in the middle attack against
> changed algorithms.
It should be noted the MitM requires more memory than exists in the
world, with more chosen plaintexts than ha
On 24-Sep-08, at 07:33 , Faramir wrote:
Robert J. Hansen escribió:
Faramir wrote:
Ok, let me say something on my behalf: in my experience, when
something does't work as well as expected, and people say "well...
lets do it 2 times, that should work", usually that leads to
something that works,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Shaw escribió:
> On Sep 24, 2008, at 7:33 AM, Faramir wrote:
>
>> Once I saw a shelf attached to the wall by no less than 24 screws.
>> When the shelf was removed, the wall looked like it had been attack with
>> a screw-shooting machine gun.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Robert J. Hansen escribió:
> Faramir wrote:
> I have a _big_ problem with people arguing that their personal
> prejudices are actually reasonable conclusions to draw. Like Mark Twain
That was never my intention, I always knew my prejudice was no
Kevin Hilton wrote:
> What's the motivation for abandoning the AES also-rans?
Insufficient love.
Nobody needs SERPENT, Twofish or Blowfish, so there's a strong
evolutionary pressure to either not include them or axe them from the
spec. (Tiger-192 fell out of the spec the same way.)
People in th
On Sep 24, 2008, at 8:47 AM, Kevin Hilton wrote:
Thanks for the quoted sections from Applied Cryptography. Just to
throw more fuel on the fire, however from the quoted material, it
would seem that Serpent and 3DES have a lot in common -- slowness, but
security. Again a lot of ciphers are alrea
On Sep 24, 2008, at 7:33 AM, Faramir wrote:
Once I saw a shelf attached to the wall by no less than 24 screws.
When the shelf was removed, the wall looked like it had been attack
with
a screw-shooting machine gun. Sure, the shelf was firmly attached to
the
wall, but it would have been bett
> Purely historical reasons. Also, the SERPENT design team, much like the
> Twofish design team, is strongly pushing abandoning the AES also-rans
> and using AES.
>
What's the motivation for abandoning the AES also-rans? I can see the
motivation for not including them in the OpenGPG specificati
Kevin Hilton wrote:
> would seem that Serpent and 3DES have a lot in common -- slowness, but
> security.
Arguably true.
> How a cipher like cast5, but not Serpent could be
> included, other than for historical reasons, is beyond me.
Purely historical reasons. Also, the SERPENT design team, much
Faramir wrote:
> So probably it is a mistake to try to explain in a logical way
> something that is, by definition, non based on logic.
I don't have any problem with people having their own personal likes and
dislikes. I like Blowfish; I use it, although I don't recommend it to
others.
I have a
Thanks for the quoted sections from Applied Cryptography. Just to
throw more fuel on the fire, however from the quoted material, it
would seem that Serpent and 3DES have a lot in common -- slowness, but
security. Again a lot of ciphers are already included in GnuPG, many
it seems for historical r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Robert J. Hansen escribió:
> Faramir wrote:
>> Ok, let me say something on my behalf: in my experience, when
>> something does't work as well as expected, and people say "well...
>> lets do it 2 times, that should work", usually that leads to
>> som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Robert J. Hansen escribió:
> Faramir wrote:
>> Maybe he said both things, my source was wikipedia, but they provided
>> a link to the interview where he said that:
>
> Add this to the list of things Wikipedia has screwed up.
No, it was me who s
John Clizbe wrote:
> And in /Applied Cryptography/, they write[3]:
D'OH! Up to late after plumbing emergency... That should read,
And in /Practical Cryptography/, they write[3]:
> [3] Ferguson, Niels & Schneier, Bruce. /Practical Cryptography/.
> John Wiley & Sons, 2003. [Pages 63-64]
> [4]
Faramir wrote:
> Robert J. Hansen escribió:
>> Faramir wrote:
>>> didn't include Blowfish because I was told it is not supported by PGP
>
>> PGP can read Blowfish traffic. It won't generate Blowfish traffic, but
>> that's a separate issue.
>
> Interesting... I will add it to my list... please
Faramir wrote:
> Ok, let me say something on my behalf: in my experience, when
> something does't work as well as expected, and people say "well...
> lets do it 2 times, that should work", usually that leads to
> something that works, but it is not as good as it could be...
False premise. DES wo
Faramir wrote:
> Maybe he said both things, my source was wikipedia, but they provided
> a link to the interview where he said that:
Add this to the list of things Wikipedia has screwed up.
Schneier has repeatedly advocated for AES. Go read his _Practical
Cryptography_ and see what he says abo
Kevin Hilton wrote:
> I've often wondered the consequences of such an action -- whether
> this makes the chance of a collision higher or equal in comparing the
> SHA512 modified hash product to the SHA256 hash product. Perhaps
> someone could elaborate on this.
Theoretically? None. Practically?
ant, and well-studied. I have a personal
> liking for it just for its simplicity.
And according to Wikipedia, the only known way to break the full 16
rounds implementation is brueforce... it seems the only one who
recommends to move is its author...
> The all time best advice re: prefe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Robert J. Hansen escribió:
> Faramir wrote:
>> I think I will add some more algos, to avoid using 3DES (while it
>> should be safe enough... I don't like the solution "lets do it 3 times")
> Not to ask a dunce question here, but why not?
I will
On Sep 23, 2008, at 11:32 PM, Kevin Hilton wrote:
Robert can probably give a better explanation that I, however with
3072 DSA signing keys, the SHA512 and SHA256 algorithms "functionally"
produce the same length hash since the lower 256 bits are dropped as
per the FIPS specification. I've often
On Sep 23, 2008, at 11:03 PM, Faramir wrote:
Well, I wrote what I intend to use as default preferences, but before
modifying anything I wanted to ask opinions...
For encryption: AES256 AES192 TWOFISH AES CAST5 3DES (didn't include
Blowfish because I was told it is not supported by PGP
On Sep 23, 2008, at 7:24 PM, Faramir wrote:
I think I will add some more algos, to avoid using 3DES (while it
should be safe enough... I don't like the solution "lets do it 3
times")
3DES is arguably the "best" (defined as "has been studied the most and
hasn't been broken") algorithm in O
Robert can probably give a better explanation that I, however with
3072 DSA signing keys, the SHA512 and SHA256 algorithms "functionally"
produce the same length hash since the lower 256 bits are dropped as
per the FIPS specification. I've often wondered the consequences of
such an action -- wheth
ndon Twofish and move to AES.
A lot of people are still quite fond of Blowfish. It's a beautifully
simple algorithm, quite elegant, and well-studied. I have a personal
liking for it just for its simplicity.
The all time best advice re: preferences is "unless you know what you're
do
lack of vocabulary ;-)
Well, I wrote what I intend to use as default preferences, but before
modifying anything I wanted to ask opinions...
For encryption: AES256 AES192 TWOFISH AES CAST5 3DES (didn't include
Blowfish because I was told it is not supported by PGP, and also its
author says pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Shaw escribió:
>> Now that the algorithm has been changed for picking preferred
>> algorithms, can someone please explain how the new algorithm works if
I was forgetting to ask: does this change mean we will see a GPG
1.4.9b (or 1.4.10) ver
On Sep 23, 2008, at 10:37 PM, Robert J. Hansen wrote:
Kevin Hilton wrote:
Now that the algorithm has been changed for picking preferred
algorithms, can someone please explain how the new algorithm works if
the personal preferences are omitted?
Borda counting.
http://en.wikipedia.org/wiki
Faramir wrote:
> I think I will add some more algos, to avoid using 3DES (while it
> should be safe enough... I don't like the solution "lets do it 3 times")
Um.
Not to ask a dunce question here, but why not?
It's perfectly safe. In fact, 3DES is probably the most trustworthy
algorithm on thi
Kevin Hilton wrote:
> Now that the algorithm has been changed for picking preferred
> algorithms, can someone please explain how the new algorithm works if
> the personal preferences are omitted?
Borda counting.
http://en.wikipedia.org/wiki/Borda_count
Once you've gone off and r
On Sep 23, 2008, at 6:38 PM, Kevin Hilton wrote:
Now that the algorithm has been changed for picking preferred
algorithms, can someone please explain how the new algorithm works if
the personal preferences are omitted? Someone had previously posted a
very informative example with three users
Faramir wrote:
>I had to use a dictionary for the first message, and what I found
> didn't make any sense... according to my dictionary, a "cap" is
> something closely related to a hat,
A 'cap' may also (and more likely) refer to a limit usually an upper bound
> so I though maybe the "cap se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Robert J. Hansen escribió:
> Faramir wrote:
>> 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...).
>
> Imagine a group of people are going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kevin Hilton escribió:
> Now that the algorithm has been changed for picking preferred
> algorithms, can someone please explain how the new algorithm works if
> the personal preferences are omitted? Someone had previously posted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
David Shaw wrote:
> Huh? You don't have preferences now
Yes, I have done the 'setpref' thingy on My Key. I suspect that from
this thread countless Others have or are doing so. My Point is that
until My Key _with_ adverti
Now that the algorithm has been changed for picking preferred
algorithms, can someone please explain how the new algorithm works if
the personal preferences are omitted? Someone had previously posted a
very informative example with three users with their key preferences,
and showed how the
y 99242560) and you. My preferences are (and I
really need to update these) AES, TWOFISH, CAST5, BLOWFISH, 3DES. The
only algorithms that are even possible here (because we both have
them) are AES, CAST5, and 3DES. AES is clearly the most popular of
these three, so AES will be chosen. B
ncrypted
> using 3DES. ;)
But... I didn't modify my key preferences, and showpref shows:
Cifrado: AES256, AES192, AES, CAST5, 3DES
Resumen: SHA1, SHA256, RIPEMD160
Compresión: ZLIB, BZIP2, ZIP, Sin comprimir
Características: MDC, Sevidor de claves no-modificar
So I figure the default most
hing changes until a Key is 'refreshed' on individual
> Keyrings?
>
> The fact of the matter is that unless someone has a current Key with
> preferences then the existing Key will be the one that is used.
Huh? You don't have preferences now, but will add some for this
fea
John W. Moore III wrote:
> So, nothing changes until a Key is 'refreshed' on individual
> Keyrings?
Nope! There's no need to update your keyrings. This affects GnuPG's
executable code only -- there are no changes needed to your gpg.conf,
nor any key refreshes that need to occur.
The fact of the matter is that unless someone has a current Key with
preferences then the existing Key will be the one that is used.
I've got a shilling that says 99% of My Messages will still be Encrypted
using 3DES. ;)
JOHN ;)
Timestamp: Tuesday 23 Sep 2008, 17:16 --400 (Eastern Day
or may
> > not follow your exact 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.
>
> Sounds good to me. It seems to cover what people mostly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Mark H. Wood wrote:
> Sounds good to me. It seems to cover what people mostly need to know,
> and is compact enough for a man page.
Color Me "behind-the-times" but I seriously thought the Man Page was
succinct and clear regarding this. :-\
JOHN
On Sun, 21 Sep 2008, Robert J. Hansen wrote:
. . .
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
David Shaw wrote:
> That's exactly it. Camellia is a very popular algorithm in Japan.
> Including it doesn't buy us much new from the cryptographic perspective
> as we already have strong 128-bit ciphers in OpenPGP, but it does buy us
> something
On Tue, Sep 23, 2008 at 09:44:53AM -0400, David Shaw wrote:
> On Sep 22, 2008, at 10:17 AM, Mark H. Wood wrote:
>
>> On Mon, Sep 22, 2008 at 12:09:00AM -0400, David Shaw wrote:
>>> I'd be content with something that says "List algorithms in the order in
>>> which you'd like to see them used.
>>
>>
On Sep 22, 2008, at 10:17 AM, Mark H. Wood wrote:
On Mon, Sep 22, 2008 at 12:09:00AM -0400, David Shaw wrote:
I'd be content with something that says "List algorithms in the
order in
which you'd like to see them used.
There's the problem right there. "Used" when? When sending?
apparently
Robert J. Hansen wrote:
> Remove the option.
Apologies for the multiple send. I had a network bounce (or three)
while sending this; apparently, Thunderbird wasn't able to register that
the message had gone through.
___
Gnupg-users mailing list
Gnupg-
On Sep 23, 2008, at 8:44 AM, Werner Koch wrote:
On Tue, 23 Sep 2008 14:00, [EMAIL PROTECTED] said:
proper code lines. While 'interoperability' testing has
not
occurred; I have been able to successfully utilize Camellia without
Again: Please do not use this cipher for anything other than
thing you feel is confusing.
> >
> > Remove the option.
> >
> > Seriously. I think key preferences ought to be considered analogous to
> > "--cipher-algo": you can tweak them if you want, but it's not
> > recommended and should be hidden from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Werner Koch wrote:
> I also wonder why so many people are interested in it.
Well Werner, because You have 'Groupies' that cleave to You like they
would to Phil Zimmerman if He were so Publicly available.
Folks are 'interested' because it is New &
On Tue, 23 Sep 2008 14:00, [EMAIL PROTECTED] said:
> proper code lines. While 'interoperability' testing has not
> occurred; I have been able to successfully utilize Camellia without
Again: Please do not use this cipher for anything other than pure
interop testing. The identifier assigned to C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Robert J. Hansen wrote:
> Remove the option.
>
> Seriously. I think key preferences ought to be considered analogous to
> "--cipher-algo": you can tweak them if you want, but it's not
> recommended and should be h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
David Shaw wrote:
> them... but there is no guarantee that those messages will be
> decryptable, ever. You've got a gun pointed at your foot. Be careful
> you don't pull the trigger.
Ah Jeez, David; You are too rough on the individual who incorpo
gt; Seriously. I think key preferences ought to be considered analogous to
> "--cipher-algo": you can tweak them if you want, but it's not
> recommended and should be hidden from the user by default. If a user
> uses the --expert flag while --edit-keying, then present it. Othe
On Mon, Sep 22, 2008 at 12:09:00AM -0400, David Shaw wrote:
> I'd be content with something that says "List algorithms in the order in
> which you'd like to see them used.
There's the problem right there. "Used" when? When sending?
apparently not. When others send to me? apparently so. Someho
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 messag
time spent in order to make the
gnupg project very successful. In order to provide effective
documentation, contributors must know all the nuances of the project
and have a very good working knowledge of the various options.
Its clear that the preferences among how the different ciphers or
hashes
time spent in order to make the
gnupg project very successful. In order to provide effective
documentation, contributors must know all the nuances of the project
and have a very good working knowledge of the various options.
Its clear that the preferences among how the different ciphers or
hashes
?
>>? S12 CAMELLIA192 ? ? ?
>>? S13 CAMELLIA256 ? ? ?
>>??
>But... is Camellia already implemented? :O
>I didn't know about that... or maybe, the S11 to S13 places are
> reserved for future use?
On Mon, Sep 22, 2008 at 02:37:17AM -0500, Robert J. Hansen wrote:
> Faramir wrote:
> >> 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
Robert J. Hansen wrote the following on 9/22/08 3:47 AM:
> David Shaw wrote:
>> 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.
>
> Remove the option.
>
> Seriously. I
On Sep 22, 2008, at 3:33 AM, Faramir wrote:
But... is Camellia already implemented? :O
I didn't know about that... or maybe, the S11 to S13 places are
reserved for future use?
They are reserved for experimentation in GPG. Don't use them.
They're for interoperability testing only.
Dav
On Sep 22, 2008, at 1:52 AM, Laurent Jumet wrote:
Hello !
To set the preferences, this can help:
??
? Cipher-Algos:? Digest-Algos:? Compress-Algos
Good morning GnuPG users!
the following mail hit my mailbox about fifty times now - I think it's
enough. :-)
I thougt, it is my client, fetching the same mail from the server, but
looking there, I found all the mails ther too. :-(
Anyone else have the same problem? If not, I will search for the
On Mon, 22 Sep 2008, Robert J. Hansen wrote:
David Shaw wrote:
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.
Remove the option.
.snip.
44 instances of t
David Shaw wrote:
> 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.
Remove the option.
Seriously. I think key preferences ought to be considered analogous to
"--cipher-algo": you c
Faramir wrote:
>> 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 c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Laurent Jumet escribió:
> Hello !
>
> To set the preferences, this can help:
>
>??
>? Cipher-Algos:? Digest-Algos:
Hello !
To set the preferences, this can help:
??
? Cipher-Algos:? Digest-Algos:? Compress-Algos: ?
??
? ? ? Z0 Uncompressed
h 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 ad
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 ofte
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
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 objec
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 p
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 fo
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 you
> 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
e 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",
ss 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 ha
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&
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 sp
> GnuPG in particular works like this:
>
> 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 sp
On Sep 18, 2008, at 6:30 PM, Robert J. Hansen wrote:
David Shaw wrote:
The preferences on the keys are used by people encrypting a message
*to* those keys. It indicates that algorithms the keyholders prefer.
If AES256 is listed first in personal-cipher-preferences, it doesn't
matt
David Shaw wrote:
> The preferences on the keys are used by people encrypting a message
> *to* those keys. It indicates that algorithms the keyholders prefer.
If AES256 is listed first in personal-cipher-preferences, it doesn't
matter if AES256 is listed first in the recipient's
s
> seems to rule the roost.
The preferences on the keys are used by people encrypting a message
*to* those keys. It indicates that algorithms the keyholders prefer.
The personal-*-prefs are used by the sender. It indicates which
algorithms within the above list the sender i
1 - 100 of 138 matches
Mail list logo
