Re: ePGP extension for mobile
Thanks once again for the feedback. Best, Edwin On Thu, Jan 2, 2014 at 3:04 PM, Olav Seyfarth o...@enigmail.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi Edwin, IN SHORT To your question: I don't think there is a mobile solution for ePGP available. LONG ANSWER I wasn't aware that you referred to a product. I interpreted Enterprise PGP as (any) enterpsise-grade OpenPGP-Implemenation. I apologize for that confusion. While I see the benefit of centralized PGP implementations, I personally would not use epgp.org any more since it seems to be abandoned: the last build is from April 2007 - almost 7 years old. No (security relevant) bugs found since then? I don't know the product. I see no mail client integration in the screenshots, so I assume it works similar to http://www.symantec.com/gateway-email-encryption and http://www.zertificon.com/produkte/z1-securemail-gateway/ . In security gateways, messages get signed/verified/en-/decrypted on the server. Thus, messages behind that gateway (in the 'local network') travel unprotected. (Usual transport layer security such as TLS should be applied though.) GnuPG-list-off-topic Additional thoughts/ideas: To access Mail from mobile devices, one way would be to have a VPN connection to the mail server /behind/ the security gateway, leaving you with unencrypted messages on the phones. You might use a special app that uses phone-independent protected storage (such as R2Mail2), or put yor company mail app inside some secured container (such as Good for Enterprise). Or you might set up additional key pairs for each mobile device and push all incoming messages to special (even publicly available) 'mobile devices accounts'. You'd have to provision the corresponding key pair to each phone and may use any (unprotected) mail app. /GnuPG-list-off-topic Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJSxX/hAAoJEKGX32tq4e9WoWIMAJgyX8zyIfLPE/ZL+i/R6rOj sDMMTDuO/gDL3JBd/lwZugLnk2oA1Mym5bT8xAX28wjKGx7/EFpMByBALLNB2AY6 Ir/nkHcPwGF7FGzr9wsdD9wnsEN7co8KbaAbJEh7488dgJEkaxhUImAWZ6WEtMb8 AseE/jN18drFKRLk1uma6HrlTl0EFRco1I9pEKk9J8qgPiYuzFGJVhgRtNN1C/4a X2qN3qjpNODOp1cd+CvLQFaa8RO/SefTEiwDLE5U3/zZphS4WEzXAwivAixdF6d8 Tsi9LoKHrVP2BmitaErUh6xWQCK4lNqyylz3F8DNc2PCv+vjs94d9mNJ24v+GKs6 xBPqJQ/Lg0RKyWNNd1r7mndL70tWKp9D+9C6v1k5V9ohwWYY5qlWqkar9g35kLaD NS7V2V0aKF1yyBy1DUP0Z/xKNMOZFLtKvdMu/w2cQQeeZTP2aOB+jJq7p9zyqz2x C+msM9NNj6/IiidhmsN/bm3NfEXqIoylXi61f6ZESA== =9ofq -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
Am Fr 03.01.2014, 00:33:51 schrieb Doug Barton: On 01/02/2014 09:35 PM, Hauke Laging wrote: | I just noticed that you can easily be deluded about an email being | encrypted: That you receive an encrypted mail does not mean that it | was sent encrypted. An adversary may encrypt a non-encrypted message | (which he has intercepted) in order to create more trust in the | message for the recipient: If you receive critical information and | are aware that it has not been encrypted then you may react | differently from the case where you are sure that is was encrypted. This threat model doesn't make a lot of sense, except for very naive users who cannot distinguish the importance of a message that is encrypted vs. a message (encrypted or not) which is signed. I am quite sure you have misunderstood something. Sorry if I didn't make myself clear. Do you agree that it is (or, depending on the content, can be) an important information whether a message was encrypted by the sender (and for which key)? How can it make little sense to provide this information? Whether it is more important to encrypt a message or to sign it differs a lot with the content. Thus I do not understand your explanation of importance. This is similar to SSL/TLS without client negotiation: The client knows (or: can know) whether it is encrypting for the right server. But the server cannot know whether the legitimate client has started the connection or an MitM attacker. If the server demands certainty about that then it has to require the use of client certificates. But currently there is (AFAIK) no such thing as an analog for the client certificate in the OpenPGP world. The certificate itself is already there, of course, but it is not yet used in a way providing security for the recipient about the confidentiality of the message. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 FYI, your client has horrible line wrapping. If there is a setting, please change it to 72 columns. On 01/03/2014 12:59 AM, Hauke Laging wrote: | Do you agree that it is (or, depending on the content, can be) an | important information whether a message was encrypted by the sender | (and for which key)? Not particularly, no. The message doesn't get encrypted using the sender's key, although it may be encrypted to the sender's key, along with the recipient's. What advantage does it give to the attacker to encrypt a message via MITM? The likely outcome of doing so would be to reveal that they are intercepting messages, for what benefit? That's a legitimate question, not a snark. You seem to be suggesting that this would provide value to the attacker, if so can you elaborate? | How can it make little sense to provide this information? If the sender cares they can insert a statement in their signed message. I did/did not encrypt this message before sending. Problem solved. | Whether it is more important to encrypt a message or to sign it | differs a lot with the content. Thus I do not understand your | explanation of importance. My argument is that the _only_ thing relevant to message validity is the signature on the message itself. Whether it was encrypted or not should play no role in the recipient's calculation of the validity of the message. | This is similar to SSL/TLS without client negotiation: No, it's not at all. But I don't want to quibble about that, I'm still interested in your description of the importance of the encryption itself, separate from the message and signature. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSxn8pAAoJEFzGhvEaGryEulsH/2u1seI5K62Y0Aa5fKI3SRAD eBc8n62Se7sXw8rOXR+Qp5k191Upg1/Po2mkTSpgPjqc47yeAPaj4pHBAQIiAlgC 1iDdb4RveB3zZeJ4HpVgrRR5ap3S8w+SmnDdbul4evVcnuHnzP7zOFOZ5ZgIVnr8 Aoaei1jaaKal6p6qf5FDOA2c/Ni8pALZ8ZaUDNlDOLMpRS02uKZHUJwpx7eCDuKK wvvk6X7nicetiKdklDX31eoabGuhu0ret3BbAwq6EEXaAD6FnPIuhgHcvLZzz6Tj c0XuJD+UYK67p/rm4EdxUdr57rJ3Kr/hKdTjtBVy/l17LZZoXuROa8KSblwtr2U= =aqFY -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/03/2014 01:13 AM, Doug Barton wrote: | My argument is that the_only_ thing relevant to message validity | is the signature on the message itself. Whether it was encrypted or | not should play no role in the recipient's calculation of the | validity of the message. Sorry, that's a little bit stronger than I intended. There are of course cases such as, This is odd, every communication I have ever had with Alice about $SUBJECT previously has been encrypted, but this one is not, I wonder if there is a problem here? But for the common case my point remains the fact that a message is encrypted should not enter into the validity calculation. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSxoAjAAoJEFzGhvEaGryE7GsH/0wItxi1Q8kvHU/0dy0mjRkE jgRl0d8njyWVxhx6SDAbyZoAJ6w+oTHz0fdLRhspwvSuKcvrX4Zs0G3Y9Kr18EJg 39rhpedLCijs/Q5x55V/RZR0Wfs3uNP7V58w4nCgL6pzhwgb2xmOarOn7reEuvn2 xFff4NXPAg6xKZpT/5IkT5Y2K0oD/xu7QIWfZKvYpI482QwkVVmZwv5j6sW2p/lm Wbi9Hh0bnhL46YVSoH6Z/Lh/cnwsfL89F5Xl6YHyzInWJhH2nHsRy6KLzZSOx00q Qv9Zli3bx5PvStujwxJ/iGHPgnYCZn2Qjsc/jAp3gSdItcdj4uDIDQGQucRO7lQ= =8OZQ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 1/3/2014 3:33 AM, Doug Barton wrote: This threat model doesn't make a lot of sense, except for very naive users who cannot distinguish the importance of a message that is encrypted vs. a message (encrypted or not) which is signed. I'm going to cautiously disagree. What we call very naive users account for the vast majority of GnuPG users. Unfortunately, that's as far as my disagreement goes. I see what Hauke's getting at, but I disagree that it really amounts to much of a problem, or that his proposed fix would work. The real problem Hauke's discovered is, people generally don't have the educational background to think formally and critically about trust. Which is, well, true -- but that one's a hell of a hard problem to solve. Everything else (including sign-encrypt-sign schemes) amounts to just ways to try to dodge the real issue. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
Am Fr 03.01.2014, 01:13:13 schrieb Doug Barton: On 01/03/2014 12:59 AM, Hauke Laging wrote: | Do you agree that it is (or, depending on the content, can be) an | important information whether a message was encrypted by the sender | (and for which key)? Not particularly, no. The message doesn't get encrypted using the sender's key, although it may be encrypted to the sender's key, along with the recipient's. That's not what I am talking about. I am talking about the recipient having keys with different security levels. So there are keys I (insecure) and S (secure). By insecure I mean a key like the one which signs this email: Being used on a normal system (i.e. an insecure one; oh no, in a moment Rob will notice that I used secure and insecure again...). If data is so important that it shall not be encrypted for my key I but for my key S only then I want to be sure that it has been encrypted by the sender for S. That the message which arrives at me is encrypted for S does not ensure this. Anyone can encrypt messages for my key. What advantage does it give to the attacker to encrypt a message via MITM? As I said: If a normal user (i.e. one with nearly no security clue at all) starts an email conversation without encryption (or with weak encryption) and I notice that (because the message arrives unchanged) then I will tell the sender to change his behaviour. He will probably to that and the communication becomes secure. It is in the interest of an adversary to prevent the communication from becoming secure. The likely outcome of doing so would be to reveal that they are intercepting messages, In my opinion it is very unlikely that this would be revealed. There are people who like to get everything encrypted and those who prefer to get only important data encrypted. Every serious adversary will know what type his target is. This is more or less a public information. So if somebody wants everything encrypted why should he ever ask or mention that? It is possible, yes. Thanks for encrypting your messages. Who does that? And how many senders unfamiliar with crypto would understand from that that their message has been modified? Maybe a nice feature of their great ISP? Even worse with asking such a sender whether he has used the right recipient key. Probably he will not even understand the problem or misassess the situation. And if the recipient expects only important data to be encrypted then the adversary would encrypt only important data (which may be hard to decide automatically though but who would notice a minute delay under normal circumstances?). And why should the adversary not risk being detected? We encrypt because we assume that there are adversaries. | How can it make little sense to provide this information? If the sender cares they can insert a statement in their signed message. I did/did not encrypt this message before sending. Problem solved. Yes. But why should the sender care? The sender can be sure about doing it right! The recipient is the one who cannot. And why should we bother writing that in every mail if there is a simple automatic solution to it? You cannot even be sure that the information is correct! People make mistakes. My argument is that the _only_ thing relevant to message validity is the signature on the message itself. I do not doubt that in any way but my argument isn't about validity at all. It is about guaranteed confidentiality! That is a big difference. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't decrypt message encrypted with ECC
On Thu, 2 Jan 2014 18:54, eagleeyes...@yahoo.com said: I have created a test ECC 25519 subkey. You mean using the experimental code in GnuPG master? Don't use it - it is is work in progress. 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
How to do pinentry in same screen as gpg
All, I have a script that I use to send mail (as part of pine/alpine) that needs to prompt for my key passphrase. I run alpine on a private unix server, within a screen session. It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Here's where I've gotten on a possible solution: I could possibly have every window within my screen session have my .cshrc check for a running gpg-agent, and start one if it's not (this seems wasteful considering how infrequently I sign). Along these lines, I'd probably have to have every single screen process update the running TTY, so that my most recently-opened screen would contain the dialog. It seems that the pinentry command is invoked behind the scenes by the agent, and then directly writes to and reads/from the tty specified (so it could in theory interfere with whatever else I'm running on that screen), for example, if I were doing something while su'd to root. -or- It would also be nice if pinentry could cause the spawning of a new screen window via screen -X, but as I have a password-protected screen, this isn't possible either. -or- It might also be nice if I could basically start a pinentry program in a dedicated window, and simply choose to use it when needed (similar in analog to how I might use a hardware pinpad, or a fingerprint reader). I don't know if this is possible. I could also start up some dummy program in a screen where the agent will spawn. I think that last one is the plan of attack I'll likely pursue. However, it would be really, really nice if, instead of gpg--agent--assuan--pinentry, GPG could just fall back to prompting for a password on the same tty where GPG is running. It would also be nice if GPG had some method of simply saying hey, I can't find a place to spawn this pinentry, and could exit cleanly. Thoughts are welcome. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
Am Fr 03.01.2014, 10:02:28 schrieb MFPA: OpenPGP's mitigation against this is signing emails, and the web of trust to give assurance who signed. That's exactly why I want signatures. But I do not only want a signature which guarantees the data integrity, I want a(nother) signature which guarantees the (correct) encryption. You mean the recipient has 2 keys, one of which the adversary has compromised? And the adversary intercepts and decrypts mail that is encrypted to the compromised key, then sends it on its way encrypted to the non-compromised key? Yes, that is the more complicated case. Again, this would be flagged up if the sender was in the habit of signing outgoing messages (as you stated). No, it wouldn't. The reason is that the signature is created the same way in the two cases encrypted and non-encrypted. Thus you can apply encryption later with the recipient having no chance at all to determine who encrypted. (this may mean that you sign it twice: once before and once after encryption). Is that better than the usual signing and encryption carried out together? It is better with respect to ensuring the encryption. It has disadvantages, though, otherwise we wouldn't do it the other way round. Proving the authenticity becomes more difficult if there is no signature within the encryption because a third party cannot encrypt the data. You would need to give them the session key. Who is capable of doing that? Furthermore you cannot know whether an encrypted message has been signed within. That may be an advantage in certain situations. You can send an encrypted message anonymously. That is not possible with my proposal (you would have to add a fourth layer... not difficult though). But I do not suggest to make my configuration the default. I just want to be able to use it. Sometimes it's best to send a signed cleartext message, sometimes to send an unsingned encrypted message, sometimes a first signed then encrypted message and I want to stress that sometimes it's best to send a first encrypted then signed (or signed-encrypted- signed) message. Both your examples seem to involve encrypted-only and not signed messages, The problem is the same with signed and unsigned messages. so would be unaffected by introducing additional signature options. I don't understand that statement. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
Am Fr 03.01.2014, 04:28:38 schrieb Robert J. Hansen: or that his proposed fix would work. Would you explain how that shall be avoided? You send an email to me. You encrypt it to the key which I want you to encrypt it to. Then you sign the encrypted data. If I receive an email from you which is not encrypted and signed (as the outer layer) then I go on red alert. Like today I might if the message is not encrypted or not signed. How shall THEY create an encrypted-signed message if you have e.g. sent it without encryption? The adversary needs your signing key. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. It might also be nice if I could basically start a pinentry program in a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 1/3/2014 4:57 AM, Hauke Laging wrote: Would you explain how that shall be avoided? I already did, in quite clear language. You are trying to solve a social problem (people don't have the background to think formally about trust issues) via technological means (if we just change the way we sign...). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 03/01/14 10:57, Hauke Laging wrote: If I receive an email from you which is not encrypted and signed (as the outer layer) then I go on red alert. Like today I might if the message is not encrypted or not signed. How do you know the sender doesn't have an unencrypted copy of the message in an easily broken into online backup service? The encryption of one copy of a message doesn't imply the confidentiality of all copies that exist. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On Fri, Jan 03, 2014 at 06:21:05AM -0500, Robert J. Hansen wrote: On 1/3/2014 4:57 AM, Hauke Laging wrote: Would you explain how that shall be avoided? I already did, in quite clear language. You are trying to solve a social problem (people don't have the background to think formally about trust issues) via technological means (if we just change the way we sign...). I think the need for such a fix could also be highlighted in the following example. I sign the message Got to talk tomorrow at dawn, then send it to Alice, thinking about the cake for the birthday party, not important so not encrypting it. Bob grabs the message, and sends it encrypted to Alice's highest security key. Alice then thinks it is a really important message, and the matters to discuss are really important. She takes with her the top secret files we are working together on. Bob, knowing the place and date of the meeting, then comes and steals the top secret files. So changing the encryption could break an opsec. I'm not saying it would be useful everyday. But some use cases seem to require it. However, I'm not saying this feature should be included by default, as a fix would be easy (call gpg twice), and I can think of few use cases. BTW, is a timestamp included in the signature? If not, it could lead to similar issues. Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
On Fri, 3 Jan 2014, Hauke Laging wrote: Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. No, the agent is required, per the manpage. If GPG doesn't find an agent, it starts one: I just fired up a gpg --gen-key on my system where 2.x is installed. danm 74860 0.0 0.1 13728 2120 ?? Ss1:18PM 0:00.02 gpg-agent --daemon --use-standard-socket danm 74853 0.0 0.1 17408 3136 3 I+1:18PM 0:00.02 gpg --gen-key (gpg2) danm 74861 0.0 0.0 9264 1972 ?? I 1:18PM 0:00.01 pinentry (pinentry-curses) It leaves this agent running after you exit GPG, which feels sloppy -- ssh doesn't leave ssh-agent running after I connect, if I use it at all. It might also be nice if I could basically start a pinentry program in a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. I seem to recall that I was able to do it by messing heavily with environment variables. As I want to get back into playing with smartcards, the agent become more necessary. (Or keeping v1 and v2 installed in parallel, which seems nonoptimal). Hauke, in your posts, you mention that the pinentry protocol isn't on the GPG website. Could that please be fixed by the people who maintain the project? I notice it also missing from http://www.gnupg.org/documentation/manuals/ If I come up with a good method for doing so, I'll post a howto/blog here. I do wonder how difficult it would be to write a pinentry-getline which doesn't try to do any fancy display tricks -- I just want enough magic to turn echoing off. (I think the ncurses are part of what mess alpine up). I may try this as well. Thanks all, -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
On Fri, 3 Jan 2014, Hauke Laging wrote: Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. It might also be nice if I could basically start a pinentry program in a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. Actually -- it *looks like* loopback-pinentry is pretty much exactly what I'm looking for here, if I understand the feature. Hopefully recent fundraising activity can get 2.1 out the door soon. (I'm going to donate!) -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 01/03/2014 08:12 AM, Leo Gaspard wrote: So changing the encryption could break an opsec. If someone's opsec is based on the question of whether a message was encrypted or not, then they've probably got their cart before their horse too. opsec requirements should indicate whether you encrypt, not the other way around. BTW, is a timestamp included in the signature? If not, it could lead to similar issues. Yes, all OpenPGP signatures generated by standards-compliant tools include a timestamp: https://tools.ietf.org/html/rfc4880#section-5.2.3.4 --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 01/03/2014 12:35 AM, Hauke Laging wrote: From the RfC perspective (PGP/MIME) this should not be a problem; you just need another level of nesting. Maybe the mail clients are not even prepared for reading such messages. That would not surprise me but would not be an argument against one client implementing this as the first one. I am interested in general arguments for and against this. it sounds to me like you might be interested in what the S/MIME community calls triple-wrapping, which is used to provide cryptographic proof-of-origin and attribute-handling for intermediate transport agents: http://www.isode.com/whitepapers/smime-military-messaging.html https://bugzilla.mozilla.org/show_bug.cgi?id=380624 That said, triple-wrapping (or similar approaches) have tradeoffs that we might not want to encourage. For example, they leak metadata about who signed the message to anyone who observes it in transit; this is not the case for the traditional sign-then-encrypt layering. metadata gathering is a fruitful surveillance technique. but at its core, i think the problem you're raising is related to a fundamental (but probably common) misunderstanding: people assume that if something is encrypted to them then that is related to some signal from the message author, even though asymmetric encryption has nothing to do with authenticity or verifiability. I don't think you're going to solve that particular problem by having some e-mails have an extra layer of signature on them. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
Il 03/01/2014 11:28, Hauke Laging ha scritto: But I do not suggest to make my configuration the default. I just want to be able to use it. Sometimes it's best to send a signed cleartext message, sometimes to send an unsingned encrypted message, sometimes a first signed then encrypted message and I want to stress that sometimes it's best to send a first encrypted then signed (or signed-encrypted- signed) message. I can't come up with a situation where sign, encrypt, sign again w/ *same* key used in the first signature gives more security than first encrypt then sign. So two layers are enough. I (partially) get your point: receiving an encrypted message could mislead an uneducated user... But I doubt someone w/ access to top secret material falls in that category :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
On 03/01/14 14:31, Dan Mahoney, System Admin wrote: Hauke, in your posts, you mention that the pinentry protocol isn't on the GPG website. Could that please be fixed by the people who maintain the project? I notice it also missing from http://www.gnupg.org/documentation/manuals/ I remember that post by Hauke. Let me quote my reply I wrote to this list back then: On 11/12/13 10:43, Peter Lebbing wrote: On 11/12/13 08:38, Hauke Laging wrote: I wonder why none of these commands (GETPIN, GETINFO, not even BYE) are explained on http://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html I suppose because that is the agent protocol description, not the pinentry protocol description. They're both Assuan protocols, but they're different protocols. I can get a description of the pinentry protocol simply by: $ info pinentry True, it's not exactly the website :). I agree it would be good if the manual were on the website, and I can't find it either, but let's wait for the new design. Oh, btw, slight addition: BYE is not in the agent (or pinentry) protocol description because it is a basic assuan command, so it's described at [1] or info assuan. HTH, Peter. [1] http://www.gnupg.org/documentation/manuals/assuan/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
NSA seeks to build quantum computer that could crack most types of encryption
Hi all. Nothing new actually, but this is nice point: “The irony of quantum computing is that if you can imagine someone building a quantum computer that can break encryption a few decades into the future, then you need to be worried right now,” Lidar said. [1] [1] http://www.washingtonpost.com/world/national-security/nsa-seeks-to-build-quantum-computer-that-could-crack-most-types-of-encryption/2014/01/02/8fff297e-7195-11e3-8def-a33011492df2_story.html Cheers, Filip ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On Fri, Jan 03, 2014 at 12:50:47PM -0500, Daniel Kahn Gillmor wrote: On 01/03/2014 08:12 AM, Leo Gaspard wrote: So changing the encryption could break an opsec. If someone's opsec is based on the question of whether a message was encrypted or not, then they've probably got their cart before their horse too. opsec requirements should indicate whether you encrypt, not the other way around. Well... So, where is the flow in my example? This example was designed so that, depending on the level of encryption (and so the importance of the safety of the message according to the sender), the message had different meanings. Sorry, I can't see yet where I went wrong. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 01/03/2014 06:56 PM, Leo Gaspard wrote: On Fri, Jan 03, 2014 at 12:50:47PM -0500, Daniel Kahn Gillmor wrote: On 01/03/2014 08:12 AM, Leo Gaspard wrote: So changing the encryption could break an opsec. If someone's opsec is based on the question of whether a message was encrypted or not, then they've probably got their cart before their horse too. opsec requirements should indicate whether you encrypt, not the other way around. Well... So, where is the flow in my example? This example was designed so that, depending on the level of encryption (and so the importance of the safety of the message according to the sender), the message had different meanings. As you've noticed, the sender cannot verifiably communicate their intent by their choice of encryption key. If the sender wants to communicate their intent in a way that the recipient can verify it, they'll need to sign something. In your example, the fact that a message was encrypted makes the recipient treat it as though the sender had indicated something specific about the message because it was encrypted. This is bad policy, since there is no indication that the sender encrypted the message themselves, or even knew that the message was encrypted. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On 01/03/2014 01:28 AM, Robert J. Hansen wrote: On 1/3/2014 3:33 AM, Doug Barton wrote: This threat model doesn't make a lot of sense, except for very naive users who cannot distinguish the importance of a message that is encrypted vs. a message (encrypted or not) which is signed. I'm going to cautiously disagree. What we call very naive users account for the vast majority of GnuPG users. I don't necessarily disagree with you on that. :) Unfortunately, that's as far as my disagreement goes. I see what Hauke's getting at, but I disagree that it really amounts to much of a problem, or that his proposed fix would work. The real problem Hauke's discovered is, people generally don't have the educational background to think formally and critically about trust. Which is, well, true -- but that one's a hell of a hard problem to solve. Everything else (including sign-encrypt-sign schemes) amounts to just ways to try to dodge the real issue. Yes, that is the point I was trying to get across. ... and I did actually suggest a solution to the problem Hauke is (ostensibly) trying to solve. The sender can include a statement in their signed message regarding whether or not they also encrypted it before sending. However I would still argue that doing so would have no real benefit. Thinking further, what *may* be useful would be for the mail client to pop up a message that says something similar to, This message was encrypted, but not signed. No assumptions should be made about the validity of the message itself. In the end however there is no substitute for user education. :-/ Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
