Sorry, I know this is only somewhat on topic: if someone can suggest
an appropriate mailing-list or news group, that'd be great.
I want to use rngd to increase my entropy pool for use with GnuPG, but
I don't have a hardware random device. I've seen a lot of references
to using /dev/urandom as the
On Sep 22, 2009, at 6:54 PM, Daniel Kahn Gillmor wrote:
Can you give me an example of a script
that has this behavior "baked in" to the point where adopting a better
heuristic would break it?
It doesn't work that way. The default is "the first valid key". It's
been that way in the PGP worl
On 09/22/2009 06:30 PM, David Shaw wrote:
> I think the current behavior is the right one. Otherwise we break
> however many baked-in uses out there (scripts, etc), to say nothing of
> having to explain to people why a particular key was chosen. "We pick
> the first valid key" cannot be misunders
On Sep 22, 2009, at 4:40 PM, Daniel Kahn Gillmor wrote:
On 09/22/2009 04:09 PM, John W. Moore III wrote:
John Clizbe wrote:
IIRC, it's the first usable key with a matching User ID. Period.
First one it
can use.
thanks for catching that, John. It appears that if the first key
with a
mat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi List readers,
thanks to David Shaw for the nice URL:
http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html
This one I like very much; The pencil and paper approach.
>
> Also, here's the Stick Figure Guide to AES:
>
> http://www
On 09/22/2009 04:09 PM, John W. Moore III wrote:
> John Clizbe wrote:
>
>> IIRC, it's the first usable key with a matching User ID. Period. First one it
>> can use.
thanks for catching that, John. It appears that if the first key with a
matching User ID doesn't have full calculated validity, the
First of all, someone has factored a 512-bit RSA key (the one used to
protect a TI programmable calculator, it seems). It took 73 days on a
dual-core 1900Mhz Athlon64. It took just under 5 gigs of storage and
around 2.5 gigs of RAM. In other words: not much at all. It's not
some big dis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Daniel Kahn Gillmor wrote:
> On 09/22/2009 04:57 PM, John W. Moore III wrote:
>> Like GPG it utilizes the 1st encountered Key that matches the Send To:
>> address & is valid.
>
> this is not what gpg does. gpg simply chooses the first key with a
>
On 09/22/2009 04:57 PM, John W. Moore III wrote:
> Like GPG it utilizes the 1st encountered Key that matches the Send To:
> address & is valid.
this is not what gpg does. gpg simply chooses the first key with a
matching user ID, whether or irrespective of the calculated validity of
the User ID in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
David Shaw wrote:
> [1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the
> same way any longer. I don't have my copy of PGP command line online at
> the moment, so I can't check what it does, but I'd be surprised if it
> didn't ei
On Sep 22, 2009, at 1:11 PM, Daniel Kahn Gillmor wrote:
when encrypting messages to a user ID with multiple matching keys with
full calculated validity, gpg seems to just choose the "first"
matching
key, for some definition of "first" -- i think it's decided by
chronological age of first impo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
John Clizbe wrote:
> IIRC, it's the first usable key with a matching User ID. Period. First one it
> can use.
My usual 'solution' for this is to 'Disable' the non-preferred or unused
Key until such time as it is Revoked or I have been otherwise inf
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
David Shaw wrote:
> There are occasional debates on who has the better PRNG. The debates
> usually end with no changes on either side :)
>
> That isn't to say there aren't differences between systems - the FreeBSD
> PRNG (which seems to have bee
Daniel Kahn Gillmor wrote:
> when encrypting messages to a user ID with multiple matching keys with
> full calculated validity, gpg seems to just choose the "first" matching
> key, for some definition of "first" -- i think it's decided by
> chronological age of first import into the local keyring.
when encrypting messages to a user ID with multiple matching keys with
full calculated validity, gpg seems to just choose the "first" matching
key, for some definition of "first" -- i think it's decided by
chronological age of first import into the local keyring.
This does not seem to be the best
On Tue, 22 Sep 2009 16:26, bmea...@ieee.org said:
> Just a quick question on the --status-fd output from a --verify
> operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could
> VALIDSIG or GOODSIG also show up? In other words, are these just for
It depends. EXPKEYSIG for example may come in
On Tue, Sep 22, 2009 at 11:19 AM, Werner Koch wrote:
> On Tue, 22 Sep 2009 16:26, bmea...@ieee.org said:
>> Just a quick question on the --status-fd output from a --verify
>> operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could
>> VALIDSIG or GOODSIG also show up? In other words, are the
Just a quick question on the --status-fd output from a --verify
operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could
VALIDSIG or GOODSIG also show up? In other words, are these just for
more information on why a signature failed, or can they qualify the
"GOOD" and "VALID" outputs?
Thanks
On Mon, 21 Sep 2009 22:36, tschai...@gmail.com said:
> 1. I'm working under the assumption that libgcrypt is a library that
> encapsulates the cryptographic algorithms and that libgcrypt is used
> only by gpg 2.x or greater. gpg 1.4.x does not use libgcrypt and
> updates to libgcrypt are not nece
19 matches
Mail list logo
