Re: PGP/MIME considered harmful for mobile
On Sat, 26 Feb 2011 21:02:08 -0500, Avi avi.w...@gmail.com wrote: Why? Inline is simple and effective. I'm curious as to why you feel MIME is so much better. http://josefsson.org/inline-openpgp-considered-harmful.html jamie. pgpha2dSJArgJ.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME considered harmful for mobile
On Thu, 24 Feb 2011 20:22:03 -0500, Robert J. Hansen r...@sixdemonbag.org wrote: Just as an FYI to the list -- On Android's mail application, PGP/MIME attachments are nigh-unusable. It won't render even the plaintext portions: it has to be downloaded and opened with a text reader. If you're concerned about your mail being readable on a mobile device (which is increasingly important nowadays), you might want to consider switching to inline signatures. Yikes! I thought we were almost done killing inline signatures! Don't revive it now! If PGP/MIME is broken on android, we need to get them to fix it, not go backwards to inline pgp. jamie. pgpW6t3hiuiob.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Fri, 4 Feb 2011 20:08:08 +, MFPA expires2...@ymail.com wrote: IMHO, the comment field is firmly in the you don't need this at all category. If Heinrich Heine really wants his UID to be Heinrich Heine (Der Dichter) heinri...@duesseldorf.de he can type Heinrich Heine (Der Dichter) in the name field and heinri...@duesseldorf.de in the email address field. I *very* strongly agree with this sentiment. jamie. pgpncVJu4zsmt.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Thu, 03 Feb 2011 17:10:58 -0500, Robert J. Hansen r...@sixdemonbag.org wrote: On 2/3/11 4:30 PM, Daniel Kahn Gillmor wrote: my user survey is from several years of trying to personally help dozens of people of all skill levels learn how to use OpenPGP for secure messaging. Regardless of the intelligence or technical savvy of the people i've personally helped get more comfortable with OpenPGP, i believe all of them have been baffled by the Comment: prompt. I'm in a similar position to you, except this is my twentieth year of helping people with PGP. (I started way back in 1991, when PGP first came out and was distributed friend-to-friend on floppy disks... five and a quarter floppy disks.) I have never seen anyone be baffled by the 'Comment:' prompt. Some people have asked, What should I type here?, and I usually explain, nothing, just hit return, and they do. Those who ask what the Comment field means generally understand it very quickly. I have to agree with Daniel that I have in fact honestly never spoken to anyone who was *not* confused by that field. I can't ever remember seeing a comment field used in any way that made sense to me. I invite you to look through the User IDs in your own keyring, from the perspective of a potential certifier, and ask yourself what does it mean for me to certify these comments? Zero. Comments don't get certified. All my signature means is I have met this person face to face, have seen two forms of government identification, have confirmed a fingerprint and exchanged an email at that address. There's nothing in my signature policy that addresses comments, nothing at all. I'm not sure I understand this comment. Certifications are over user IDs. The comments are in the user IDs. By certifying the full user ID you are also certifying the comment. Omitting the baffling prompt entirely would be the most terse, which is what i propose. Do you object to that? Without a good basis, yes, I do. If you change this prompt you will also break a ton of scripts that expect this prompt. Not only that, but since key generation is a rare occurrence the breakage may occur months or years after the change is made. This isn't something to be done lightly. I think this is why his original suggestion was to move it instead to --expert. Moving it to --expert makes a lot of sense to me. jamie. pgptusULBZJoU.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Thu, 03 Feb 2011 17:54:39 -0500, Robert J. Hansen r...@sixdemonbag.org wrote: But i suspect he would not want to certify this User ID: Daniel Kahn Gillmor (I am really Robert Hansen) d...@fifthhorseman.net Correct. Because the presence of my signature means something. The *absence* means *nothing at all*, and you're smart enough to know that. Just out of curiosity, can you explain why you wouldn't sign dkg's hypothetical user ID? jamie. pgpkFAKu20oug.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to handle user passphrase input from python script
On Mon, 31 Jan 2011 03:41:51 +0100, orionbe...@gmail.com wrote: I use a python script to (a) open a file encrypted with a symmetric cipher using a passphrase, (b) do some operations on it, and (c) re-encrypt it. You might try using one of the many python gpg interface libraries that exist out there. With a cursory look I see three such packages in Debian: python-gpgme python-pyme python-gnupginterface hth. jamie. pgpvTIdjWsJiL.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What does the sub entry of a key mean?
On Sat, 15 Jan 2011 19:17:27 +0100, Bo Berglund bo.bergl...@gmail.com wrote: THanks, indeed the --with-colons gave a completely different output... I was just about to ask of the date format (if it changes between operating systems or such) but now I have a different problem in understanding the machine readable format. Very hard to understand. Is there a parsing guide somewhere? Hi, Bo. There should be a file called DETAILS (in doc/DETAILS in the gnupg source, or maybe included with your local installation) that describes in detail the meaning of the --with-colons output. It's exactly the reference you're looking for when writing a program to parse the --with-colons output. Good luck! jamie. $ head gnupg2-2.0.14/doc/DETAILS -*- text -*- Format of colon listings First an example: $ gpg --fixed-list-mode --with-colons --list-keys \ --with-fingerprint --with-fingerprint w...@gnupg.org pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: fpr:ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: $ pgp9kMTpPnBla.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgkey2ssh
On Thu, 21 Oct 2010 19:58:31 -0600, Aaron Toponce aaron.topo...@gmail.com wrote: So, help? Hi, Aaron. You might be interested in some of the tools that come with the Monkeysphere [0] package, which deals with a lot of OpenPGP for SSH stuff. It comes with the utility openpgp2ssh, which translates OpenPGP keys to SSH keys (and is well documented). From openpgp2ssh(1): SYNOPSIS openpgp2ssh mykey.gpg gpg --export $KEYID | openpgp2ssh $KEYID gpg --export-secret-key $KEYID | openpgp2ssh $KEYID Monkeysphere also has a command to import an authentication-capable OpengPGP subkey directly into an ssh-agent: $ monkeysphere subkey-to-ssh-agent It's available in Debian, Ubuntu, and some other distros [1]. hth. jamie. [0] http://web.monkeysphere.info/ [1] http://web.monkeysphere.info/download/ pgplGCTY4Rc9p.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 18:23:04 -0400, Robert J. Hansen r...@sixdemonbag.org wrote: I'm not. This idea isn't good. Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? jamie. pgph0M2eECPqg.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Sat, 16 Oct 2010 01:05:11 +0200, Hauke Laging mailinglis...@hauke-laging.de wrote: I just don't like the idea that access to the agent is not noticed by design. I strongly agree with this point. Let's think about it another way: what if the user is themselves doing something that is unintentionally accessing the key? They might prefer to know about it rather than have it accessed without their knowledge. I would say that's good enough reason to have confirmation right there. jamie. pgpnVgCOCUNn9.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 19:12:21 -0400, Robert J. Hansen r...@sixdemonbag.org wrote: Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? This seems to be an argument from implication of hypocrisy: as if, were I a user of ssh-agent, my opinion regarding gpg-agent could be safely dismissed on the grounds of my hypocrisy by not bringing the same issues up to the ssh-agent authors. No, I was just curious why, if you were an ssh-agent user, you would be ok with the implementation there but not for gpg-agent. If you're not an ssh-agent user then you have nothing to get defensive about. jamie. pgpP9szUlw4zT.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 15:56:52 +0200, Vjaceslavs Klimovs vklim...@gmail.com wrote: I did some quick tests on Nokia N900 (600 MHz ARM CPU), with gnupg 1.4.6, here is what I got: Encrypting and signing, 2048 bit RSA keys: real0m 2.50s user 0m 0.50s sys 0m 0.02s Decrypting and verifying, 2048 bit RSA keys: real 0m 1.74s user 0m 0.41s sys 0m 0.04s Encrypting and signing, 4096 bit RSA keys: real0m 3.58s user 0m 1.92s sys 0m 0.06s Decrypting and veryfying, 4096 bit RSA keys: real 0m 3.80s user 0m 1.89s sys 0m 0.03s Is one second considered a rule of thumb limit? That would mean that 4096 keys are not suitable for widespread use yet. Then by that logic neither are 2048 bit keys. jamie. pgpmmvzoiybHA.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 16:28:07 +0200, Vjaceslavs Klimovs vklim...@gmail.com wrote: 2048 bit keys are suitable - it's user+sys what matters in this case, but not real by all means, as that includes waiting for passphrase input too. I think this is really a UI issue, in which case real is what you really care about. An operation that takes 1s is annoying if it needs to be done frequently, but I'm not sure the operations we're talking about here really ones that are done that frequently. jamie. pgpvmHkukpkG5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 21:25:21 +0200, Ludwig Hügelschäfer mlis...@hammernoch.net wrote: Ack. 1.5 seconds is about the limit where a good GUI should issue a reaction. This is where the human mind is starting to think there's something wrong. We should be careful not to overstate the impatience of users too much. I've seen plenty of people wait many seconds for google maps to load on phones without giving up on the whole process. I also have an extremely slow machine were I routinely have to wait a long time (many seconds) for certain operations to complete. It's certainly not ideal, but I don't give up on those operations just because they take a little longer. I get used to it and figure out ways to deal. I'm not saying we shouldn't care about operations taking a noticeable amount of time, but I wouldn't state out-right that users will revolt and refuse to do something just because it takes more than a second. jamie. pgpGIWnJefD7B.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: local signatures: should they be importable by default in some cases?
On Tue, 22 Jun 2010 09:27:46 -0400, David Shaw ds...@jabberwocky.com wrote: On Jun 22, 2010, at 2:36 AM, Daniel Kahn Gillmor wrote: Can you elaborate on the usage you're describing? I'm thinking of a situation involving three people: Alice, Bob, and Charlie. Alice has met Bob in person and has verified his key. Alice does not want this information to be publicly available (e.g., she has concerns about exposing a transparent social graph via the keyservers). However, Alice knows and trusts Charlie and wants to put Bob in touch with Charlie, even though Charlie and Bob have never spoken before, and certainly have not verified each others' keys. Alice makes a non-exportable certification over Bob's key+userID, and mails it to Charlie (in an encrypted message, of course). Charlie imports the certification. Now even if Charlie does something like gpg --send $BobsKeyID, the fact that Alice has met Bob will not be publicly exposed. I'm not sure this is good behavior for Alice. If she is concerned about whether her linkage to Bob is publicly known, why would she risk that by giving Charlie a signature (local or otherwise)? Now she has not only to worry about keeping her linkage secret herself, but she also has to worry about Charlie keeping her linkage secret. I think that is a red herring. Charlie could also make a myspace page that talks about what great friends Alice and Bob are. No one can forcibly guarantee that all their linkages are kept secret. Alice has to ultimately trust Charlie on some level that he won't maliciously make those linkages public. I think the situation Daniel points out is one of the better usages for local signatures, and probably the main reason for having them in the first place. In the above scenario, it seems more reasonable for Charlie to locally sign Bob's key himself on Alice's say-so. But that creates a different trust path than the one Daniel describes. Just as with exportable signatures, Alice's certification of Bob is different in Charlie's eyes that Charlie's own certification. Charlie wouldn't (or shouldn't) make an exportable signature of someone whose identity he hasn't verified, so why should he make even a local one? According to your logic, everyone should just sign the keys of everyone they wish to have trust paths too, whether they've actually met them or not, just based on the fact that others they know have signed their keys, rather than relying on the calculated validity through known trust paths. The point of the scenario that Daniel is pointing out is that Alice and Charlie can use OpenPGP to *cryptographically* verify Bob's identity, without Charlie having to make certifications he otherwise wouldn't make. jamie. pgpK8OfVlzGCc.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: local signatures: should they be importable by default in some cases?
On Tue, 22 Jun 2010 09:51:58 -0400, Jameson Rollins jroll...@finestructure.net wrote: I think the situation Daniel points out is one of the better usages for local signatures, and probably the main reason for having them in the first place. Actually, looking at the RFC 4880 now, I see that the original definition definitely was that local signatures were intended to *only* be used by the issuer. From section 5.2.3.11 [0]: Non-exportable, or local, certifications are signatures made by a user to mark a key as valid within that user's implementation only. Thus, when an implementation prepares a user's copy of a key for transport to another user (this is the process of exporting the key), any local certification signatures are deleted from the key. The receiver of a transported key imports it, and likewise trims any local certifications. jamie. [0] http://tools.ietf.org/html/rfc4880#section-5.2.3.11 pgpi0fadBGzqy.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
keyserver queries over TLS [was: Re: auto refresh-keys]
On Sun, 20 Jun 2010 02:50:41 +0100, MFPA expires2...@ymail.com wrote: So in order to be safe you need additional CPU load either for TLS or for signing. Signing is superior IMHO because it allows reuse of the data (one crypto action (covering less data) for several users vs. one for each user with TLS) and makes more sense because you don't need a second crypto system (X.509) to protect the first (OpenPGP). Starting from where we are now, as far as I know there are no keyservers that sign their output, but there are keyservers that use TLS. And TLS does not have to be x.590. There is a draft spec for using openpgp keys with TLS http://tools.ietf.org/search/rfc5081 which is implemented in the GnuTLS library http://www.gnu.org/software/gnutls/gnutls.html This is turning into a separate thread, but while we're on it, I just wanted to point out that the Monkeysphere Project [0] currently provides a means for doing OpenPGP-based site authentication/encryption over TLS, and has discussed building a gpg plugin that can do OpenPGP validation of hkps keyserver queries: https://labs.riseup.net/code/issues/2016 jamie. [0] http://web.monkeysphere.info/ pgpTvvbTmjB9S.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Test mail to gnupg.u...@seibercom.net
On Fri, 11 Jun 2010 06:27:12 -0400, Jerry gnupg.u...@seibercom.net wrote: I am assuming that you wanted me to reply to this message. Its intended purpose was not overly clear. At least not to me, but then again I have not had my second cup of coffee this morning. I think if he had wanted you to respond to it he would have asked you to respond to it. jamie. pgpzBRIvtD0Pu.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyserver spam example
On Thu, 10 Jun 2010 11:32:05 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: And i should probably add that it is indeed an infinitesimal drop in the bucket compared to the other spam i receive; i'm not concerned about it. Not to mention that the bother of a couple of extra spams is completely dwarfed by the benefit of having the public keyserver network. jamie. pgprdXT59QKSN.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyserver spam example
Speaking of spam, I'm getting more spam from some sort of automated ticketing system that seems to be subscribed to this list that I ever have from a keyserver. The mail seems to come from: secure.mpcustomer.com and it often sets the From: to be from someone else. This is totally uncool. Is there a list moderator that can permanently ban anything From this address from the list? jamie. pgpEw3WpEL7zu.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Crypto Stick released!
On Thu, 03 Jun 2010 16:43:19 +0200, Crypto Stick cryptost...@privacyfoundation.de wrote: Each of the three keys can be up to 3072 bit. In fact they can even be 4096 bit long; but GnuPG does currently not support such key length in cooperation with the Crypto Stick (but GnuPG can handle 4096 bit soft-keys without the Crypto Stick). That's strange. What is the limitation with the bit length and GnuPG in regards to the Crypto Stick? Is that something that can be patched, or is it a limitation of the communication protocol? jamie. pgpZtUEt1mW7D.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Migrating from PGP to GPG question
On Wed, 24 Feb 2010 20:33:14 -0800, Smith, Cathy cathy.sm...@pnl.gov wrote: We are migrating from OpenPGP which is a freeware version of PGP. Sorry for the confusion. I'm not familiar with OpenPGP, the software. I'm familiar with the PGP Corporation's implementation (which I think is just called PGP), but not an implementation called OpenPGP. Having trouble finding any references to anything other than OpenPGP the spec as well. Would you mind passing on a link? Thanks. jamie. pgpTfz0XfXl9y.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Migrating from PGP to GPG question
On Wed, 24 Feb 2010 18:46:33 -0800, Smith, Cathy cathy.sm...@pnl.gov wrote: We are starting to migrate from OpenPGP to GnuPG. Just for clarification, GnuPG is software tool that is actually an implementation of the OpenPGP specification [0]. OpenPGP is not actually a piece of software itself, nor is GnuPG a specification. jamie. [0] http://tools.ietf.org/html/rfc4880 pgpj2xA8mtpQF.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
fragility of --edit-key interface [was: Re: Changing trust in GPGME]
On Wed, Jan 13, 2010 at 10:39:28AM +0100, Werner Koch wrote:
On Tue, 12 Jan 2010 23:41:52 +0100, Piotr Bratkowski wrote:
I have this code. And when I see output owner_trust = 4, but in gpg
from system I get 0. Do I need to somehow save this changes??
This is not directly supported by GPGME. You need to write an edit
interactor to control the gpg --edit-key command. GPA has code which
shows how to do it.
Hello Werner et. al. My understanding is that one of the main
advantages of GPGME is that it provides a stable API to gnupg
functionality. I understand that GPGME doesn't yet provide all the
functionality that a user might need, but I think that suggesting
developers use gpg --edit-key to achieve their desired functionality
should include a strong warning that the interface to gpg --edit-key
is fragile and may change unexpectedly and without warning.
For instance, as of v1.4.10 (and v2.0.13), the edit-key interface to
generate a subkey on an existing key ('addkey') in expert mode changed
such that the RSA (set your own capabilities) selection in the key
type chooser moved from entry 7 to entry 8. As far as I can tell,
this change was not documented, at least not in the any of the
changelogs associated with recent gnupg releases. The Monkeysphere
project [0] is using this capability and this undocumented change
recently caused problems.
Developers looking for the stable interface that GPGME is supposed to
provide should be duly warned that the gpg --edit-key interface is
not as stable, and that they should be on the look out for changes to
that interface in the future.
jamie.
[0] http://web.monkeysphere.info/
signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
