On really last addition on this (promised :-) ):
I tried to mix up keys with new and old packet header types.
Is it desired that gnupg simply converts them back to old packet
headers (if possible) without any notice to the user?
What will keyservers do when someone uploads a key with e.g. old
pack
Hi list.
On Tue, Jan 27, 2009 at 10:44 PM, Peter Thomas wrote:
> On Tue, Jan 27, 2009 at 4:48 PM, David Shaw wrote:
>> The RFC is really a file format document more so than a "how to use trust"
>> document. Every now and then it is suggested that a trust documen
On Thu, Jan 29, 2009 at 10:19 PM, David Shaw wrote:
> build-packet.c:build_sig_subpkt()
> sign.c:make_keysig_packet()
> sign.c:update_keysig_packet()
Thanks :-)
I'll have a look at it and come back to you if I should have questions ;-)
Peter
___
Gnup
On Thu, Jan 29, 2009 at 7:35 PM, Faramir wrote:
> Yes, but you made me remember the time I was studying physics (before
> I bailed out from that).
Ah :-)
> By the way, why do you need so much entropy? To ensure the quality of
> CAcert certificates?
Uhm,... to speed up my monster-65563-or-even-m
On Thu, Jan 29, 2009 at 6:03 PM, Faramir wrote:
> Well, not if the sample emits beta particles, these are supposed to be
> easily blocked by some millimeters of skin, so as long as you don't
> touch them too much, they would be safe to use. But I suppose as beta
> radiation is composed of electro
On Wed, Jan 28, 2009 at 7:00 PM, Benjamin Donnachie
wrote:
> 2009/1/28 Peter Thomas :
> Please please please stop starting new threads!
Sorry Benjamin. I thought it was better to somehow group my questions
according to what they're about. An normal mail user clients should
provide thr
On Wed, Jan 28, 2009 at 9:31 PM, David Shaw wrote:
> On some platforms, a hardware RNG actually ends up feeding /dev/random.
> This is particularly nice as it means GPG (or any program that uses
> /dev/random) benefits without code modification.
But this has a disadvantage if that hardware RNG is
2009/1/28 Ingo Klöcker :
> See http://www.fourmilab.ch/hotbits/ for a random number generator using
> radioactive decay.
>
> Under http://von-und-fuer-lau.de/ct-randcam.html you can download a
> (mostly) non-deterministic random number generator using a webcam. The
> page is in German.
This sounds
On Wed, Jan 28, 2009 at 6:36 PM, Robert J. Hansen wrote:
> Imagine you have a Geiger counter and a radioactive sample. Over each
> time frame, the Geiger counter reports how many decays it measures.
> That number becomes your random value. So far, so random, right?
Using a radioactive sample for
On Wed, Jan 28, 2009 at 6:26 PM, Robert J. Hansen wrote:
> Anyone who uses the Mersenne Twister to generate cryptographic
> pseudorandom values is living in sin.
xD ... Well I've read that "without modification it is not usable for
cryptography" so I thought maybe there is a modified version which
One more thing
On Wed, Jan 28, 2009 at 5:10 PM, Werner Koch wrote:
>> It seems that it's quite easy to disable this limit in the gnupg
>> source, all I have to do is set max=something in keygen.c, correct?
> No, there is some limit in the RNG too.
I've grep'ed through the sources and there are ma
Hi David.
One more thing on this:
On Tue, Jan 27, 2009 at 5:18 AM, David Shaw wrote:
>> Would gnupg understand these subpackets in a 0x1F signature?
> Yes. It's a valid key as per the spec, even though no program actually
> generates such a key that I know of. Note that I can't make that same
Hello Werner.
On Wed, Jan 28, 2009 at 5:10 PM, Werner Koch wrote:
> Read the manual of libgcrypt 1.4.4 - it includes a description of the
> RNG. The code in 1.4 is basically the same.
That's what I was looking for :-)
These levels described on
http://www.gnupg.org/documentation/manuals/gcrypt/Q
Hi.
Now this is surely gnupg specific again ;-)
Ok let me see...
1) When creating keys or other data which needs random numbers, how is
this done in gnupg? I mean does it per default use /dev/random? Or
does it have its own means like a modified Mersenne Twister or
whatever?
I wonder because I'd
Hi.
I've just made some tests. And it showed that anybody can change the
paket header from old to new for any key (even without the secret
key).
Of course I've expected this, but is this the case for all signature
types, that gnupg doesn't include the paket header in the signing but
just the body?
For those who are interested, I've moved this thread to that location:
http://www.imc.org/ietf-openpgp/mail-archive/msg30794.html
Peter
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
On Tue, Jan 27, 2009 at 4:48 PM, David Shaw wrote:
> The RFC is really a file format document more so than a "how to use trust"
> document. Every now and then it is suggested that a trust document or
> something like an OpenPGP best practices document should be written, but
> nobody has taken up
Hello.
This time it's all about signature subpackets:
Sorry that this got longer, but I think these points are all somehow
connected. So feel free to split up as you like :-)
I know that these questions are more about OpenPGP itself than gnupg,
but perhaps you, David, can have a look at them here,
Hi again.
Ok this is a first bunch of questions on signatures (again both
specific for gnupg but perhaps also common for OpenPGP).
Would be glad if someone could help me with answering these (David?! xD).
1) For the 0x11 signature the RFC says "...has not done any
verification of the claim that .
On Mon, Jan 26, 2009 at 5:40 PM, David Shaw wrote:
> No, but you could patch it if you liked. Take a look at the
> write_header() and write_new_header() functions in build-packet.c
Although you've convinced me that using old packet types where
possible is preferable, I still tried to get this wor
On Tue, Jan 27, 2009 at 4:57 AM, David Shaw wrote:
> They should at least fail - a new style RFC-4880 (or 2440) packet (of any
> type) is unreadable by an old RFC-1991 program. It simply won't be
> meaningful. At to *how* it will fail, that depends on the program.
>
> The point of the Marker Pac
Hi David.
btw: Thanks for your excellent answers. Great to have one of the RFC
authors here :-)
On Mon, Jan 26, 2009 at 11:28 PM, David Shaw wrote:
> It's a "token", that can be given from one person to another. The
> token contains only what is stated inside the signature itself. Let's
> say
On Mon, Jan 26, 2009 at 11:31 PM, David Shaw wrote:
> No, they don't have a concept of a packet type above 15. There are
> only 4 type bits in the old-style packet header. :)
Yes, that was clear
> Old programs will basically blow up if they see something they don't
> understand. There is a spec
Hi again.
This is about signature types and how gnupg uses them.
I've looked through the signature types in chapter 5.2.1
1) The 0x02 standalone signature: What is its intended use (by the
standard) and is it ever used by gnupg?
I mean it's clear to me that it signs just it's own subpackets, but
On Mon, Jan 26, 2009 at 5:40 PM, David Shaw wrote:
>> Ah, thanks. So I'd should be 254 for better security of the private key,
>> right?
> Yes. See http://eprint.iacr.org/2002/076.pdf for the attack that
> prompted this extra layer of protection.
Ah,.. interesting,.. thanks for that pointer.
>>
Hi David.
On Mon, Jan 26, 2009 at 3:52 PM, David Shaw wrote:
>> I'm currently reading RFC4880 and I think I have many minor questions... is
>> the gnupg-users list the right place to ask? Or is there any better place?
> Look for the ietf-openpgp mailing list at
> http://www.ietf.org/html.charte
Hi folks.
I'm currently reading RFC4880 and I think I have many minor questions... is
the gnupg-users list the right place to ask? Or is there any better place?
Anyway,... I think I start right now and ask my first question,.. (think
it's easier to handle if I ask only one or two questions per mai
27 matches
Mail list logo
