Re: why is SHA1 used? How do I get SHA256 to be used?
On Tue, Jul 10, 2012 at 08:15:32PM -0400, Robert J. Hansen wrote: There tends to be a lot of scaremongering in the world of crypto. I think it's generally wise to be careful in our declarations. It is enough to say SHA-1 is known to not meet its design specifications and that some fairly devastating attacks against it will likely be coming along in the near future. That's already a good enough reason to reduce our usage of and dependency upon SHA-1. There's no need to fearmonger about how the algorithm has already collapsed, because it hasn't. I'm not saying it has collapsed. I'm saying that it has weaknesses, and that the number and magnitude of the weaknesses continue to grow, and that I think it is imprudent to use SHA-1. I would much rather people make the move to something better now, because otherwise we'll all be stuck with SHA-1 long after it's insecure, just like it's been with MD5. Practically, collisions can be generated for 75 of the 80 rounds[0]. Right now, only random collisions can be generated. That's not any use in forging a signature, which requires a preimage collision. A cryptographic break is not the same as a practical exploit. It's an indication of weakness. I've seen lots of people that work with crypto claim that we don't need larger margins of security. The cost of computation is so small that I'd rather overdo it than regret my decision later. I don't generate signatures with algorithms I consider insecure because that leads to people being able to forge signatures in my name. Then you need to stop using OpenPGP altogether, because you're already generating SHA-1 signatures with your certificate which can be lifted and dropped onto new messages if/when a preimage attack is introduced against SHA-1. Really? I'm pretty sure that I'm not generating SHA-1 signatures. This is signed using SHA-512, SHA-384, or SHA-256. When I sign another key, I use SHA-512. At least that's what I've configured GnuPG to do, and I'd be very surprised if it did not, in fact, do that. If it is using SHA-1, please report it to the list: it's a bug. Let me make this really clear: if you believe SHA-1 is insecure, you believe OpenPGP is insecure and you should stop using it. SHA-1 is hardwired into the OpenPGP spec in a few different places and, as of right now, cannot really be removed. The new V5 key format will almost certainly change this, but V5 won't be coming out for a good long while yet. SHA-1, for my current key, is being used to generate my fingerprint. It's being used in MDCs when I encrypt a message. And it's being used instead of the default checksum for my private key. That's it. Since my private key remains solely in my possession and is not subject to tampering, what checksum is used is really irrelevant. Since I sign my messages when I encrypt them, the MDC is essentially redundant, since it would be apparent that they'd been tampered with. It is extremely unlikely that an attacker would be able to tamper with the encrypted message such that they could produce a valid, signed unencrypted message. And I'm personally not happy with the use of SHA-1 for the fingerprint, but it'll have to do for a while. I wish we had chosen RIPEMD-160 instead. I feel it's a better, more conservative design. If I use MD5, even for one message, that allows a moderately determined attacker to replay that signature on what is likely to become a fairly large set of messages. I'd rather avoid that, thank you. You've *already done this*. Really? Can you show an example? If you truly believe this, stop using OpenPGP. Is my statement not true for MD5? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: why is SHA1 used? How do I get SHA256 to be used?
On Tue, Jul 10, 2012 at 10:10:12AM -0400, Robert J. Hansen wrote: SHA1 is no longer secure. At the present moment, SHA-1 is just fine. In the fairly near future, anywhere between six months to a few years, I expect this will change. But SHA1 is no longer secure is factually untrue, at least where OpenPGP is concerned. SHA-1 is considered cryptographically broken. It does not provide the level of security it claims. Practically, collisions can be generated for 75 of the 80 rounds[0]. I hardly consider an algorithm this close to a collision just fine. There's no need to run screaming to the exits, but a quick and orderly transition has been appropriate for some time. The time to move to something else is ending soon. I don't recommend SHA-1 for new signatures, but if you have a choice between sending a SHA-1 message which your recipient can verify or a SHA-256 message which your recipient can't, well -- that math's pretty easy to do. SHA-1 isn't a good choice for new signatures, but it's a lot better than no signature. I don't generate signatures with algorithms I consider insecure because that leads to people being able to forge signatures in my name. If I use MD5, even for one message, that allows a moderately determined attacker to replay that signature on what is likely to become a fairly large set of messages. I'd rather avoid that, thank you. I'm not going to cater to people using really old versions, especially when security is involved. The good news is that no one's asking you to. You're only being advised, don't use --digest-algo SHA256, it's unwise and can break interoperability. Use --personal-digest-preferences SHA256 instead. This is the same advice that has been given by the GnuPG developers, by the Enigmail team, and by many other people within the community. It's a best-practices thing for GnuPG. The question is, will GnuPG fall back to SHA-1 if it's not in my digest preferences? I'd much rather fail to generate a signature than generate one using an algorithm which is very weak. [0] http://eprint.iacr.org/2011/641 -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ideal.dll
On Fri, Jun 22, 2012 at 02:18:13PM -0400, Robert J. Hansen wrote: On 6/22/2012 1:44 PM, ved...@nym.hush.com wrote: As you mentioned earlier, the v3 people have an entrenched user- base, and are hardly novices, and 'for them', listing the keysize with the fingerprint, really is trivial. If people want to keep using PGP 2.6, let them, but I'm not going to help them do it. If people want an emergency stopgap while they migrate to OpenPGP, I'll happily help. Unfortunately, at this point essentially all the people who would migrate have already migrated. There are people using v3 keys that are not using MD5 (other than the fingerprint, obviously). I am one of them. My v3 key (0x560553e7) has v4 self-signatures on it, none of which recommend MD5. All of the preferences are for algorithms presently considered strong (except SHA-1, but removing that isn't possible, unfortunately). Obviously, I'm not using PGP 2.6, since it won't read my key. I have moved to using a v4 key for everyday usage, but my v3 key still has more signatures on it than my v4 key, and I am not planning on revoking it by any means. I still accept signatures on it and data encrypted to it, just like I do with my v4 key. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint
On Sat, Apr 28, 2012 at 10:21:52PM +0100, michael crane wrote: what is the reasoning for attaching the key ID to the end of the fingerprint string ? That's the way the key ID is derived for v4 keys. v4 keys use the low 64 bits (or 32 bits for short key IDs) as the key ID. v3 keys used the low 64 bits (respectively 32 bits) of the RSA modulus. However, this posed two problems. One is that the low bit is always one (multiplying two large primes together does that). The other is that originally v4 keys were all DSA or Elgamal. Those algorithms don't have a modulus in the same way[0], so a different technique had to be used to derive a unique fingerprint. [0] Basically, the one (for Elgamal) or two (for DSA) primes that are use as moduli can be shared securely among many keys, so using them as the sole basis for a key ID means arbitrarily many keys can have the same key ID, which kinda defeats the purpose. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [new-user] question
On Thu, Apr 12, 2012 at 11:21:16PM +0100, michael crane wrote: hello, I'm trying to understand the principals and benefits of using pgp/gpg I think I understand that I send the part of my key that is public to somebody and they use that key to encrypt a message which only I can decypher. So what if somebody uses my public key to send me a message purporting to come from somebody else ? what is the mechanism to ensure it came from who I think it did ? The sender can sign the message to verify that it came from him or her. If someone just sends you an unsigned encrypted message, there is no way to verify that I came from who you think it did. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: comments on uid
On Sat, Mar 17, 2012 at 12:11:39AM -, freej...@is-not-my.name wrote: The comment can only be added when creating the UID. If you wish to add, remove or edit you can create a new UID and set it as primary. If the key has not been shared, you can delete the old UIDs, but if it is already on the keyservers the copies there cannot have bits removed. Thanks for the info. Is there some reason why we can't edit the UID? I realize it doesn't help if the key is on a server but this key is not. When you compute a signature over a UID, part of the data you hash is the UID. If the UID is different, then any signatures aren't valid anymore because the hash result will be different. The facility isn't implemented since it breaks all existing signatures and is essentially equivalent to deleting an old UID (which really can't be done if the UID has been published) and adding a new UID. If you want to do those two steps, you have to do them manually. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: compilation information ?
On Mon, Mar 12, 2012 at 01:24:06PM -0400, ved...@nym.hush.com wrote: Is there any command that tells how the gnupg version was compiled? gpg --version doesn't list it. A simple way to find out is to do gpg --armor filename [or any other command resulting in gpg .asc file], and the information will be listed in the version line, i.e. Version: GnuPG v1.4.12 (Cygwin) Is there any way to find out without performing a gpg function on a file? From looking at the source, I don't believe so. Note that the only case in which you have more than one option is Windows/DOS. For other platforms, the binary is always compiled in the ordinary way. I expect exposing this information was not considered to be terribly important since most platforms don't have this issue. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On Fri, Mar 02, 2012 at 04:55:23AM -0800, Post Carter wrote: 3) Next, the recipient decrypts the message. Since at its lowest level the encryption amounts to XOR'ing the message text against the secret key, it essentially results in the flipping of each class of text. C becomes P and P becomes C: PPPCCPP It is not true that encryption amounts to XORing the message text against the secret key. That type of encryption is not secure because it is trivial for someone to XOR two blocks (of the key size) of ciphertext together in order to get the XOR of the plaintexts. This allows trivial analysis of the plaintext. Stream ciphers usually create a key*stream* and XOR the plaintext against that. OpenPGP implementations do not use stream ciphers proper; instead, they use a block cipher in CFB mode. So by flipping bits what you get here is not only flipped bits in the data, but a corrupted next block. Also, CFB mode, what is XORed is the output of a block cipher encryption of the previous ciphertext. 4) In the attack scenario, when the recipient sends the gibberish to the sender, they are sending the now encrypted part of the message above denoted by CC: PPP --CC-- PP 5) The attacker intercepts and XOR's the gibberish CC against their original insertion PP from #2 to deduce the key. Then they can decrypt the original C contents from #1. This doesn't work, because all you get is the output of the block cipher. That doesn't tell you the key if the block cipher is secure. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using the not-dash-escaped option
On Thu, Feb 02, 2012 at 08:45:56PM +, MFPA wrote: On Thursday 2 February 2012 at 9:50:34 AM, in mid:874nv9va1h@vigenere.g10code.de, Werner Koch wrote: Sure it does not work if you use Content-Transfer-Encoding: 7bit The message body looks exactly the same in the copy in my sentbox, where the header you cite above says Content-Transfer-Encoding: quoted-printable I think what Werner is saying is to use quoted-printable encoding; then, the space will be represented as =20 (when encoded) and it will be less likely to get eaten by hungry mail-handling tools. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [META] please start To: with gnupg-users@gnupg.org, i.e.:
On Tue, Jan 31, 2012 at 11:23:25PM +, MFPA wrote: On Monday 30 January 2012 at 7:06:43 PM, in mid:20120130190643.gb184...@crustytoothpaste.ath.cx, brian m. carlson wrote: The problem is that unlike regular list messages, the dupes don't come with the list headers, which makes sorting them based on the list headers problematic. The group's email address gnupg-users@gnupg.org usually appears in the To: or CC: field of the duplicate message. Why not filter/sort on that and catch most of them? Because that means that instead of using one procmail rule to autosort all mailing lists I have to write one for every list I might subscribe to. This is error-prone and defeats the purpose of using a generic tool to do repetitive tasks easily. Most mailing lists have a List-ID header for this purpose. Majordomo lists use a different convention which is also easily sorted on. Also, when I'm subscribed to a mailing list, I expect people to post their replies to the list unless there's a personal reply that is not appropriate for the list. For lists that require subscriptions, that means that it's guaranteed that everybody will get a copy, which is the point of a mailing list. Why intentionally send me an extra? Who wants two copies of an email? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why hashed User IDs is not the solution to User ID enumeration (was: Re: Creating a key bearing no user ID)
On Fri, Jan 27, 2012 at 07:52:56PM -0600, John Clizbe wrote: Having keyservers support no-modify requires that they first support crypto. That's a really big step. To my knowledge, no one is working on such an initiative in SKS or any other keyserver. I'm working on an OpenPGP library which may sprout a keyserver daemon supporting this, but there's no guarantee that that will happen anytime soon, if ever. Don't hold your breath. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA padding scheme
MFPA wrote: On Monday 23 January 2012 at 12:47:03 AM, in mid:20120123004703.GB10912 at crustytoothpaste.ath.cx, brian m. carlson wrote: This is not a problem with OpenPGP because the attacker never gets to see the value encrypted with RSA because it's the symmetric key. Isn't that the same thing as the session key, which can be viewed using --show-session-key? Yes, it is. However, decrypting a message does not automatically provide the session key to the user (outside of the internal functionality of the OpenPGP implementation). So what I'm saying is that even if you have an oracle that will decrypt messages on demand and provide them to the attacker, that doesn't mean that the oracle is going to provide the session key used to decrypt that message, which you need to conduct the attack. Also, please, please, please don't ever CC me. This resulted in a major delay as I deleted the message which I am now replying to and had to cobble it together based on the archive. Please respect my Mail-Followup-To and post replies only to the list. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using root CAs as a trusted 3rd party
On Tue, Jan 24, 2012 at 03:13:46PM -0300, Faramir wrote: Well, if Trent signs Alice key, Bob, who trust Trent, might sign her key too. Charly doesn't know Trent, but he trusts Bob's judgement, so he might accept Alice's key as valid, not because of Trent's signature, but because of Bob's signature. Also, maybe Trent only signs keys if 2 persons have checked it, but he just sign it once, that signature doesn't reflect the amount of people having checked it. This is why OpenPGP implementations have trust settings. If Bob trusts Trent's assertions, then he can give Trent full trust and Bob's implementation will believe that Alice's key belongs to Alice. There's no need to sign the key. If I truly believe that a key belongs to someone that I have seen use it for several years and that is trusted by numerous other people, but I have not verified the connection between that person's identity and key myself, I use a local signature. That way I don't have other people rely on my assertion if I haven't done the amount of checking that I would like to before making a public statement. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 1024 key with 2048 subkey: how affected?
On Mon, Jan 23, 2012 at 02:18:54PM +, Chris Poole wrote: If the only purpose of the primary key (in my case, where I have subkeys for signing and encryption) is to sign the subkeys, why not simply make it stupidly large? Equivalent to 256 bits with a symmetric cipher, or 512 bits? Because it's also used to sign other people's keys. Using a very large key (for 256-bit equivalence, ~15kbits) makes verification so slow as to be unusable. You have to not only verify signatures on other keys but also the signatures on the subkeys. This is less of a problem with implementations that verify signatures only once and then cache the results, but most implementations do not do that. Also, there's nothing preventing people from actually signing data with the primary key, so someone who is unfamiliar with your strategy might accidentally use a single, very large key. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA padding scheme
On Sun, Jan 22, 2012 at 07:48:28PM +0400, Sergey Matveev wrote: As I understand, such asymmetric ciphers as RSA and/or ElGamal requires strong padding applied before message is encrypted. Message is of course the one-time session key, used to encipher the actual data. To use them correctly and securely, yes. There are different versions of PKCS#1, NESSIE, OAEP and other schemes exist. How can I get which one is used? Trivial grep-ing through the 1.4.10 source code (which one I am using) does not help me much. GnuPG uses PKCS #1 v1.5. This is specified in RFC 4880. Moreover I did not find the way padding can be changed/specified for example for RSA. You cannot choose a different padding scheme and remain in compliance with the OpenPGP standard. I will be glad to understand what I am missing. If the standard allowed different padding schemes, then all implementations would have to support multiple padding schemes, which would be burdensome without providing significantly more security. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA padding scheme
On Sun, Jan 22, 2012 at 11:29:54PM +0400, Sergey Matveev wrote: If the standard allowed different padding schemes, then all implementations would have to support multiple padding schemes, which would be burdensome without providing significantly more security. Hmm, I see. However does it really won't provide much higher security? Just theoretically very interested in all of that. According to Wikipedia, there are several kind of attacks against plain RSA (just some of them): * sending ciphertext with the same e to several recipients This depends on a small message. All secure padding schemes avoid this problem because the pad the message so it is not small. * no randomness All secure padding schemes provide this, as well. * problems with the product of two ciphertexts This is not a problem with OpenPGP because the attacker never gets to see the value encrypted with RSA because it's the symmetric key. So, padding should close all of those problems. As I can see, PKCS #1 1.5 just adds random pad to satisfy length requirements. Is those randomness sufficient to solve above three issues? OAEP, comparing to PKCS #1 1.5, is much more mature and looks really cool with dependent on each other X and Y. The existence of PGP predates the invention of OAEP by at least three years. So it really wasn't an option, and PKCS #1 v1.5 is not insecure, so there's no reason to break backwards compatibility. If PKCS #1 1.5 is sufficient, then OAEP just brings all-or-nothing additionally? Or because of RSA's ciphertext payload is always pretty random data (symmetric keys), then (probably) bad padding won't deal any damage? Basically. The issue is that if the padding is incorrect, the message is rejected. So the attacker can't manipulate the message without risking corrupting the structure of the method. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: maximum passphrase for symmetric encryption ?
On Tue, Dec 27, 2011 at 07:54:05PM -0500, ved...@nym.hush.com wrote: That's exactly my question. Does gnupg have a maximum string length for a passphrase, and restrict itself to the entropy contained within that length? Not to my knowledge. OpenPGP does not specify a maximum string length for a passphrase, and it's limited only to the amount of memory you have, or in some cases 2^61 bytes (which is essentially unlimited). I tried symmetrically encrypting, using a string of 65 characters, and it works, and requires exactly those 65 characters to decrypt. (Substituting any other character for the 65th character does not decrypt). Yes. When you use a passphrase to encrypt, the entire passphrase is hashed, so if the input is at all different, the passphrase will be rejected. Most modern OpenPGP implementations repeatedly hash the passphrase and use salt (8 bytes of random data stored with the passphrase to make the hash unique even if you reuse the passphrase). This makes brute-force attempts slower since more computation is required. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Bad Signatures when using check-sigs
On Fri, Dec 16, 2011 at 10:26:04AM -0500, David Tomaschik wrote: When executing gpg --check-sigs, there are reports of bad signatures. What makes a signature bad? For example, on a key I signed that has several UIDs, one of my signatures on one UID is reported as bad, but the rest are fine. I looked in the docs, but didn't find anything... hope I'm not missing something obvious. It means that one of the following things is true: * The key alleged to have made the signature did not make the signature. * The data on which the signature was made is different than the original data. * Someone made an error in the OpenPGP implementation. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: kernel.org status: establishing a PGP web of trust
On Sat, Oct 01, 2011 at 07:01:14AM -0600, Aaron Toponce wrote: Having a sufficient amount of paranoia, would keep you from using DSA, I would think. I have an RSA key with RSA subkeys, but now that larger DSA keys are generally available, I'd be okay with revolving DSA signing subkeys. As you've pointed out, DSA has the disadvantage that k must always be different, but it also has advantages, one of them being that p, q, and g can be shared among a group of people such that p and q can be *proven* to be prime and generated in a reproducible way. Another one is that DSA signatures are smaller: there are two MPIs stored for each signature, but those MPIs are at most 256 bits long each, while for an RSA signature that was only 512 bits long, the security would be woefully inadequate. Point being, both DSA and RSA have their good and bad points, and if you're fairly confident that you have a good PRNG, such as /dev/urandom, then there's not really much concern about k. After all, you also need a good PRNG for CFB IVs as well, although the consequences aren't as disastrous. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Manually compute key fingerprint
On Mon, Aug 29, 2011 at 10:23:30PM -0400, Dennis Nezic wrote: How can I manually compute the fingerprint for a key? sha1sum pubkeybinary doesn't match gpg --with-fingerprint pubkeybinary ... isn't the fingerprint simply supposed to be the sha1 hash of it? The fingerprint is a hash of certain data in the public key packet, not the entire file itself. This makes sense if you think about it, because the file containing the public key also contains user IDs, signatures, and potentially subkeys. If you were to just hash the file, then the fingerprint would change every time you added a new ID or signature, which would not be hhelpful. If you need to be able to compute the fingerprint independently, you'll need to parse the public key packet and follow the formula specified in RFC 4880. It's not terribly difficult. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Keyrings WAS Signing multiple keys
On Fri, Aug 26, 2011 at 10:29:04PM +0100, Nicholas Cole wrote: I *do* see the uses for them. The debian keyring, for example is huge, and it is useful to be able to selectively include it or not in the gpg.conf file. But there more I've thought about this, the more I think that it would be better just to have entirely separate gpg home directories for this sort of purpose. There is a lot of infrastructure in Debian that depends on the ability to have read-only keyrings using a command-line option. If that functionality were to disappear, somebody would patch it in because the breakage would be too great (and needless). If an additional option were required to use multiple keyrings, I would submit a patch to make it the default because otherwise it would break existing functionality. Besides the several different programs that handle key signing parties, dpkg-source would lose the ability to verify packages before unpacking them. apt's archive verification would break. That doesn't include dak, the Debian Archive Kit, which also uses GnuPG and would also break. I expect that most GNU/Linux distributions would also use those patches for the same reasons. Removing the capability from GnuPG would not have the effect of removing the functionality, but only on shifting the maintenance burden. For the case in question, there would be nothing to stop you having a home directory made specifically for a key-signing party, for example, importing your signing key into it and using it as your working directory. '--homedir', not multiple keyrings, seems to me to solve the problem addressed by multiple keyrings for almost all real-world cases. Creating a separate directory and populating it seems silly and wasteful, plus it prevents the storage of multiple, separate keyrings in one directory (like /usr/share/keyrings). If you would like to use the --homedir method, nothing is preventing you from doing that. But breaking existing infrastructure will go over like a lead balloon. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Implementation question: validating left two of signatures
I have a quality-of-implementation question (more in general than specifically about GnuPG). I am writing an implementation of OpenPGP that verifies signatures, among other things. Signatures contain the left two bytes of the hash as a quick check. I've noticed that a small number of signatures are in fact valid even though this quick check does not match the hash. Is it considered acceptable to fix up this value if it is wrong? If not, is it acceptable to treat two signatures as the same signature if they are identical but for the left two? Does GnuPG (or any other implementation) actually give any credence to the left two whatsoever? If there's an OpenPGP implementers' list or another, more appropriate forum, please feel free to point me in that direction. I couldn't find one, so I posted here. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
