Re: User experience of --hidden-recipient encryption
On 30.01.2016 14:36, Peter Lebbing wrote: > On 29/01/16 19:32, Bjarni Runar Einarsson wrote: >> Also, if I go with a), does that leak the fact that there were >> hidden recipients? Does it leak how many? > > I'd say yes and yes. Every recipient has their own Public Key Encrypted > Session Key (PKESK) packet with the (shared) session key encrypted to > their key. The only difference between a regular recipient and a hidden > one is that the regular ones identify which key the packet is meant for, > whereas each hidden recipient has a packet without that identification. > So the number of PKESK packets without identification is equal to the > number of hidden recipients. It leaks that there were and how many there > were, just like you can identify all non-hidden recipients by the > remaining PKESK packets. Leakage of exact number of hidden recipients can be mitigated by adding random number of pseudo-recipients (e.g. generate some more keys on your localhost and add them to recipients). signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Master Key Best Practice with SmartCard
On 25.01.2016 12:08, Antoine Michard wrote: > It's work well except that for https://encrypt.to, he use my first > encryption key and I can't decrypt it with my Smartcard. I'd report an issue to encrypt.to maintainer. encrypt.to also doesn't handle correctly the case when more than one key matches speceificed short key id, e.g. https://encrypt.to/0x70096AD1, the shown fingerprint doesn't change when you change selection. -- xmpp:andrey.ut...@decent.im signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to export ASCII armored secret key without passphrase?
On 01/20/2016 07:13 PM, Peter Lebbing wrote: > Is your GnuPG 2.1.10 binary invoked as "gpg", not as "gpg2"? Which OS is this > and where did you get GnuPG 2.1.10? This might be an issue if you want to > install GnuPG 1.4 alongside. I believe in Debian, the plan is to name the 2.1 > binary gpg and the 1.4 binary gpg1, but that hasn't been done yet AFAIK. In Gentoo this is the case. And it also currently doesn't allow to have two installation at the same time. There's concept of slots, but nobody has cared enough to implement different slots for it. -- xmpp:andrey.ut...@decent.im signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Constant "gpg: keyserver refresh failed: Invalid IPC response"
This happens all the time with default key server hkp://keys.gnupg.net, with pgp.mit.edu it's the same, but slightly higher chance to get a proper result. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please consider joining Bountysource Salt to collect recurring donations
On 10.12.2015 18:49, Robert J. Hansen wrote: > ... So, yeah. I'm thinking this is not a credible source for > fundraising. Arduino and GNOME, projects with *far* greater visibility, > get $0 a month from Bountysource. I find it hard to believe we'd do > much better. > > I think this is something best avoided. > The Salt project has released this spring or this autumn, I don't remember for sure. There's competing project Gratipay (former Gittip, rebranded recently), and some more, so there's also a fragmentation. Yes you are right that these platforms (and recurring donation to FOSS projects in general) is far from being as popular as it should be. But basically this is a network, and the value of network is bound to number of members in it. If nobody is in, nobody considers joining worth. The more time passes, the more projects and backers join and the more is money flow. I was surprised to become first backer of FFmpeg project, which was already set up :) Also I am not aware how much hassle is it for you to set up your donation-collecting account on these networks, but I hope it's not that painful. Werner, Donate menu entry got better, but there's another issue - when cursor pointer moves from menu header down to menu entries, menu dropdown tends to disappear, it takes many attempts to catch it :) Thanks for all the comments. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Please consider joining Bountysource Salt to collect recurring donations
On 10.12.2015 01:29, Robert J. Hansen wrote: >> This request targets GnuPG maintainers to register a team on that >> (and/or others, e.g. Gratipay) croudfunding platform. > > Is there some problem with the existing donation system? If there's a > problem then let's fix it, but I'm not sure it's a good idea to change > something that works. Wow, actual Donate page turned out to be a secret area, not obvious to get to it (it looks like a menu header, not a menu entry). Without regard to that: - subj enables recurring donations (personally I am not willing to make large one-time transcation), - subj is a place where people eager to give go to find whom to give, - subj is new, it gains popularity and gets people attention, so somebody would consider GnuPG when reviewing projects available for funding. -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Please consider joining Bountysource Salt to collect recurring donations
This request targets GnuPG maintainers to register a team on that (and/or others, e.g. Gratipay) croudfunding platform. GnuPG users are welcome to comment whether they would support such opportunity. Occasional GnuPG contributors are welcome to comment whether they would like to become "bounty hunters" (an opportunity on subj site). I am not affiliated to these platforms. -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why gpg 2.1.9 cannot export secret key without passphrase?
Just for note. This can be worked around the following way (works in both 1.4 and 2.1, didn't test in 2.0). 1. Export key, giving any non-empty passphrase. 2. Import key on new location supposed for automated key usage. 3. `gpg --edit-key `, there type "passwd", enter old passphrase, enter empty line twice, strike Ctrl+D, confirm changes saving. This works identically in both 1.4 and 2.1. If importing location has no capability of passphrase changing (--edit-key) - e.g. Android Open Keychain - import it to 1.4 keychain, then export it, it will let you export it without passphrase (won't even ask for it). Thank you Peter for pointing out that this is solvable without fixing the issue in code, but your suggested solution wasn't enough, so I had to go a few steps further :) I'd like to state this explicitly (due to rational point made by Peter) that the link to my private GnuPG git fork with a patch is not supposed a working solution - it is an experimental work in progress which is not assured for being interoperable. It is a fruit of uneducated reckless tinkering with original code. -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why gpg 2.1.9 cannot export secret key without passphrase?
Thank you for your hints Peter. The following tiny changes allow exporting and importing to succeed https://github.com/andrey-utkin/gnupg/commit/a3b539b6ef7c922b1f1f3f343fdc942086d96c4e Is the approach of using "s2kmode = 0" and "protection sha1" together correct? Shouldn't "protection none" be used? -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: question about gpg2 and passphrase
On 02.12.2015 22:12, Smith, Cathy wrote: > I need to be able to decrypt a file using gpg2 in batch. I have a > customer who requires us to provide a public key that is RSA 2048 bit. > I have RHEL6 available which provides gpg 2.0.14 to create the key > pair. However, I’ve not been able to use gpg2 in batch to provide the > passphrase to decrypt a file. It wants an interactive prompt for the > passphrase. I’ve tried some things that I’ve read on-line without any > success.Is there a way to configure gpg2 to accept a passphrase in > batch? Hi, Have you tried generating a key with empty passphrase? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why gpg 2.1.9 cannot export secret key without passphrase?
On 30.11.2015 21:53, Peter Lebbing wrote:
> On 30/11/15 20:10, Andrey Utkin wrote:
>> Is it impossible straight from RFC 4880 in any defined mode, or is
>> it just a wrong behaviour in GnuPG/Libgcrypt?
>
> It is a specific bug of GnuPG 2.1, and Werner's comment on the bug entry
> mentioned here makes me believe he intends to fix it eventually.
>
> GnuPG 1.4 and 2.0 can export keys without passphrases, and this is fully
> defined in RFC 4880.
Thanks for clarification. I'd be glad to help Werner to fix it if he has
no time.
Could you please direct me to exact S2K-stuff modes for exporting it
which would be compliant with earlier GnuPG branches 1.4 and 2.0? Then I
would have a chance to accomplish the fix in finite time.
>> Empty passphrases are banned in several places in this software:
>
> Yes; that's because there is a difference between not encrypting stuff
> and encrypting it with an empty passphrase :). The latter is just silly.
> The only purpose of doing that is to be able to tell your client that
> you "encrypted it" without technically lying. And I'm not making stuff
> up. This actually happens (I'm looking at you, DropBox!).
>
> When a private key is stored without a passphrase, it is stored without
> encryption. The actual packet looks different: it clearly indicates that
> what follows is plaintext. If you were to encrypt it with an empty
> passphrase, it would actually be encrypted, but with a key that
> corresponds to an empty passphrase and hence would be trivially cracked
> by anyone.
Surely these two ways are distinguishable. But for unattended processing
cases, I'd like a mode that makes utils skip all passphrase entry
prompts. I guess the no-encryption case ("trivially cracked by anyone")
is needed here.
Which of the mentioned modes was used in 1.4 and 2.0 for exporting
without passphrase?
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)
On 28.11.2015 17:36, Peter Lebbing wrote: > On 27/11/15 22:55, Andrey Utkin wrote: >> Any comments? > > Could you outline a sequence of steps that goes wrong without your > solution and right with it? > > Like: > > - SSH to compromised PC > - Use SSH agent forwarding > - While logged in to compromised PC, SSH from there to another > > Wrong: > - Compromised PC opens whole host of SSH connections purporting to be you > > Right: > - Keychain confirmation server comes in guns blazing, data center > containing compromised server turns into mushroom cloud > - Mushroom clouds don't impersonate sysadmins > > I'd like to see a detailed usage scenario. Preferably with mushroom clouds. > > Peter. > Thanks for your interest. Your joke describes one of usage scenarios quite well :) Let me describe how exactly this is supposed to work when key must be used. The whole process still looks similar to smartcard key usage, especially regarding user's action to enable key access operation (PIN entry). So it is easier to start with looking at using smartcard. Note: I have no practical experience with actual OpenPGP smartcards and I'm not convinced with their usability enough to spend couple of hundreds of bucks or more (with shipping cost) to try them. As far as I see there is a common problem with reviewing what exactly is being encrypted/signed. I was told on another forum that this issue is solved by pinpads with displays, like this one (sorry for russian): http://www.rutoken.ru/products/all/rutoken-pinpad/ , but this is what I otherwise see for "pgp smartcard pinpad": https://www.google.com/search?q=pgp+smartcard+pinpad&tbm=isch Why not to make such review and confirmation operation fully software-defined, overcoming limitations of hardware appliances? This idea is even more appealing when you consider the accessibility of both VPSs and handheld devices with great displays? VPS or handhelds are attackable, but their availability allows user to set up one dedicated to keys operation, keeping attack surface of key vault minimal. This is what is wrong with the case of smartcards in my opinion. In a word: - costs money ( -> won't be chosen by a lot of people despite the rise of interest to privacy); - costs even more money and/or time to get it in far countries (good stuff is not quite available locally, or is, but for very high price); - key length limitations on certain hardware solutions (can't say for all, but I guess that 's true for majority of available hardware); - hard to use large set of keys. Let's also look at the case when we use local keys just on a local machine (as I do now, being unwilling to go with smartcards). Consider the case that user has just one full-blown workstation at hand, and needs to use untrustworthy software like browsers and closed-source apps. The workstation is not powerful enough to jail all untrusted applications to virtual machines like Qubes OS project proposes. (Even if it is powerful enough, Qubes OS is far from being production-ready, and manual AppVM handling without Qubes is pain.) In this case, what is primarily important is to store keys (and, well, all sensitive data) anywhere but locally. This looks like the situation with SSH agent forwarding to untrusted host (regarding that we don't want to store keys on it), but with the difference that we _start_ on an untrusted machine and we are not ssh-ed to it from anywhere. So even without confirmation control, remoting the keys operation is beneficial. And if we add user confirmation interface, then we eliminate the risk of what you have described as "Compromised PC opens whole host of SSH connections purporting to be you". The confirmation interface can be implemented in any convenient way. E.g. the confirmation dialog may be raised on a network-enabled smartphone; keys may be stored on smartphone or on a remote server. So, my speculations make me think that I want to implement what I have described in original posting, and that I would want it the same way even if I used smartcards daily. I am sorry if all my long posts don't explain a lot to you or don't make a lot of sense. I raised the discussion here in hope to gather opinions or get directed towards ready-to-use solutions not known to me before. Now I see that it probably makes sense to try to implement this schema in a limited scope, see how it goes, describe it comprehensively (with mushroom clouds, as requested) and present it here for review. Thanks. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why gpg 2.1.9 cannot export secret key without passphrase?
On 27.11.2015 13:28, Peter Lebbing wrote: > I think it makes sense to be able to store a private key without a passphrase > in > a safe place (as in: an actual safe), so you don't run the risk that you > forgot > the passphrase. Currently, this is not possible Is it impossible straight from RFC 4880 in any defined mode, or is it just a wrong behaviour in GnuPG/Libgcrypt? Empty passphrases are banned in several places in this software: gnupg: agent/protect.c: 1218 (hash_passphrase()) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/protect.c;h=cdb39fd1310dd539b3fa88f55e117a9aeecdb1e9;hb=refs/heads/master#l1218 libgcrypt: cipher/kdf.c: 245 (_gcry_kdf_derive()) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/kdf.c;h=ad5c46efdce696896f60521f8fe856ea102e6950;hb=refs/heads/master#l245 I haven't learned the RFC yet, so any quick tips are very appreciated. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)
TL;DR: Generalization of "Split GPG" concept.
Any comments?
Anybody likes the idea?
Ready to join development or early adoption?
What is this: Concept of flexible solution for usage of private keys
without disclosing them. Key usage is always confirmed by user (as a
form of AnyNumber-factor auth).
What is planned to guard: OpenPGP keys, SSH keys, X.509 client certificates.
Inspiration: Split GPG (https://www.qubes-os.org/doc/split-gpg/),
PGP-smartcards, SSH-smartcards.
Implementation form: portable libraries/toolkit.
Elements:
- keychain server (KS): the process which is accessible via specified
protocols and has access to the unprotected keys, so that it can use them:
--- encrypt/decrypt/sign;
--- create challenge responses;
- keychain key usage client (KUC): the process which makes requests for
key usage;
- keychain confirmation server (KCS): the process conveying User's
decision (approval or rejection) to each key usage request;
The following elements must run in trusted environment (including
trusted physical security system, trusted hypervisor, trusted machine OS);
- keychain server;
- keychain confirmation server.
Keychain key usage client can work in entirely hostile environment.
Keychain usage client (KUC) may be entirely spoofed by attacker, no data
from KUC is trusted and it must be verified by User.
The above restriction is not a show-stopper ("oh, too much restricted
scheme - how to get such trusted environments?"). It is an improvement
comparing to default scheme, which supposes secret keys exposition in
same hostile environment. The point is in decoupling these three
essential entities of key material, key usage agent (gpg-agent,
ssh-agent) and key control (usually underdeveloped in mainstream systems
- you just MAY get asked to enter passphrase if you use it).
This scheme is an improvement comparing to hardware smartcard usage
because it brings flexiblility and fine-grained control to key usage
confirmation procedure.
Q: How confirmation happens?
A: This function is outsourced to plugin system. Different systems would
find different ways as most fit. Used/allowed plugins configuration is
set up in keychain server. It possibly will look similar to Linux PAM.
Q: How to have keychain server data encrypted?
A: As long as KS must actually use the keys in their unencrypted form,
it is required that safety of KS is trusted. If we cannot assume KS
environment trusted, then keys are compromised as soon as they get
loaded in unencrypted form. See http://blog.invisiblethings.org/keys/ "I
proudly use empty passphrases on all of my private keys...". Encryption
of KS data is out of scope of this scheme, but it may be implemented as
the adopter decides, as additional safety measure.
Q: How to ensure unspoofability of confirmation dialog?
A: Confirmation app must run in trusted environment, so this is not
needed. If environment is not trusted, the unspoofability of
confirmation dialog is only one of countless unresonvable security issues.
Q: Which protocols are used to convey key usage dialogs and confirmation
dialogs?
A: The ones that can be considered handy and trusted in specific case.
The following ones are offered for adopters consideration:
- SSH;
- other end-to-end (KUC-KS, KS-KCS, KUC-KCS) encrypted connections:
--- XMPP via TLS chat with PGP or OTR encryption;
--- HTTPS online session with realtime notifications;
--- encrypted VoIP or VVoIP call communication (smart audio
synthesis/recognition software are probably required);
--- confirmation HTTPS link in encrypted email;
- NFC (near-field communication protocol, hardware) - NFC crypto chip
prepares signature which shows approval to KS;
- (bad, use as fallback) SMS, PSTN call;
It should be stated that KC may want to gather more than one approval,
by more than one communication channel (thus we have multi-factor
authorization). Or system may query several confirmation channels in
parallel or serial fashion.
Examples of viable platforms for trusted elements (KC, KCS), review of
potential risks:
- Android device: so-so to bad (depending on whether the system is
fully dedicated, and on system configuration):
--- risk for KC: vendor-provided OS system services tend to spy on user;
--- risk for KC: normally every app has its kernel-guarded storage, but
processes with system privilegee (gained by exploit or by user
permission) may access this data;
--- risk for KCS: potential spoofing of KCS app dialogs;
- Remote sever: bad to so-so to good (depending on whether VPS or owned
and guarded physical machine):
--- risk for any component: remote attack (TODO elaborate, review more
in-depth);
- Pluggable micro-PC with dedicated system (like
http://inversepath.com/usbarmory.html): potentially good, but there's
lack of interactive peripheral for dialog, a gadget like androids
without bloatware would be nice.
- Virtual machines: good, but must be used properly - untrusted env
mustn't be supervising trusted env.
- Different
Re: Why gpg 2.1.9 cannot export secret key without passphrase?
Thanks to everybody for caring about my issue, and for showing that I'm not alone with it. So this already has been reported in https://bugs.gnupg.org/gnupg/issue2070 and has been discussed in https://lists.gnupg.org/pipermail/gnupg-devel/2014-October/028919.html. So it just needs to be patched. Does anybody knows what works well if I am ready to donate (not a ton) and want to have it done soon? P. S. I haven't received 2 of 3 replies to my gmail mailbox, had to go to maillist archive to review the thread. Have this happened to anybody else, is this a known issue? -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Why gpg 2.1.9 cannot export secret key without passphrase?
$ gpg --export-secret-keys (pops a Xorg dialog window from my console, driving me nuts) (i give empty passphrase) (it asks me whether i am sure I want no passphrase) (I say yes) gpg: key : error receiving key from agent: No passphrase given - skipped Why is there such a _policy_? Maybe I am lost and I am using Windows which re-asks everything and still refuses to do what I want? -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
