On 21-06-2012 7:47, Robert J. Hansen wrote:
> No, because this is the sort of thing that usually goes in a gpg.conf
> file. I can't think of a use case for default-preference-list on the
> command line -- not saying none exist, mind you, but only that I can't
> think of one.
I have met one in pr
when running the command: gpg --list-packets
there is an outputted line that reads: "SHA1 protection"
I did some looking online and saw that this line stays even when people change
their hash algorithm to something else (like SHA2).
If the "SHA1 protection" is not indicating the use of SHA1
On 21/06/12 15:00, Sam Smith wrote:
> when running the command: gpg --list-packets
>
> there is an outputted line that reads: "SHA1 protection"
First of all, it seems you understand it, but let me emphasize this: the
algorithms you get when using the inspection method vedaal showed you, are /no
On Jun 21, 2012, at 9:00 AM, Sam Smith wrote:
> when running the command: gpg --list-packets
>
> there is an outputted line that reads: "SHA1 protection"
>
> I did some looking online and saw that this line stays even when people
> change their hash algorithm to something else (like SHA2).
>
On 06/21/2012 09:57 AM, Peter Lebbing wrote:
> There is no cipher
> or hashing involved in creating a key...
This may or may not be true, depending on what method of random number
generation is being used. ANSI X9.17, Yarrow and Fortuna are three
examples of pseudorandom number generators that ar
Thanks for this detailed explanation. I really appreciate it.
I've read of theoretical attacks against SHA1. whenever I hear of such things I
start to be leery when using such Hash. Seeing the advanced attack capabilities
demonstrated by Flame/Stuxnet leads me to believe theoretical is only
te
On 06/21/2012 12:52 AM, Robert J. Hansen wrote:
> Please don't do this. It's error-prone. Those are machine-readable
> numbers, not human-readable ones. Use the human-readable ones: for
> instance,
>
> default-preference-list TWOFISH 3DES SHA256 SHA224 RIPEMD160
completely agreed.
> Also, def
On Jun 21, 2012, at 12:39 PM, Daniel Kahn Gillmor wrote:
> On 06/21/2012 12:52 AM, Robert J. Hansen wrote:
>> Please don't do this. It's error-prone. Those are machine-readable
>> numbers, not human-readable ones. Use the human-readable ones: for
>> instance,
>>
>> default-preference-list TWOF
Werner Koch wk at gnupg.org wrote on
Wed Jun 20 10:29:28 CEST 2012 :
>The next version of Libgcrypt will support IDEA and thus GnuPG 2.1
>will be able to decrypt old (i.e. PGP 2) files, directly.
Will GnuPG 2.x then allow importation of v3 keys?
(main reason I still prefer 1.4.x over 2.x)
Th
vedaal at nym.hush.com vedaal at nym.hush.com wrote on
Thu Jun 21 19:05:06 CEST 2012 :
>Will GnuPG 2.x then allow importation of v3 keys?
>(main reason I still prefer 1.4.x over 2.x)
Sorry,
my mistake, gnupg 2.x does import v3 keys,
haven't looked at this aspect for a while, as I couldn't use m
On 6/21/2012 12:39 PM, Daniel Kahn Gillmor wrote:
> i don't think this is the case.
You and David are completely right, and I have no idea what I was
thinking. Thank you both for the correction!
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http:/
On 06/21/2012 01:21 PM, ved...@nym.hush.com wrote:
> vedaal at nym.hush.com vedaal at nym.hush.com wrote on
> Thu Jun 21 19:05:06 CEST 2012 :
>
>> Will GnuPG 2.x then allow importation of v3 keys?
>> (main reason I still prefer 1.4.x over 2.x)
>
> Sorry,
> my mistake, gnupg 2.x does import v3 ke
On 06/21/2012 04:38 PM, Daniel Kahn Gillmor wrote:
> unfortunately, this is indeed the case. v3 keys have a serious
> vulnerability in that their fingerprint mechanism is trivially gamable,
> so long keyid collisions are easy.
It's quite a bit worse than that, really. If I understand things
corr
13 matches
Mail list logo
