Re: OpenPGP card reset procedure
On Wed, 27 Feb 2013 14:00, ni...@dest-unreach.be said: sending 4 VERIFY-commands with the same (wrong) PINcode. It next locks the Admin PIN using a similar procedure. Right. According to my understanding, this will ACTIVATE FILE, and next TERMINATE DF. While the spec seems to indicate the reverse should be done: You are right, I once messed it up somewhere but meahwhile my gpg-connect-agent script to reset the card is: /hex scd serialno scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 44 00 00 scd apdu 00 e6 00 00 /echo card has been reset to factory defaults Which is as it should be. Either way, the procedure (with first ACTIVATE and next TERMINATE) seems to work, I just don't understand how... That is a bug in the card. 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
/etc/gnugpg.d/
What about having /etc/gnugpg.d/ where you can drop configuration files just you can drop them into /etc/apt/apt.conf.d/? For example someone could make a hkps distro package, get the certificate into the correct place and drop a configuration file to use the certificate. Werner Koch: On Tue, 26 Feb 2013 16:43, do...@dougbarton.us said: keyserver-options ca-cert-file=$GNUPGHOME/ca.hkps.pool.sks-keyservers.net.cert I see that it can make sense to have such variables. However, we will need to add a meta option to allow such variable substitution. Thus if you want to do that you would need to use something like enable-var-subst somepath $gnupghome/foo.bar We have something similar in gpg-connect-agent, where variables have been added only later and thus over there you need to use /subst. The available variables would only be those known to GnuPG and not arbitrary envvars. In particular those available with gpgconf --list-dirs. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 2013-02-23, Jerry je...@seibercom.net wrote: Well, each to his/her own I suppose; however, I would not approve of the file being sent to my PC regardless. There is always the possibility of the email being intercepted and exploited or my PC being compromised. There is a security element to this, but it actually works the other way around. SSL is considerably *less* secure than an openPGP message. Here's why: * CAs: SSL requires you to trust a certificate authority (and to date CAs have already been exploited). * MitM: There are also a number of MitM techniques that work on HTTPS connections. One attack that comes to mind involves establishing a non-SSL connection to the customer. They get no pop-up about a bad cert because there's no cert involved. The attacker even uses an icon of a padlock for the site, so if the customer is careful enough to look for the padlock, but not careful enough to look where the browser puts it, they will be fooled. Alternatively, an attacker can simply use an untrusted cert knowing that many people will just click through their browsers popup warning anyway because they cannot be bothered. * Phishing: There are many tricks that bait customers into logging into a rogue site that masquerades as their banks, ultimately creating a compromising interaction would be avoided if the statement were properly delivered. * storage: When a customer downloads their PDF statement over https, the PDF is unencrypted and it remains in that state, vulnerable to anyone who penetrates their home pc. Securing the storage requires additional effort on the part of the customer (generally unlikely). OTOH, if PGP is used, the statement is encrypted in storage by default. A customer would have to proactively decrypt the attachment with intent to archive it in the clear in order to achieve the same vulnerability as the status quo. If I want confidential information delivered to my PC, that should be my business. If an institution wanted to offer that option, and thereby being issued a released of responsibility, I have no objections to it. You would not need any such release of liability. All natural people banking in the US are free of liability per regulation E. (I say natural people, because businesses do not get reg. E protection). Although banks bear the liability for poor security choices, they generally do not care. They just need a facade that complies with the poor standards and comforts the relatively street-unwise shareholders. IOW, they only need to *appear* secure, they don't actually care to *be* secure. Hence why they don't bother with PGP. If banks had a genuine interest in security, they would at a bare minimum be PGP clear-signing their e-mail notices to customers. It would impose no technical changes on their customers, but customers keen to detect phishing could do so, and the bank could then honestly say that they've taken an effective step toward mitigating phishing attacks. Dumb user tools could then be created that makes it possible for everyone to detect phishing attacks, not just those who are keen. I do not consider the clicking on of a secure link and downloading the document to be an inconvenience, but rather a security feature, Requiring a periodic human interaction is obviously less convenient for the human. And as I pointed out, it simultaneously less secure. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
Figuring out how to install an app is not the problem. Figuring out how to *use OpenPGP* is the problem. The app is not the same as the amount of specialized knowledge required to use the app successfully. The installation problem takes care of the other. Hushmail users need not know any more than yahoo users when opening an account. A HM user may not even be aware that PGP is in play, or what PGP is. OpenPGP has a learning curve like the Matterhorn. This is a long-known and long-lamented fact. If you can fix that, then maybe things will change. As things stand, though, I doubt they will change. It's been fixed. Check out countermail.com, or hushmail.com. take the bait. Such an app could embed an email client that does everything the advanced users would do, and hide everything possible. Such an app could even hide the email address, and hide the fact that email is used at all, if they wanted. Then why bother at all with email and OpenPGP? For the /other/ users. They're not good at it. On the contrary, many of them are phenomenally good at it. Operations Research is part of the business school in most universities, and the OR geeks tend to be astonishingly good at what they do -- which is maximize efficiencies and cut inefficiencies. I'm not sure why you put so much stock into the MBA. An MBA merely makes someone into a good bullshitter, so their idea, however flawed, is better marketed to upper management. In the end, the result is better marketing spin, not better ideas. And worse, better ideas end up losing out to better marketed ideas. When one MBA is pitted against another, the decision makers ignore it anyway, and vote with their gut and use whatever data supports the decision they've already made -- not the other way around. It's a sham. I understand that many geeks like to look down our noses at people in the B-schools, but really, that's a shallow prejudice that we as a community need to get over. There are some alarmingly sharp people over there. It's really not a good time to attempt to prop these guys up, when every economy in the world is suffering acutely from their colossal and aggregate incompetence. A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security I'm going to have to ask to see the business study you're using to back this up. Do you need a business study to prove that a helicopter costs more to maintain than a bicycle? The contrast is so sharp, one would be a fool to even consider funding such a study. I won't waste any time trying to track down the proof that you're asking for. But I will say that ssh and textual interfaces are decades more mature than javascript, Adobe Flash, Flash cookies, and all the other dodgy shit you find on bank sites (and casino sites alike). And the difference in complexity is staggering -- complexity being directly proportional to defects, which in turn are directly proportional to security vulnerabilites. Moreover, an SSH server wouldn't drag the bank into the vicious pattern of chasing the shiny.. e.g. there would not be a need to work on improving the smoothness of animations that must glide accross the screen. New web frills are emerging on a rapid and ongoing basis - highly unstable. This means the cost of securing it is an ongoing cost. This recurring cost is needed just to keep up with the new bugs that are being introduced -- a cost that comes on top of the normal cost of intrusion detection and incident response. This is your prejudice, nothing more. I know studies have already proven the relationship between complexity and bugs - although I don't recall where the research was done, it's not just my imagination. And the relationship between bugs and vulnerabilities is security 101. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: /etc/gnugpg.d/
On Thu, 7 Mar 2013 15:44, adrela...@riseup.net said: What about having /etc/gnugpg.d/ where you can drop configuration files just you can drop them into /etc/apt/apt.conf.d/? In general I consider those configuration directories a bad idea. They are nice at the first view because they make packaging easy but after all they are unreadable. Sure, for some applications they make sense (/etc/pam.d/) but definitely not for GnuPG. I also miss to understand how they would help to solve the OPs problem. 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
gpg 2.0.19-r1 with libgcrypt 1.5.0-r2 -- Segmentation Fault
Hi all, I hope this is the most appropriate place for this...please let me know if there's a better spot. Anyway, I'm getting a segfault whenever I try to use GPG to encrypt or decrypt any message. I have all my keys, public and private, imported from another system which works exactly as expected, and which should be more or less identical to the one that seems to be broken. I'm running Sabayon, a fresh install and fully updated, if that is useful information at all... Here's what happens: feign@mahakala ~ $ gpg --decrypt lebowski.asc You need a passphrase to unlock the secret key for user: My Email 1024-bit ELG key, ID 429C2EF5, created 2013-01-16 (main key ID 719D9903) gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: My Email 1024-bit ELG key, ID 429C2EF5, created 2013-01-16 (main key ID 719D9903) gpg: encrypted with 1024-bit ELG key, ID 429C2EF5, created 2013-01-16 My Email gpg: signal Segmentation fault caught ... exiting Segmentation fault So yeah, it looks to be validating my passphrase correctly (I typed it incorrectly on purpose first just to check), but then it seg faults. On my other system, with the same keys and gpg version, I can run the same command and it works just fine. Thoughts? Any extra information I can provide? I'd really like to get this working, and I'm pretty baffled. Thanks! Rob ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Possible to use GNUPGHOME as a variable inside gpg.conf?
On 03/07/2013 05:41 AM, Werner Koch wrote: On Tue, 26 Feb 2013 16:43, do...@dougbarton.us said: keyserver-options ca-cert-file=$GNUPGHOME/ca.hkps.pool.sks-keyservers.net.cert I see that it can make sense to have such variables. However, we will need to add a meta option to allow such variable substitution. Thus if you want to do that you would need to use something like enable-var-subst somepath $gnupghome/foo.bar We have something similar in gpg-connect-agent, where variables have been added only later and thus over there you need to use /subst. The available variables would only be those known to GnuPG and not arbitrary envvars. In particular those available with gpgconf --list-dirs. That would be awesome, can't wait to try it. :) Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
