Re: Multiple Subkey Pairs
I apologize for having triggered the emotionally agitated exchange in this thread culminating in someone bringing up the German-Jew trauma. I did not intend this and will try to make future points in a more moderate language. I acknowledge the outburst of true emotion by the person I responded to initially. Unfortunately my initial contribution was held for moderation and finally has been withheld for reasons unknown to me. All that was left is a belated, empty response under my name in the last digest. Since followers of this discussion cannot possibly understand the heated responses without the trigger, I'll try it again. Hopefully this will end the emotional part and will get the discussion back onto the appropriate technical track. This time I'll slightly redact my initial contribution so as to avoid it being held by a moderator. Here we go -Quote: So far there's no credible reporting that any government is doing mass surveillance of email content. Instead, mass surveillance focuses on metadata: who's talking to whom, when, with what for a subject line, routed through which mail servers, and so on. The YYY (-a famous three letter agency) e.g. denies to archive content of YYY citizens mails. It is thus perfectly reasonable to assume it does so with all other ones. They can easily do it, thus they do it. I am german, so I am free game for them anyways. Besides, you believe their denials - are you kidding? GnuPG does not and cannot protect against that. This is as regrettable as it is true. Worse still, it is much more cumbersome to protect your metadata than to protect content with e.g. GnuPG. You could achieve it easiest with Y(-We all would know how to do this). A public key infrastructure is difficult to reconcile with anonymity. If your concern is mass surveillance -- which is to say, metadata -- sorry again, if we are speaking about the YYY, only metadata if recipient and sender are YYY citizens and if we believe what the agency says. Regarding the the security of the content, I share the view that lighting a firework of a dynamic subkey structure is not going to help. IMHO one properly kept key is enough and its security should last for decades. After all the all or nothing principle is at the core of cryptography in many contexts. There is no such thing as attrition of security by heavy usage of a public RSA or ECC key. When it comes to system compromise leading to broken security. This is not kind of an aging process smoothly proceeding with time and eventually leading to death. They target you or they don't. cheers Michael Anders (a reference to my project page) *** End of quote. The reference to my crypto project homepage which also contains a political statement, might also have been the problem. Those who are interested and dont't feel offended by a positive reference to a controversial person can find it via my homepage www.fh-wedel.de/~an/ following the link to Academic Signature. Best regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Subkey Pairs
The YYY (-a famous three letter agency) e.g. denies to archive content of YYY citizens mails. It is thus perfectly reasonable to assume it does so with all other ones. This is not a reasonable inference. I deny being able to violate the Second Law of Thermodynamics. Is it perfectly reasonable to assume I can violate the First or the Third? No, clearly not: the inference is not logically sound. Neither is your original inference. Besides, you believe their denials - are you kidding? See my previous post. sorry again, if we are speaking about the YYY, only metadata if recipient and sender are YYY citizens and if we believe what the agency says. I cannot accept this assertion, as it is offered without either direct evidence or logically sound inferences. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On 03/15/2014 03:53 PM, Juha Heljoranta wrote: I am not able to get the gpg to verify a signature. Any advice how to fix this? Or could the key 9C973C92 be invalid/broken? $ mkdir -m 700 newgnupg $ echo foo zinc-0.2.0.jar $ wget http://repo1.maven.org/maven2/com/typesafe/zinc/zinc/0.2.0/zinc-0.2.0.jar.asc This is a signature ostensibly made by a 2048-bit DSA key, made over an SHA-1 digest. DSA keys larger than 1024-bits should generally make signatures over stronger digests than SHA-1. See section 4.2 of FIPS-186-4 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf for similar guidance. Perhaps the folks who publish zinc need to --enable-dsa2, or to remove any mistaken digest-algo sha1 from their signing routines? You could point them at this thread in the gnupg-users archives if you think it would be useful. That said gpg seems to still accept signatures made by even stronger RSA keys over SHA-1. And it even accepts (with a warning) signatures by stronger RSA keys over MD5, which is even weaker than SHA1. So gpg's behavior seems to be non-uniform here. That said, i'd love to be able to tell gpg to ignore or explicitly reject signatures made by strong keys with MD5 digests. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On Mar 15, 2014, at 3:53 PM, Juha Heljoranta juha.heljora...@iki.fi wrote: Hi, I am not able to get the gpg to verify a signature. Any advice how to fix this? Or could the key 9C973C92 be invalid/broken? The key may be fine, but the signature is invalid. DSA keys specify how many bits of hash are necessary to make a signature. This key says it needs a 256-bit hash: gpg: requesting key 9C973C92 from hkp server pgp.mit.edu gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: SKS 1.1.4 gpg: armor header: Comment: Hostname: pgp.mit.edu :public key packet: version 4, algo 17, created 1330048372, expires 0 pkey[0]: [2048 bits] pkey[1]: [256 bits] But the signature is strange. It claims to be SHA-1: :signature packet: algo 17, keyid 04918EA99C973C92 version 4, created 1352169028, md5len 0, sigclass 0x00 digest algo 2, begin of digest 6f 81 ^ But is way too large: hashed subpkt 2 len 4 (sig created 2012-11-06) subpkt 16 len 8 (issuer key ID 04918EA99C973C92) data: [255 bits] ^^^ Basically, the signature failed verification because it's mangled somehow. I'm not sure how they managed to create it, but it's broken. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: locale bug in 1.4
On Sun, Mar 16, 2014 at 9:28 PM, Hauke Laging mailinglis...@hauke-laging.de
wrote:
Hello,
I may have found a locale bug in 1.4.12. I am aware that this is not the
current version but I cannot easily install 1.4.16 now. 1.4.12 is the
version in Knoppix 7.2.
I have problems with non-ASCII characters when I use batch mode. The
funny part is that this problem does not appear when I generate a
mainkey (from a batch config file). It appears when I add UIDs later:
echo adduid$'\n'$name$'\n'${email}$'\n'${comment}$'\n'save$'\n' |
LC_ALL= LANGUAGE=en gpg --batch --passphrase foo \
--command-fd 0 --edit-key Hauke
Why are you setting LC_ALL= LANGUAGE=en? This would cause the switch to
iso-8859-1 (well, to the system-wide default charset, but that's most like
iso-8859-1).
The man page says about --display-charset:
If this option is not used, the default character set is determined
from the current locale.
What you would expect.
locale looks like this:
LANG=de_DE.UTF-8
LANGUAGE=de
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=de_DE.UTF-8
gpg --expert --gen-key
leads to a message:
You are using the `utf-8` character set.
The batch pipeline leads to:
You are using the `iso-8859-1` character set.
Which IMHO pretty well explains the umlaut problems. But it doesn't make
sense to me. Why does GnuPG guess it's not UTF-8 any more just because
of the pipeline? Adding --display-charset utf-8 solves the problem. It
does not occur with 2.0.22 (and some versions before).
BTW: Unfortunately I have no clue about internationalization. Is it
correct that LANG and all the LC_ variables have content of this kind
LANG=de_DE.UTF-8 but that LANGUAGE has neither the _ part nor a
character encoding?
Hauke
--
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
David Tomaschik
OpenPGP: 0x5DEA789B
http://systemoverlord.com
da...@systemoverlord.com
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On Mar 17, 2014, at 10:39 AM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 03/15/2014 03:53 PM, Juha Heljoranta wrote: I am not able to get the gpg to verify a signature. Any advice how to fix this? Or could the key 9C973C92 be invalid/broken? $ mkdir -m 700 newgnupg $ echo foo zinc-0.2.0.jar $ wget http://repo1.maven.org/maven2/com/typesafe/zinc/zinc/0.2.0/zinc-0.2.0.jar.asc This is a signature ostensibly made by a 2048-bit DSA key, made over an SHA-1 digest. DSA keys larger than 1024-bits should generally make signatures over stronger digests than SHA-1. See section 4.2 of FIPS-186-4 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf for similar guidance. Perhaps the folks who publish zinc need to --enable-dsa2, or to remove any mistaken digest-algo sha1 from their signing routines? You could point them at this thread in the gnupg-users archives if you think it would be useful. It doesn't matter if you specify --digest-algo sha1. Regardless of the setting of enable-dsa2, it the key wants a 256-bit hash, gpg won't allow you to sign with SHA-1. There is no way to generate that signature, at least in gpg. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On Mon, 17 Mar 2014 15:39, d...@fifthhorseman.net said: So gpg's behavior seems to be non-uniform here. That said, i'd love to As required by FIPS-186-3, 4.2: This Standard specifies the following choices for the pair L and N (the bit lengths of p and q, respectively): L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 and RFC-4880: 13.6. DSA An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. be able to tell gpg to ignore or explicitly reject signatures made by strong keys with MD5 digests. Run in enforced FIPS mode ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Subkey Pairs
That is an odd comparison. What does a statement about a fundamental law of physics which you can't change have to do with a statement about what you are doing, where you are perfectly free to do something else than you say? Try some variations. I deny that I've ever been to Vienna; is it logical to believe, based on that, that I've traveled extensively in Europe? I deny that I've ever seen _Star Wars Episode III_. Is it logical to believe, based only on that, that I've seen every other installment? I deny that I've ever read the second stanza of Coleridge's 'Kubla Khan'. Is it logical to believe, based only on that, that I've read the first? This is all rather irrelevant, though, since it's clear you _a priori_ believe nothing claimed by that outfit. (Which may be justified, mind you. Saying I do not trust them and I consider all of their statements a nullity: I will only trust what I can independently verify is a perfectly logical position.) You have not spend time understanding how YYY work it seems to me. There are two options here: either I confess my ignorance, in which case you'll claim to be more knowledgeable and thus right, or I claim my knowledge, in which case you'll think I'm clearly too close to them to be trusted. At this point, I don't care what you think. My original statement -- I have seen no credible claims that anyone anywhere in the world is doing bulk surveillance of email content on an internet-wide scale -- stands. I stand by that. No more and no less than that. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On Mon, 17 Mar 2014 15:39, d...@fifthhorseman.net said: So gpg's behavior seems to be non-uniform here. That said, i'd love to be able to tell gpg to ignore or explicitly reject signatures made by strong keys with MD5 digests. There is a new option in master: --allow-weak-digest-algos Signatures made with the broken MD5 algorithm are normally rejected with an ``invalid digest algorithm'' message. This option allows the verification of signatures made with such weak algorithms. Right, at some time we may need to add SHA-1 here. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Subkey Pairs
Am 17.03.2014 17:54, schrieb Robert J. Hansen: That is an odd comparison. What does a statement about a fundamental law of physics which you can't change have to do with a statement about what you are doing, where you are perfectly free to do something else than you say? Try some variations. I deny that I've ever been to Vienna; is it logical to believe, based on that, that I've traveled extensively in Europe? I deny that I've ever seen _Star Wars Episode III_. Is it logical to believe, based only on that, that I've seen every other installment? I deny that I've ever read the second stanza of Coleridge's 'Kubla Khan'. Is it logical to believe, based only on that, that I've read the first? All this examples lack the dimension of illogical, untruthful and purposely misleading communication, humans are capable of. Of cause in a pure logical environment all of your examples have to be answered with: You can't draw these conclusions. But taking into account that humans are not strictly logical, and taking into account the past we can reasonably make conclusions which we can't by pure propositional logic. Just one example from the not so far past: We are not and we will not spy on chancellor Merkel Without any context and background information it is not logical to draw the conclusion that there has been spying in the past. But knowing e.g. who said that, it is reasonable to assume so. This is all rather irrelevant, though, since it's clear you _a priori_ believe nothing claimed by that outfit. (Which may be justified, mind you. Saying I do not trust them and I consider all of their statements a nullity: I will only trust what I can independently verify is a perfectly logical position.) You have not spend time understanding how YYY work it seems to me. There are two options here: either I confess my ignorance, in which case you'll claim to be more knowledgeable and thus right, or I claim my knowledge, in which case you'll think I'm clearly too close to them to be trusted. There are at least three options: 3. My impression is wrong. At this point, I don't care what you think. My original statement -- I have seen no credible claims that anyone anywhere in the world is doing bulk surveillance of email content on an internet-wide scale -- stands. I was referring to this statement of yours: I cannot accept this assertion, as it is offered without either direct evidence or logically sound inferences. I don't care about the direct evidence but the logically sound inference that bulk surveillance of email content on an internet-wide scale is happening is reasonable. But if you want evidence [1]: At least some of the data traffic coming through the German internet exchange point DE-CIX is diverted to German intelligence and other agencies. They (and this is just the Germans) divert a certain percentage. It would be illogical if they wound analyze that in some way. Therefor by pure logic a mass surveillance is happening. Now we can argue about how mass and internet-wide scale are defined, but my assumptions is, that for you this example doesn't fulfill the criteria and because there is no evidence that other countries doing the same your statement will stand. I hope you never have a reason to start caring about what I think. Because your world seems to be the more righteous and calm place and I wish I didn't have to worry about the future of free societies as much. [1] http://www.h-online.com/news/item/PRISM-scandal-internet-exchange-points-as-targets-for-surveillance-1909989.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash
On Monday, March 17, 2014 10:39:58 Daniel Kahn Gillmor wrote: Perhaps the folks who publish zinc need to --enable-dsa2, or to remove any mistaken digest-algo sha1 from their signing routines? You could point them at this thread in the gnupg-users archives if you think it would be useful. Thanks! It seems they might sign their next release properly but I notified them just in case. Cheers, Juha ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
