From marioxcc.MT at yandex.com Fri Sep 1 00:06:14 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 17:06:14 -0500 Subject: please help "No pinentry" In-Reply-To: References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> Message-ID: <96e433f7-064c-3811-fab5-7674c4c03ef7@yandex.com> On 31/08/17 16:36, Bereshka Web and Photo wrote: > it happens all the time, solution is of itself as soon as I ask it on a forum > or like John Robbins said ?My cat, as it turns out, is an excellent debugger, and she has helped me solve a number of nasty bugs when I talked to her about them? :) not exact situation, but little bit similar ) I have heard about that. The premise is that explaining a problem sometimes makes how to solve it evident, especially when explaining that a program does not work. There is even a web page about something like that: . -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From info at bereshka.net Fri Sep 1 00:16:11 2017 From: info at bereshka.net (Bereshka Web and Photo) Date: Thu, 31 Aug 2017 17:16:11 -0500 Subject: please help "No pinentry" In-Reply-To: <96e433f7-064c-3811-fab5-7674c4c03ef7@yandex.com> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> <96e433f7-064c-3811-fab5-7674c4c03ef7@yandex.com> Message-ID: <898043F3-1C6D-4B49-8612-F1E6E55B937F@bereshka.net> haha that?s cool, now it?s clear why ftp client for mac ?yberduck chose that image) > On 31 Aug 2017, at 17:06, Mario Castel?n Castro wrote: > > On 31/08/17 16:36, Bereshka Web and Photo wrote: >> it happens all the time, solution is of itself as soon as I ask it on a forum >> or like John Robbins said ?My cat, as it turns out, is an excellent debugger, and she has helped me solve a number of nasty bugs when I talked to her about them? :) not exact situation, but little bit similar ) > > I have heard about that. The premise is that explaining a problem > sometimes makes how to solve it evident, especially when explaining that > a program does not work. There is even a web page about something like > that: . > > -- > Do not eat animals; respect them as you respect people. > https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From s7r at sky-ip.org Fri Sep 1 00:39:21 2017 From: s7r at sky-ip.org (s7r) Date: Fri, 1 Sep 2017 01:39:21 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: <4754c12a-a1f3-e4cc-eec9-861ea5f0ff37@sky-ip.org> Hi everyone, thanks for everyone's very helpful feedback. See inline. Shawn K. Quinn wrote: > On 08/29/2017 02:14 AM, s7r wrote: >> Hi Phil, >> Thanks - this is indeed _very_ useful for my use case. I don't think the >> second part is a problem since I can particularly request to not set the >> `throw-keyids` option, but let's say metadata becomes a problem at a >> given point and we decide to use this option, can I tell which recipient >> 'should' be able to decrypt a message based only on the encrypted >> message format if the `throw-keyids` option was used? > > No, that's the whole point of throw-keyids. All you're supposed to be > able to tell when using that option, is that none of your keys will > decrypt the message, so it's not for you. > > Ok, understood, last thing: at least can I learn just by looking at the cipher text that `throw-keyids` option was used and choose not to further transmit that message and at least warn the sender that he should double check and confirm one more time for safety reasons? There is a single threat model: I am trying hard to prevent accidental usage in an app where a message encrypted for a different recipient ends up to the wrong person, no matter the recipient that actually gets the ciphertext by mistake has absolutely no real use with it because he won't be able to decrypt it -- the downside and loss is at sender side for thinking the message was sent to someone else and further action is expected. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Fri Sep 1 00:49:08 2017 From: s7r at sky-ip.org (s7r) Date: Fri, 1 Sep 2017 01:49:08 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <46f67f7d-78d2-bb33-c2b0-c9d620625d9c@yandex.com> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> <46f67f7d-78d2-bb33-c2b0-c9d620625d9c@yandex.com> Message-ID: Hello Mario, Robert, Replying to both inline. Mario Castel?n Castro wrote: > On 29/08/17 02:09, s7r wrote: >> I understand that the first one is ECDSA and the second is ECDH, but >> can't I use the same secp256k1 key (if I import it) but in different two >> representations (ECDSA representation for Sign and Certify and ECDH for >> Encrypt)? > >> The subkey might have a different fingerprint because it's a >> different representation of course but this is not the concern, the >> concern is for both to be computed from the same imported private key. > > You can use hash(private_key_1) to seed a cryptographically secure > pseudo-random number generator (E.g.: AES in CTR mode with the seed as > the key), and then use that random stream to generate (private_key_2, > pubic_key_2. > > This is a method applicable in general. The algorithms of private_key_1 > and private_key_2 need not be the same, nor do they need to be defied > over the same curve. > > The only problem is that I do not know of a program to do they key > generation from a user-provided seed. > This will do for my use case. > Please stop talking about "secp256k1 keys". You do not have secp256k1 > keys. You have ExDSA or ECDH keys which are not interchangeable with > each other. I think I asked in a wrong way. I do not necessarily need for both the primary key and the secondary key (key with Encryption capability) to be the same secp256k1 curve / ExDSA key / ECDH key, etc. -- all I need is for them to be reproductible at any time, any where, based on some seed, or sha256 hash of a user-generated password, etc. It's irrelevant if they are totally different keys that work in different ways, the only feature needed is to be able to reproduce them from scratch any time, and be able to decrypt the data. Mario, check this out: https://github.com/Jaxx-io/openpgpjs-secp256k1/blob/master/README_secp256k1.md Generate keypair from bitcoin key: var openpgp = require('openpgp'); var bs58check = require('bs58check'); var wif = 'KyiAchQgMKuXQu89j6k6UVZQj7brK6cM79JfmDvkNXPVW24L1thi'; var buff = bs58check.decode(wif); var privateKey = buff.slice(1, -1); privateKey = openpgp.util.bin2str(privateKey); var options = { curve: 'secp256k1', userId: 'Hamlet ', passphrase: 'To be, or not to be: that is the question', material: { key: privateKey, subkey: privateKey } }; openpgp.generateKeyPair(options).then(function(keypair) { // success var privkey = keypair.privateKeyArmored; var pubkey = keypair.publicKeyArmored; }).catch(function(error) { // failure }); Although I am not sure if how this code solves the primary / secondary subkey problem, I doubt it can create a primary key with Encryption capability because ECDSA doesn't work like this, as Robert clearly explained (thanks again for this). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Fri Sep 1 02:06:04 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 19:06:04 -0500 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> <46f67f7d-78d2-bb33-c2b0-c9d620625d9c@yandex.com> Message-ID: On 31/08/17 17:49, s7r wrote: >> You can use hash(private_key_1) to seed a cryptographically secure >> pseudo-random number generator (E.g.: AES in CTR mode with the seed as >> the key), and then use that random stream to generate (private_key_2, >> pubic_key_2. >> >> This is a method applicable in general. The algorithms of private_key_1 >> and private_key_2 need not be the same, nor do they need to be defied >> over the same curve. >> >> The only problem is that I do not know of a program to do they key >> generation from a user-provided seed. > > This will do for my use case. > >> Please stop talking about "secp256k1 keys". You do not have secp256k1 >> keys. You have ExDSA or ECDH keys which are not interchangeable with >> each other. > > I think I asked in a wrong way. I do not necessarily need for both the > primary key and the secondary key (key with Encryption capability) to be > the same secp256k1 curve / ExDSA key / ECDH key, etc. -- all I need is > for them to be reproductible at any time, any where, based on some seed, > or sha256 hash of a user-generated password, etc. It's irrelevant if > they are totally different keys that work in different ways, the only > feature needed is to be able to reproduce them from scratch any time, > and be able to decrypt the data. You can use the same scheme that I described. The only difference is that you use a hash (say, SHA-256) of the seed provided by the user as the seed of the CSPRNG, instead of the hash of a private key (as I originally described) The only thing that is still missing is software that implements deterministic generation of DSA and DH keys over secp256k1 given a seed. You can either find one already written, write it yourself, or pay somebody to write it for you (possibly as a modification of GNU PG). Note that you will need to know the seed *and* the method of generation so that you can re-generate the key in the future if it becomes necessary. You can store the program used for the key generation in a place where it will remain available in the future, for example, in the same place where you store your backups, or print the source code. The generation program needs not be kept secret. Only the seed needs to be kept secret. > Mario, check this out: > > https://github.com/Jaxx-io/openpgpjs-secp256k1/blob/master/README_secp256k1.md > > Generate keypair from bitcoin key: > var openpgp = require('openpgp'); > var bs58check = require('bs58check'); > > [...] I can not comment on this library. I have never used it nor do I plan to use it. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri Sep 1 15:31:04 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 1 Sep 2017 14:31:04 +0100 Subject: E-mail with deniable authentication In-Reply-To: <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> References: <20170829200052.22DC1C02BE@smtp.hushmail.com> <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> Message-ID: <440c4678-6364-b824-fc64-41be61d15aef@andrewg.com> On 31/08/17 03:35, Mario Castel?n Castro wrote: > Writer and recipient have a Diffie-Hellman key over the same group and > know each other's public key. > > The writer computers the shared secret per the DH algorithm This is the real trick though - the DH algorithm requires two-way synchronisation in advance of sending the payload. This is easy enough with a realtime connection, but much harder with email. Most "modern" communication protocols can implement deniability and forward secrecy relatively easily, because they assume a realtime (or near realtime) connection that allows for cooperative algorithms like DH. These protocols are a form of data-in-motion security, where the sequencing of the data is significant, and the integrity of the data is only valid for the duration of the session. But emails are data-at-rest. Their integrity has to be mantained for an indefinite time, since the correspondents may not be online at the same instance. They are closer (conceptually) to a collection of tiny encrypted disk volumes than to communication streams, even if those volumes are then transferred over data-in-motion-secure channels such as TLS. To take a concrete example, when you download a file over HTTPS, your web browser decrypts the file immediately and throws away the now-useless ciphertext. If you save that file, it's either saved in plaintext, or encrypted again using a completely separate system. By contrast, when your MTA receives a PGP email, it does no decryption on it before saving it to disk (save for whatever the TLS connection requires). If you come back to that mail a year later, you have to decrypt it at the point of reading. In the intervening time, the email has sat in the pristine encrypted form. Real-time syncronisation such as required by DH can't happen when I'm asleep and/or my mail client is turned off. It can't happen if I don't read my emails for a month while I'm on holiday. Now, it is still possible to implement DH over a high-latency connection such as email - however this would either have to involve manual intervention at each stage (e.g. opening an attachment for each step in the DH handshake), or a mail client that was aware of the protocol and parsed the handshake emails both automatically and transparently. Perhaps one could adapt the signal/whisper protocol so that each encrypted message contained part of the handshake for future messages - but you'd have to open your encrypted emails in the correct order and maintain an ever-expanding cryptographic state indefinitely, which itself opens a can of worms. What happens if you read email using multiple clients? What if someone roots your laptop? And as others have pointed out, plausible deniability isn't a panacea. It's only really useful in the case where your adversary must prove their assertions to an independent fourth party beyond reasonable doubt. It might keep you out of jail in a well-functioning democracy, but it won't save you from the mafia, the CIA or Kim Jong Un. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From bernhard.kleine at gmx.net Fri Sep 1 14:33:34 2017 From: bernhard.kleine at gmx.net (Bernhard Kleine) Date: Fri, 1 Sep 2017 14:33:34 +0200 Subject: please help "No pinentry" In-Reply-To: <96e433f7-064c-3811-fab5-7674c4c03ef7@yandex.com> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> <96e433f7-064c-3811-fab5-7674c4c03ef7@yandex.com> Message-ID: Am 01.09.2017 um 00:06 schrieb Mario Castel?n Castro: > On 31/08/17 16:36, Bereshka Web and Photo wrote: >> it happens all the time, solution is of itself as soon as I ask it on a forum >> or like John Robbins said ?My cat, as it turns out, is an excellent debugger, and she has helped me solve a number of nasty bugs when I talked to her about them? :) not exact situation, but little bit similar ) > I have heard about that. The premise is that explaining a problem > sometimes makes how to solve it evident, especially when explaining that > a program does not work. There is even a web page about something like > that: . > Thank you for that, I will buy at least five rubber ducks ASAP. -- spitzhalde9 D-79853 lenzkirch bernhard.kleine at gmx.net www.b-kleine.com, www.urseetal.net - thunderbird mit enigmail GPG schl?ssel: D5257409 fingerprint: 08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Sep 2 14:58:47 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 2 Sep 2017 13:58:47 +0100 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: <5610076832.20170902135847@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tuesday 29 August 2017 at 2:24:18 PM, in , Shawn K. Quinn wrote:- > No, that's the whole point of throw-keyids. All > you're supposed to be > able to tell when using that option, is that none of > your keys will > decrypt the message, so it's not for you. I thought you could also tell how many keys it was encrypted to, from the output of gpg --list-packets. - -- Best regards MFPA I'll tell you what's the matter! This parrot is dead! -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWaqrDF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +i9TAP9wHrrVApzeItibVUOzPGo6dF0Q1xWUdzhl2Gf+Fut6XgEA2DscZI9yyPwi uzNpkEWlyk3Wp863KyXKvSUK3EZR5g2JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWaqrDF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/wZSD/0UrzNDD8KQTwFU1P1YKtQlTM0i 1egLTxx3a4eukon0Cl3H3pniSQNXgtxP8A7BzkNKvWiKT661++WcqB5sQE/Fj9lX O6zMGLfuKypdTXPC69h7i9rRS4D/yawgAtEIr5Fw2Cj4uUEbBBymQlLlTXUGdmyz wDTNWWX1V/bTPl4yjZOnYrkD2sd1D2bOTqF9AnInrjARr1lJHZDztEtgKk9y2P5X JjyI6IQORG6CEoKOraMP3FgK4p5+uFzcpMx7wj7QqgDb80oaRoGLn9eccZKl7OjP ZHGronabhiVQCAvG1YoeAzusXszmhRxbUOXDsvmQ1/vTyU7/sz+exRaNmSCPN1r7 64M8uuxdYAbkSa1fQ+JbXjbb6hfpwrefASFRYy3wWcUfFecNg6suKCypSFJ6QrVj q/tp3O6OB6mDoPFZZKXn+FUy0S7G7PNGp8quIUvc7vNRomPXdvz8zq18nO4HXKsX Pkb5swwBfJkQeXhYGv+wgYCOPDR9+TeK2ZO4csmOUrdqkxsmqgskmjUvrJBiJFuv BDX+uPkr60iwpzECadxMy9n+iD4jYvsrJxJu8PCJVp6g1m2iWfBmZGM0kLGEhuJF uCZf4w6w18WWRgatfuwzRsRvCSVFLWx864fsLugVEu/krJ0upieKYZoP/1rGMh8i H9qMsAgkv9cvWH0T6g== =mygj -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Sep 2 16:58:50 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 2 Sep 2017 10:58:50 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <5610076832.20170902135847@riseup.net> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> <5610076832.20170902135847@riseup.net> Message-ID: > I thought you could also tell how many keys it was encrypted to, from > the output of gpg --list-packets. Nope. You can tell how many subkeys it was encrypted for, but not how many distinct certificates those represent. If one recipient has 10 subkeys and you encrypt to all 10, there will be 10 packets awaiting you... but there's no way to determine these all correspond to one certificate. From stefan.claas at posteo.de Sat Sep 2 17:30:52 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 2 Sep 2017 17:30:52 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <87tw1pd40r.fsf@fsij.org> References: <3xMw342rkHz10Hj@submission01.posteo.de> <87tw1pd40r.fsf@fsij.org> Message-ID: <20170902173052.465549c8@iria.my-fqdn.de> On Thu, 03 Aug 2017 07:00:04 +0900, NIIBE Yutaka wrote: > If someone will make transaction to that address for some amount, I > would resume the development again. :-) As a little proof of concept i converted my sub signing key to a private Bitcoin WIF key and send you some Satoshi. :-) Here you can see that i did it: https://blockchain.info/address/12rY4qgjXbL3h8gCSaJUJMJ9g9TaPtypC4 People who want to check if it was really me, who did the transaction, can do the following: Step 1 : Download my public key from key servers. Step 2 : Do a gpg -k --with-colons --with-key-data "Stefan Claas" Step 3 : When GnuPG list my pub key data look for: sub:u:256:19: and copy the data string after pkd:1:515: Step 4: Visit http://gobittest.appspot.com/Address and paste in step1 the copied data from my pub key and press send. In field 9 you can see the Bitcoin address of my sub signing key. People can omit steps 2 - 3 and use Niibe's script. I however was not able to use the script, because it gave me no output... :-( The Bitcoin address of my public sub signing key matches the address as show in the transaction. :-) Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 246 bytes Desc: Digitale Signatur von OpenPGP URL: From marioxcc.MT at yandex.com Sun Sep 3 04:18:27 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Sat, 2 Sep 2017 21:18:27 -0500 Subject: E-mail with deniable authentication In-Reply-To: <440c4678-6364-b824-fc64-41be61d15aef@andrewg.com> References: <20170829200052.22DC1C02BE@smtp.hushmail.com> <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> <440c4678-6364-b824-fc64-41be61d15aef@andrewg.com> Message-ID: <81db7e7f-6d74-6196-0e82-b4484b04354e@yandex.com> On 01/09/17 08:31, Andrew Gallagher wrote: > On 31/08/17 03:35, Mario Castel?n Castro wrote: >> Writer and recipient have a Diffie-Hellman key over the same group and >> know each other's public key. >> >> The writer computers the shared secret per the DH algorithm > > This is the real trick though - the DH algorithm requires two-way > synchronisation in advance of sending the payload. This is easy enough > with a realtime connection, but much harder with email. Diffie-Hellman may be used interactively, but it is not necessary. See the specification of Diffie-Hellman over an elliptic curve emplyed for *encryption* in OpenPGP as described in RFC 6637 ). There is a summary of the protocol in page 8. Note how it requires no ?two-way synchronization?. As described here, the sender generates an ephemeral key. If the sender uses *his* ECDH key instead of an ephemeral one then the shared secret can be used to derive the key of a MAC algorithm and used for deniable authentication. Obviously there is the requirement that the receiver knows that the key used by the sender really belongs to the sender and not an impersonator. This is a general requirement in public key cryptography also applicable for digital signatures. > And as others have pointed out, plausible deniability isn't a panacea. > It's only really useful in the case where your adversary must prove > their assertions to an independent fourth party beyond reasonable doubt. > It might keep you out of jail in a well-functioning democracy, but it > won't save you from the mafia, the CIA or Kim Jong Un. I am well aware of that. Although deniable encryption is not a panacea it is an improvement. It gives less power to the correspondent to blackmail. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Sep 4 12:58:20 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Sep 2017 12:58:20 +0200 Subject: Financial Results 2016 Message-ID: <87vakyafxv.fsf@wheatstone.g10code.de> Hi! find below a plain text versions of my latest blog entry. If you have any questions please reply to this mailing list. Salam-Shalom, Werner ================= Copy of : 1 Financial Results for 2016 ???????????????????????????? Having prepared the annual accounts for g10^code GmbH, the legal entity employing some of the GnuPG hackers, I can now share a financial report. Please read on if you are interested in how we earned and spent the money from donations and paid projects. 1.1 Balance Sheet as of 2016-12-31 ?????????????????????????????????? Let us start by looking at the balance sheet, which describes our financial status. The following table shows the actual [balance sheet] with a few accounts pooled up. Note that for display purposes all values have been rounded to a full Euro, and thus there are minor mismatches in the Sums row. ?????????????????????????????????????????????????????????????????? Asset (2015) Liability (2015) ?????????????????????????????????????????????????????????????????? Tangible assets 4722 (3880) Stock of goods 0 (0) Cash balance 154 (360) Bank balance KSD 282163 (207453) PayPal and others balance 7001 (3842) Accounts receivable 10702 (4774) Accounts receivable other 150 (497) Common capital stock 25000 (25000) Loss carried forward 0 (0) Profit carried forward 126688 (11338) Net profit 98958 (115350) Shareholder loans 0 (0) Accounts payable 323 (0) Accounts payable other 53850 (27974) GnuPG development fund 72 (72) Provision for taxes 0 (41070) ?????????????????????????????????????????????????????????????????? Sums 304891 (220804) 304891 (220804) ?????????????????????????????????????????????????????????????????? The /Bank balance KSD/ is the money that we had at the end of the year in our accounts at the local savings bank. The /PayPal/ row gives the amount of money in the PayPal account and as several prepaid accounts. From the /Common capital stock/ of 25000 Euro 50% are held by Walter Koch and 50% by Werner Koch, the owners of g10^code. The /Net profit/ gained in 2015 is added to /Profit carried forward/. The /Accounts payable other/ is my profit sharing bonus of 24739 and VAT payable for the last quarter. The /GnuPG development fund/ is the rest of a campaign which collected prize money for the GnuPG logo. [balance sheet] file:data/g10code-bilanz-2016-pub.pdf 1.2 Profit and Loss from 2016-01-01 to 2016-12-31 ????????????????????????????????????????????????? Now let us see how much money we earned and how we spent it. The following table shows the actual [profit and loss sheet] with a few accounts pooled up. As above, the values have again been rounded to the nearest Euro. ?????????????????????????????????????????????????????????????? Debit (2015) Credit (2015) ?????????????????????????????????????????????????????????????? Revenues 351689 (57251) Revenues from donations 9342 (283538) Revenues other 3607 (218) Salaries 133776 (108719) Social insurance 29756 (18060) Contractors 44700 (33165) Write-offs 1571 (1532) Connectivity and hosting 2259 (2012) Rents 2769 (2681) Interest expenses 1 (550) Travel expenses 2359 (3499) Other expenses 6064 (5169) Donations 1873 (5100) Taxes 40551 (45171) Net profit 98958 (115350) ?????????????????????????????????????????????????????????????? Sums 364639 (341007) 364639 (341007) ?????????????????????????????????????????????????????????????? The major /Revenues/ items are grants from the Linux Foundation (54,219 ?), Facebook (44,715 ?), Stripe (47,824 ?), and from these paid projects: Gpg4VS-NfD (79,800 ?), Gpg4All (48,000 ?), and EasyGPG (65,000 ?). The /Rents/ are for the room used as an office in my house. /Other expenses/ sums up money spent for magazines, power, office supplies, advertising, conference fees, legal costs, etc. Donations have been given to [Netzpolitik.org], [Freundeskreis f?r Fl?chtlinge in Erkrath], [Wikimedia], and the [Freie Software Freunde]. As with almost all software development companies, the majority of expenses are staff costs. Not counting taxes, which depend on the annual profit, we had total costs of 225,000 ? with 207,000 ? spent on /Salaries/, /Social insurance/, and /Contractors/. My share of this were 47,400 ? regular salary (of which I need to pay social insurances fully myself) plus a profit sharing bonus of 24,700 ?. We made quite some profit last years due to the good revenue situation and because one of our employees substantially reduced his working hours to finish his PhD. [profit and loss sheet] file:data/g10code-bilanz-2016-pub.pdf [Netzpolitik.org] https://netzpolitik.org [Freundeskreis f?r Fl?chtlinge in Erkrath] http://www.freundeskreis-fluechtlinge-erkrath.de/ [Wikimedia] https://wikimedia.de [Freie Software Freunde] https://freie-software.de -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alex at nitrokey.com Mon Sep 4 19:02:13 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Mon, 4 Sep 2017 19:02:13 +0200 Subject: Do not cache smart card PIN In-Reply-To: <855210ce-5265-2dbc-be7e-c77c376d4eaf@cern.ch> References: <855210ce-5265-2dbc-be7e-c77c376d4eaf@cern.ch> Message-ID: Hello Justin, this is not possible right now. I did a similar feature request here https://dev.gnupg.org/T3362 Maybe you have something to add. Kind regards Alex On 08/28/2017 03:12 AM, Justin Chiu wrote: > Hi, > > Is it possible to instruct a smart card to not cache its PIN or have > GnuPG forcibly clear the PIN cache? > > My understanding is that the PIN is cached internally [1] unless if you > enable "forcesig" (which only applies to signing operations). If this > caching by the smart card cannot be turned off for encryption and > authentication as well, then perhaps it is possible to configure GnuPG > to clear the smart card's PIN cache after every operation? > > Thanks, > Justin > > [1] https://lists.gnupg.org/pipermail/gnupg-users/2006-September/029321.html > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.horne at redbone.co.nz Mon Sep 4 00:42:40 2017 From: dan.horne at redbone.co.nz (Dan Horne) Date: Mon, 4 Sep 2017 10:42:40 +1200 Subject: "Insecure memory" (yes setuid set) and "get_passphrase failed" Message-ID: Hi. I'm trying to get GnuPG working on Solaris 10 Our Unix administrator installed the CSW package. I'm trying to create my key: $ gpg2 --gen-key However at the time it comes to generate the secret key I get: You need a Passphrase to protect your secret key. Warning: using insecure memory! gpg-agent[10073]: command get_passphrase failed: End of file gpg: problem with the agent: End of file gpg: Key generation canceled. Regarding the warning, the recommended response I found via Internet search was: # chmod u+s /path/to/gpg This was done, but didn't affect the warning: $ ls -l /opt/csw/bin/gpg2 -r-sr-xr-x 25 root bin 12252 Jul 25 2016 /opt/csw/bin/gpg2 Regarding the passphrase, I've made sure that pinentry is in my path: $ which pinentry /opt/csw/bin/pinentry Which is a symbolic link to pinentry-curses $ ls -l /opt/csw/bin/pinentry-curses -rwxr-xr-x 1 root bin 58004 Jul 11 2011 /opt/csw/bin/pinentry-curses It still doesn't work After a bit more Googling, I tried adding the following to my gpg.conf file, but it caused a syntax error: pinentry-program /opt/csw/bin/pinentry-curses Any advice appreciated Thanks Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From marioxcc.MT at yandex.com Tue Sep 5 00:58:35 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Mon, 4 Sep 2017 17:58:35 -0500 Subject: Documentation of trust model Message-ID: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> Hello. Are the trust models ?classical? and ?pgp? as implemented in GNU PG documented anywhere? In the manual I can only find this for ?pgp?: ?This is the Web of Trust combined with trust signatures as used in PGP 5.x and later. This is the default trust model when creating a new trust database.?, which is a very unsatisfactory description. The situation is the same for ?classical?. Regards. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Tue Sep 5 02:35:51 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Mon, 4 Sep 2017 19:35:51 -0500 Subject: Documentation of trust model In-Reply-To: <2c7eb0d0-3500-5dbd-956f-cd9773324e4f@gmail.com> References: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> <2c7eb0d0-3500-5dbd-956f-cd9773324e4f@gmail.com> Message-ID: <9fac44b8-275d-767a-5a46-93dcdbbeb155@yandex.com> Hello. It appears that you forgot to reply to the mailing list. On 04/09/17 19:29, Lou Wynn wrote: > The PGP standard has more details in Section 5.2.3.13 Trust Signature: [?]> > Do you have specific issues or questions to discuss about the Web of > Trust model? I have read this section of RFC 4880 already. It does not answer my original question. The trust model takes signatures and user-assigned trust levels and outputs validity. Where is this documented for the ?pgp? and ?classic? models of GNU PG? I can not find anything about it in RFC 4880 (note that the section that you linked does not describe ?pgp?, ?classic? nor any other any trust model). Thanks. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Tue Sep 5 02:45:55 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Mon, 4 Sep 2017 19:45:55 -0500 Subject: "Insecure memory" (yes setuid set) and "get_passphrase failed" In-Reply-To: References: Message-ID: <72140782-c05a-dc3a-b6f8-d313d4d4df6d@yandex.com> On 03/09/17 17:42, Dan Horne wrote: > Warning: using insecure memory! > gpg-agent[10073]: command get_passphrase failed: End of file > gpg: problem with the agent: End of file > gpg: Key generation canceled. There seems to be 2 different problems here: * That gpg (or gpg-agent) fail when calling pinentry. (the ?get_passphrase? fail. * That memory pages can not be locked (?using insecure memory!?). However, I do not know how to solve either. My understanding is that ?insecury memory? means simply that gpg can not lock memory pages so as to reduce the probability that they are written to swap. This is only a security concern if an attacker can read the raw disk device. > Regarding the warning, the recommended response I found via Internet search > was: > > # chmod u+s /path/to/gpg > > This was done, but didn't affect the warning: Are you sure that this is required in Solaris? At least in Debian GNU/Linux there is no need to setuid the gpg binary to root. Root setuid programs are a security problem. If an attacker can get control of this program, he can operate with root privileges. Look for what the requirement for locking pages are in the Solaris documentation. > After a bit more Googling, I tried adding the following to my gpg.conf > file, but it caused a syntax error: > > pinentry-program /opt/csw/bin/pinentry-curses ?pinentry-program? is an option of gpg-agent, not gpg. If you want to specify this option, you must put it in ?$HOME/.gnupg/gpg-agent.conf?. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Tue Sep 5 05:40:23 2017 From: gnupg at raf.org (gnupg at raf.org) Date: Tue, 5 Sep 2017 13:40:23 +1000 Subject: "Insecure memory" (yes setuid set) and "get_passphrase failed" In-Reply-To: <72140782-c05a-dc3a-b6f8-d313d4d4df6d@yandex.com> References: <72140782-c05a-dc3a-b6f8-d313d4d4df6d@yandex.com> Message-ID: <20170905034022.GB27527@raf.org> Mario Castel?n Castro wrote: > On 03/09/17 17:42, Dan Horne wrote: > > Warning: using insecure memory! > > gpg-agent[10073]: command get_passphrase failed: End of file > > gpg: problem with the agent: End of file > > gpg: Key generation canceled. > > There seems to be 2 different problems here: > > * That gpg (or gpg-agent) fail when calling pinentry. (the > ?get_passphrase? fail. > > * That memory pages can not be locked (?using insecure memory!?). > > However, I do not know how to solve either. > > My understanding is that ?insecury memory? means simply that gpg can not > lock memory pages so as to reduce the probability that they are written > to swap. This is only a security concern if an attacker can read the raw > disk device. > > > Regarding the warning, the recommended response I found via Internet search > > was: > > > > # chmod u+s /path/to/gpg > > > > This was done, but didn't affect the warning: > > Are you sure that this is required in Solaris? At least in Debian > GNU/Linux there is no need to setuid the gpg binary to root. Root setuid > programs are a security problem. If an attacker can get control of this > program, he can operate with root privileges. Root privileges are necessary on old operating systems like Solaris 10 (not sure about 11) and Linux-2.6.8 and earlier in order to lock pages in memory. It's not needed in modern OSs (at least not in modern Linux). Was gpg successfully changed to setuid root? That should have made the warning go away (if it was gpg rather than pinentry or gpg-agent producing the warning). But's it's only a warning anyway. The pinentry problem is the important one to fix. > Look for what the requirement for locking pages are in the Solaris > documentation. > > > After a bit more Googling, I tried adding the following to my gpg.conf > > file, but it caused a syntax error: > > > > pinentry-program /opt/csw/bin/pinentry-curses > > ?pinentry-program? is an option of gpg-agent, not gpg. If you want to > specify this option, you must put it in ?$HOME/.gnupg/gpg-agent.conf?. > > -- > Do not eat animals; respect them as you respect people. > https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Tue Sep 5 09:06:22 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Sep 2017 09:06:22 +0200 Subject: "Insecure memory" (yes setuid set) and "get_passphrase failed" In-Reply-To: <72140782-c05a-dc3a-b6f8-d313d4d4df6d@yandex.com> ("Mario =?utf-8?Q?Castel=C3=A1n?= Castro"'s message of "Mon, 4 Sep 2017 19:45:55 -0500") References: <72140782-c05a-dc3a-b6f8-d313d4d4df6d@yandex.com> Message-ID: <87ingx8w0h.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2017 02:45, marioxcc.MT at yandex.com said: > Are you sure that this is required in Solaris? At least in Debian > GNU/Linux there is no need to setuid the gpg binary to root. Root setuid > programs are a security problem. If an attacker can get control of this > program, he can operate with root privileges. Actually gpg drops suid right after initializing memory and has several checks to make sure that it has been dropped. Any, I would ignore that problem for now. If the diagnostics is annoying no-secmem-warning in gpg.conf can be used. For the other problem I noticed that the gpg binary is pretty small and thus I assume gpg is some kind of wrapper script. Mote information on the installation is needed, in particular the gnupg versions and how it was build. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Sep 5 10:58:45 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 5 Sep 2017 10:58:45 +0200 Subject: Documentation of trust model In-Reply-To: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> References: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> Message-ID: <526278ec-b799-6384-8716-5f36b4bfd08a@incenp.org> Hello, On 09/05/2017 12:58 AM, Mario Castel?n Castro wrote: > Are the trust models ?classical? and ?pgp? as implemented in GNU PG > documented anywhere? As far as I know, not really. Certainly not in the OpenPGP RFCs. RFC4880 and its predecessors never defined any trust model, they only defined some ?tools? that can be used by a trust model (such as the different certification types or the trust signature packet). But the trust models themselves are left to the implementors. I seem to remember that someone on the IETF OpenPGP mailing-list evoked the idea of writing a complementary, informational RFC to describe routinely used trust models, but I don?t think it has ever been done. As for the ?classic? and ?pgp? trust models as used by GnuPG, very briefly: In the ?classic? trust model, GnuPG determines whether a given non-expired, non-revoked OpenPGP public key is valid by looking at the signatures (?certifications?) carried by that key. The key is fully valid, marginally valid, or of unknown validity depending on the number of certifications emitted by trusted keys in the user?s keyring. The key aspect of the ?classic? trust model is that it only determines the *validity* of a key. *Ownertrust* (the value associated with a key and which indicates if certifications emitted by that key are taken into account) is always manually set by the user. (This is something that is frequently misunderstood.) A ?classic? signature only means something like ?I certify that this key belongs to its stated owner?. By contrast, in the ?pgp? trust model, users can emit ?trust signatures?, which carry both validity and ownertrust information. A trust signature means ?I certify that this key belongs to its stated owner *and* I regard its owner as trustworthy.? To illustrate the difference, let?s consider the following (from the point of view of Alice): a) Alice signs Bob?s key and fully trusts Bob; b) Bob signs Carol?s key and fully trusts Carol; c) Carol signs David?s key. In the ?classic? trust model, only Bob?s and Carol?s key are valid (Bob?s key because it is signed by Alice?s own key, and Carol?s key because it is signed by Bob?s key, which Alice fully trusts). But David?s key is of unknown validity because Alice never assigned an ownertrust value to Carol?s key. The fact that Bob fully trusts Carol is irrelevant; actually, Alice does not even know that Bob fully trusts Carol. In the ?pgp? trust model, and assuming that Alice and Bob emitted trust signatures instead of simple signatures (I ignore, for simplicity?s sake, the notion of trust depth and the possibility to assign marginal ownertrust), Carol?s key has full ownertrust in the eyes of Alice even though Alice never explicity assigned an ownertrust value to it. Consequently, David?s key is valid. Obviously there would be much more to describe, but I hope the above helps a little bit. For what it?s worth, I wrote a document attempting to describe more thoroughly the various trust models used by GnuPG (including the new TOFU models) [1]. Unfortunately, it?s in French. :( I wanted to write an English version but never found the time nor the motivation? Damien [1] https://incenp.org/dvlpt/docs/confiance-openpgp.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Sep 5 11:00:21 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 5 Sep 2017 11:00:21 +0200 Subject: Documentation of trust model In-Reply-To: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> References: <551e4ffe-9253-d2da-2e97-a605563818b4@yandex.com> Message-ID: On 05/09/17 00:58, Mario Castel?n Castro wrote: > Are the trust models ?classical? and ?pgp? as implemented in GNU PG > documented anywhere? The GNU Privacy Handbook has a good explanation of it: That is to say, it explains the Web of Trust. It doesn't seem to even mention trust signatures. The difference between "classical" and "pgp" is, as the man page does say, that "pgp" includes trust signatures.[1] But in practice trust signatures are only used in such limited settings that these situations probably have their own prescriptive practices and documentation. At least, that's what I personally expect. So it's not that useful to document trust signatures in detail. It could perhaps be wise to mention this rationale for not explaining them. > In the manual I can only find this for ?pgp?: ?This > is the Web of Trust combined with trust signatures as used in PGP 5.x > and later. This is the default trust model when creating a new trust > database.?, which is a very unsatisfactory description. The man and info pages are more reference manuals than user manuals; they list all options, but don't explain what is all involved in using GnuPG in a sane manner in practice. While there are certainly ways to improve the man and info pages to be more useful, I think a whole description of how to properly use the Web of Trust would be out of scope. HTH, Peter. [1] Although it is actually phrased ambiguously: it is not clear whether the relative clause "as used in PGP 5.x and later" is a restrictive or non-restrictive relative clause. Is it: 1. The Web of Trust combined with trust signatures, in the manner they are used in PGP 5.x? So this Web of Trust is a different Web of Trust than the one of PGP 2.x. 2. The Web of Trust combined with trust signatures, which is a model that was introduced in PGP 5.x? It actually is 2: the Web of Trust is the same as in PGP 2.x, but another trust mechanism was added: trust signatures. So perhaps the sentence should be rephrased as: This is the Web of Trust combined with trust signatures, which is the model used in PGP 5.x and later. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Tue Sep 5 14:58:52 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Tue, 5 Sep 2017 07:58:52 -0500 Subject: E-mail with deniable authentication In-Reply-To: <7fb39617-2cad-e79f-a923-cc8846752553@twopif.net> References: <20170829200052.22DC1C02BE@smtp.hushmail.com> <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> <440c4678-6364-b824-fc64-41be61d15aef@andrewg.com> <81db7e7f-6d74-6196-0e82-b4484b04354e@yandex.com> <7fb39617-2cad-e79f-a923-cc8846752553@twopif.net> Message-ID: <69c89fe9-2d14-c554-e474-e3883aeeca49@yandex.com> Good point. Note: You forgot to reply to list. On 02/09/17 22:11, Lachlan Gunn wrote: > Le 2017-09-03 ? 11:48, Mario Castel?n Castro a ?crit : >> I am well aware of that. Although deniable encryption is not a panacea >> it is an improvement. It gives less power to the correspondent to blackmail. > > I would also add that lots of servers will put a DKIM signature onto the > email, thus showing who sent the ciphertext to whom. Obviously this > isn't as secure as a personal digital signature, since anyone who can > get into your email account can send email in your name, but it does > mean that email nowdays is at least somewhat non-repudiable. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marfig at gmx.com Tue Sep 5 22:58:44 2017 From: marfig at gmx.com (Mario Figueiredo) Date: Tue, 5 Sep 2017 21:58:44 +0100 Subject: Configuring dirmngr Message-ID: <20170905215844.324d29fe@Archbox> I'm having trouble configuring dirmngr to use a default keyserver. The current configuration file at .gnupg/dirmngr.conf contains this single line: keyserver hkp://pgp.mit.edu However trying to use --recv-keys always fails: $ gpg --recv-keys 0x194b631ab2da2888 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 I can only make it work by using the deprecated method of explicitly naming the keyserver: $ gpg --keyserver hkp://pgp.mit.edu --recv-keys 0x194b631ab2da2888 key 194B631AB2DA2888: 32 signatures not checked due to missing keys gpg: key 194B631AB2DA2888: "Andreas R?nnquist " not changed gpg: Total number processed: 1 gpg: unchanged: 1 What am I doing wrong in the dirmngr configuration file? -- Sinceramente / Best regards, M?rio J.G.P. Figueiredo Luanda, Angola (email) marfig at gmx.com (alt) krugar at openmailbox.org (phone) +244 934 535 121 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From alci at mecadu.org Wed Sep 6 11:30:02 2017 From: alci at mecadu.org (Franck Routier (perso)) Date: Wed, 6 Sep 2017 11:30:02 +0200 Subject: Poldi example usage of gpg-connect-agent fails Message-ID: <7f5736e1-074e-40f0-9579-e5ad8cc137a1@mecadu.org> Hi, I am trying to get into smartcard usage, and would want to allow Authentication on my system with an OpenPGP Card (FSFE Fellowship smartcard). As I understand it (I might be wrong), the right pam module is Poldi. According to the Texinfo page (info poldi), current version is 0.4, and lacks the previous poldi-ctrl utility, so I have to create some config file manually. Specifically, here is the example that is given: First, the system administrator has to associate the user moritz with the card's serial number: $ echo "D2760001240101010001000006550000 moritz" >> /etc/poldi/localdb/users Second, the system administrator needs to write the card's key into a card-specific key file. Therefore he inserts Moritz' smartcard and executes: $ gpg-connect-agent "/datafile /etc/poldi/localdb/keys/D2760001240101010001000006550000" "SCD READKEY --advanced OPENPGP.3" /bye My problem is that the command gpg-connect-agent "/datafile myfile" "SCD READKEY --advanced OPENPGP.3" /bye returns an error: ERR 100663414 Identifiant incorrect Can anyone help me on this ? (or is there a better way to authenticate using an OpenPGP smartcard ?) (or is it just a bad idea ?) Thanks in advance Franck From shaarang.tyagi at gmail.com Wed Sep 6 06:37:01 2017 From: shaarang.tyagi at gmail.com (shaarang tyagi) Date: Wed, 6 Sep 2017 10:07:01 +0530 Subject: How to encrypt using public certificate\key Message-ID: Hello, I have a situation where I need to use GnuPG from command line and encrypt a file using a public certificate or PEM public key, please note that I will not have the private key at this point and encryption needs to be done only using public key. Let me know if this is possible or not. Best Regards, Shaarang -------------- next part -------------- An HTML attachment was scrubbed... URL: From marioxcc.MT at yandex.com Wed Sep 6 15:26:09 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 6 Sep 2017 08:26:09 -0500 Subject: How to encrypt using public certificate\key In-Reply-To: References: Message-ID: <59724bc4-4a34-d0bd-c43b-7eaa22eb8d73@yandex.com> On 05/09/17 23:37, shaarang tyagi wrote: > I have a situation where I need to use GnuPG from command line and encrypt > a file using a public certificate or PEM public key, please note that I > will not have the private key at this point and encryption needs to be done > only using public key. > > Let me know if this is possible or not. You can use the ?gpgsm? to operate over X.509 certificates (this covers your use case). -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Sep 6 15:29:52 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Sep 2017 15:29:52 +0200 Subject: How to encrypt using public certificate\key In-Reply-To: References: Message-ID: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> On 06/09/17 06:37, shaarang tyagi wrote: > I have a situation where I need to use GnuPG from command line and > encrypt a file using a public certificate or PEM public key First of all, are we talking about OpenPGP, S/MIME, or both? I notice you say PEM public key, which implies the X.509 and S/MIME ecosystem, but GnuPG is more commonly used for the OpenPGP ecosystem. The "gpgsm" binary of GnuPG does do S/MIME, though. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bkapito at yahoo.com Wed Sep 6 14:56:58 2017 From: bkapito at yahoo.com (BRUCE KAPITO) Date: Wed, 6 Sep 2017 12:56:58 +0000 (UTC) Subject: How to encrypt using public certificate\key In-Reply-To: References: Message-ID: <1299815487.4097949.1504702618505@mail.yahoo.com> Can you please cease and desist sending me emails. ?I did not sign up for this On Wednesday, September 6, 2017, 8:33:40 AM EDT, shaarang tyagi wrote: Hello, I have a situation where I need to use GnuPG from command line and encrypt a file using a public certificate or PEM public key, please note that I will not have the private key at this point and encryption needs to be done only using public key. Let me know if this is possible or not. Best Regards,Shaarang_______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Wed Sep 6 16:28:46 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Sep 2017 16:28:46 +0200 Subject: Unsubscriing (was: How to encrypt using public certificate\key) In-Reply-To: <1299815487.4097949.1504702618505@mail.yahoo.com> References: <1299815487.4097949.1504702618505@mail.yahoo.com> Message-ID: On 06/09/17 14:56, BRUCE KAPITO via Gnupg-users wrote: > Can you please cease and desist sending me emails. I did not sign up > for this *Someone* managed to subscribe your e-mail address, which is usually not possible without being able to read mail addressed to your e-mail address (and thus should usually just be you). Anyway: you're asking your peers, who cannot help you. You can help yourself by following the link at the bottom of every mail you receive through the mailing list: > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Note you will need to use the exact e-mail address that was subscribed. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Sep 6 16:34:58 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Sep 2017 16:34:58 +0200 Subject: How to encrypt using public certificate\key In-Reply-To: References: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> Message-ID: <9cead936-7ad9-daac-71d5-e13d032f5beb@digitalbrains.com> Hello Shaarang, On 06/09/17 16:13, shaarang tyagi wrote: > I am talking about OpenPGP, i want to encrypt a file that follows > openpgp standard [...] > I was encrypting by selecting a certificate which i had imported , i had > also imported its root ca, so certificate chain was fully there but > encryption failed. "Root CA", "certificate chain" and your earlier "PEM public key" tell me you are using certificates from the Cryptographic Message Syntax ecosystem (to which S/MIME belongs also). These are not OpenPGP certificates/public keys, and it is simply impossible to encrypt an OpenPGP message to them. You will need to ask your peer for their OpenPGP certificate (also called "public key") before you can send them an OpenPGP encrypted message. They are two completely separate and incompatible ecosystems. It just so happens that GnuPG does have some support for CMS as well, through the gpgsm binary. More about starting with OpenPGP is in The GNU Privacy Handbook[1]. That guide is pretty outdated, though, so don't take its word for gospel. HTH, Peter. [1] -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Sep 6 19:59:43 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Sep 2017 13:59:43 -0400 Subject: Configuring dirmngr In-Reply-To: <20170905215844.324d29fe@Archbox> References: <20170905215844.324d29fe@Archbox> Message-ID: <87lglrbtdc.fsf@fifthhorseman.net> On Tue 2017-09-05 21:58:44 +0100, Mario Figueiredo wrote: > I'm having trouble configuring dirmngr to use a default keyserver. > > The current configuration file at .gnupg/dirmngr.conf contains this > single line: > > keyserver hkp://pgp.mit.edu > > However trying to use --recv-keys always fails: > > $ gpg --recv-keys 0x194b631ab2da2888 > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 What version of gnupg are you running? after making that configuration file, have you explicitly restarted dirmngr? the simplest way is: gpgconf --kill dirmngr then subsequent uses of gpg should automatically spawn a new dirmngr, which will pick up the new configuration. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From marfig at gmx.com Wed Sep 6 20:37:27 2017 From: marfig at gmx.com (Mario Figueiredo) Date: Wed, 6 Sep 2017 19:37:27 +0100 Subject: Configuring dirmngr In-Reply-To: <87lglrbtdc.fsf@fifthhorseman.net> References: <20170905215844.324d29fe@Archbox> <87lglrbtdc.fsf@fifthhorseman.net> Message-ID: <20170906193727.7487149e@Archbox> On Wed, 06 Sep 2017 13:59:43 -0400 Daniel Kahn Gillmor wrote: > after making that configuration file, have you explicitly restarted > dirmngr? the simplest way is: > > gpgconf --kill dirmngr > Thank you, Daniel. There was a problem with how I was restarting dirmngr on my script. You post helped identify it. And problem is solved. -- Sinceramente / Best regards, M?rio J.G.P. Figueiredo Luanda, Angola (email) marfig at gmx.com (alt) krugar at openmailbox.org (phone) +244 934 535 121 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From shaarang.tyagi at gmail.com Wed Sep 6 16:13:08 2017 From: shaarang.tyagi at gmail.com (shaarang tyagi) Date: Wed, 6 Sep 2017 19:43:08 +0530 Subject: How to encrypt using public certificate\key In-Reply-To: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> References: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> Message-ID: Hello Peter, I am talking about OpenPGP, i want to encrypt a file that follows openpgp standard so but when i tried with the windows version of Gnupg , i was getting an error "configuration not correct" (the error was more or less similar) . I was encrypting by selecting a certificate which i had imported , i had also imported its root ca, so certificate chain was fully there but encryption failed. Also my certificate does not show up in "openpgp certificates" list , so i am wondering that maybe the problem is that there is some specific "type" of certificate is required, although my certificate has "file encryption" present in its type! Best Regards, Shaarang Show quoted text On Sep 6, 2017 6:59 PM, "Peter Lebbing" wrote: > On 06/09/17 06:37, shaarang tyagi wrote: > > I have a situation where I need to use GnuPG from command line and > > encrypt a file using a public certificate or PEM public key > > First of all, are we talking about OpenPGP, S/MIME, or both? I notice > you say PEM public key, which implies the X.509 and S/MIME ecosystem, > but GnuPG is more commonly used for the OpenPGP ecosystem. The "gpgsm" > binary of GnuPG does do S/MIME, though. > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaarang.tyagi at gmail.com Wed Sep 6 16:55:30 2017 From: shaarang.tyagi at gmail.com (shaarang tyagi) Date: Wed, 6 Sep 2017 20:25:30 +0530 Subject: How to encrypt using public certificate\key In-Reply-To: References: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> <9cead936-7ad9-daac-71d5-e13d032f5beb@digitalbrains.com> Message-ID: Hello Peter, Thanks a lot to you for clarifying this in a paragraph otherwise i would have to read a whole lot of things to understand that i am trying to connect 2 totally differet things! I will go through the pdf and may have more question(s). Thanks again! Shaarang On Sep 6, 2017 8:05 PM, "Peter Lebbing" wrote: Hello Shaarang, On 06/09/17 16:13, shaarang tyagi wrote: > I am talking about OpenPGP, i want to encrypt a file that follows > openpgp standard [...] > I was encrypting by selecting a certificate which i had imported , i had > also imported its root ca, so certificate chain was fully there but > encryption failed. "Root CA", "certificate chain" and your earlier "PEM public key" tell me you are using certificates from the Cryptographic Message Syntax ecosystem (to which S/MIME belongs also). These are not OpenPGP certificates/public keys, and it is simply impossible to encrypt an OpenPGP message to them. You will need to ask your peer for their OpenPGP certificate (also called "public key") before you can send them an OpenPGP encrypted message. They are two completely separate and incompatible ecosystems. It just so happens that GnuPG does have some support for CMS as well, through the gpgsm binary. More about starting with OpenPGP is in The GNU Privacy Handbook[1]. That guide is pretty outdated, though, so don't take its word for gospel. HTH, Peter. [1] -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaarang.tyagi at gmail.com Thu Sep 7 12:58:16 2017 From: shaarang.tyagi at gmail.com (shaarang tyagi) Date: Thu, 7 Sep 2017 16:28:16 +0530 Subject: How to encrypt using public certificate\key In-Reply-To: References: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> <9cead936-7ad9-daac-71d5-e13d032f5beb@digitalbrains.com> Message-ID: Hello Peter, I am trying to understand the encryption process and the all the input that is required to perform encryption. So according to this RFC, section 2.1: https://tools.ietf.org/html/rfc4880#section-2.1 There can be 2 sources for encryption key, either a session key(generated randomly) or a shared pass phrase (key is derived from this phrase) ? So there is a command i found somewhere , to use with command line GnuPG, to do encryption: gpg -e -u "Sender User Name" -r "Receiver User Name" somefile Which method does this command uses exactly? It does message encryption with a given username's certificate's pub key?(Is this a third method which is not mentioned in that RFC ) ? Also, Where can i find all the commands for all the possibilities using different key sources? Best Regards, Shaarang On Wed, Sep 6, 2017 at 8:25 PM, shaarang tyagi wrote: > Hello Peter, > > Thanks a lot to you for clarifying this in a paragraph otherwise i would > have to read a whole lot of things to understand that i am trying to > connect 2 totally differet things! > I will go through the pdf and may have more question(s). > > Thanks again! > Shaarang > > On Sep 6, 2017 8:05 PM, "Peter Lebbing" wrote: > > Hello Shaarang, > > On 06/09/17 16:13, shaarang tyagi wrote: > > I am talking about OpenPGP, i want to encrypt a file that follows > > openpgp standard [...] > > > I was encrypting by selecting a certificate which i had imported , i had > > also imported its root ca, so certificate chain was fully there but > > encryption failed. > > "Root CA", "certificate chain" and your earlier "PEM public key" tell me > you are using certificates from the Cryptographic Message Syntax > ecosystem (to which S/MIME belongs also). These are not OpenPGP > certificates/public keys, and it is simply impossible to encrypt an > OpenPGP message to them. You will need to ask your peer for their > OpenPGP certificate (also called "public key") before you can send them > an OpenPGP encrypted message. > > They are two completely separate and incompatible ecosystems. It just so > happens that GnuPG does have some support for CMS as well, through the > gpgsm binary. > > More about starting with OpenPGP is in The GNU Privacy Handbook[1]. That > guide is pretty outdated, though, so don't take its word for gospel. > > HTH, > > Peter. > > [1] > > -- > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lwn at anarc.at Thu Sep 7 19:27:48 2017 From: lwn at anarc.at (=?utf-8?Q?Antoine_Beaupr=C3=A9?=) Date: Thu, 07 Sep 2017 13:27:48 -0400 Subject: benchmarking security tokens speed In-Reply-To: <87pobjcm2k.fsf@curie.anarc.at> References: <87pobjcm2k.fsf@curie.anarc.at> Message-ID: <87mv66ju5n.fsf@curie.anarc.at> On Sat Aug 26 08:34:25 UTC 2017, Szczepan Zalega | Nitrokey wrote: > Hi! Hi! [note that I didn't see your reply because you didn't add me in CC - I forgot to mention i wasn't registered to the mailing lists... ] > Nice initiative! It is good you have a script already. The more it is > automated the better. > To make the tests reproducible please give environment details: OS name, > bits and version, GPG version and from hardware side firmware versions > of used devices. Yeah, here are the details: * Debian 9 ("stretch"/stable) amd64 * Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz * GnuPG 2.1.18-6 (from the stable Debian package) * Nitrokey PRO 0.8 (latest) * FST-01, running Gnuk version 1.2.5 (latest) * Yubikey NEO 3.4.3 (not upgradable?) * Yubikey 4 4.2.6 (not upgradable?) Good enough? :) > I would also remove the `pv` from pipeline since it does its own > buffering and could influence the test results. The tests should be done > on ramdisk (/dev/shm etc) to exclude disk access sharing with OS - with > so small times this is a necessity. I rewrote the shell scripts in Python which now shells out to gpg and drops the output. We still use an on-disk file, but it's small enough (16 bytes, ie. one AES-128 block) to not be a significant overhead - it will end up in the VM cache soon enough, and there's an extra run before the real benchmark to make sure that's the case. > Why not using PKCS#11 directly (and measure real RSA speed of the > device, since AES is done in CPU anyway) instead of blackboxing the > GPG? Because that's harder to implement and there's only so much time I can spend implementing new software that is basically throwaway once I'm done making those graphs. Besides, gpg is surprisingly fast, I must say. We can see the overhead due to the gpg calls in the "CPU" column in the graph - it's basically insignificant compared to the communication and decryption time from the card, at this stage. A feedback I heard from another reviewer was that I should communicate directly with gnupg-agent, for what it's worth. I could also skip the Linux kernel USB stack to speed things up, for example. This misses the point: there is always an overhead in the various tests, even if it's only the Python interpretor or the CPU pipelines and caches. The point is that this is kept constant across tests for the multiple devices so we can have comparable data points. > How many runs have you done for each device? 100 > Have you removed the outliers? No, but the graphs show the standard deviation of the samples, which seems to be statistically insignificant. Only in the case of the FST-01 doing RSA-4096 operations do we even see it at all. > You can also try to compare the results with another benchmarking tool, > like graphene-cli [1]. They have some test results already but I cannot > find it right now. > > [1] https://github.com/PeculiarVentures/graphene-cli Well crap - I didn't even know there *was* such a tool. It's good to know, but that thing looks much harder to use than my current configuration. Results from the README file do look comparable to the performance of the Yubikey 4, however, so I'm confident that I can continue with my current approach. Unless, of course, someone provides patches to skip GnuPG and talk directly to PKCS#11 or whatever acronym you feel is better suited to produce relevant metrics. ;) I published the script and updated benchmarks here, now with Nitrokey results: https://gitlab.com/anarcat/crypto-bench/ This will be the object of a coming article about OpenPGP best practices, including offline certification key storage and, of course, crypto tokens magic. Any recommendations or reviewers would obviously be welcome so that I don't look too much like a dork. ;) Thanks for the feedback everyone! A. -- Antoine Beaupr? LWN.net From alci at mecadu.org Fri Sep 8 11:00:31 2017 From: alci at mecadu.org (Franck Routier (perso)) Date: Fri, 8 Sep 2017 11:00:31 +0200 Subject: Poldi example usage of gpg-connect-agent fails In-Reply-To: References: <7f5736e1-074e-40f0-9579-e5ad8cc137a1@mecadu.org> Message-ID: <84c4d428-393c-1854-c115-d66ec3848327@mecadu.org> Hi, and thank you for your help, Le 07/09/2017 ? 08:06, Alexander Paetzelt | Nitrokey a ?crit : > I got this working some weeks ago for testing purposes. I did what's > written here > > https://www.nitrokey.com/documentation/applications#p:nitrokey-pro&os:linux&a:computer-login > > > Why do you think, poldi-ctrl is not there for 0.4? I used 0.4.1 and had > it (on ArchLinux though). You may have to use root rights to use > poldi-ctrl? In fact poldi-ctrl is not included in the debian/ubuntu package. The NEWS file in /usr/share/doc/libpam-poldi even states, at the very beginning: "Changes since version 0.4.1: * poldi-ctrl is removed Please use gpg-connect-agent instead." That said, I could compile poldi-ctrl from source to get the config file I needed. The steps I followed are: $ git clone https://github.com/chrisboyle/poldi.git $ sudo apt install libgpg-error-dev $ sudo apt install libpam0g-dev $ sudo apt install libgcrypt20-dev $ ./configure;make then poldi-ctrl is in poldi/src/ctrl/poldi-ctrl I had to stop the running scdaemon to get it working, and poldi-ctrl -k finally gave me the right incantations. So I now have it running. Now, the Debian packager, and even the upstram doc writer seem to think I should use gpg-agent... So, anyone has an idea about why this fails: $ gpg-connect-agent "/datafile myfile" "SCD READKEY --advanced OPENPGP.3" /bye ERR 100663414 Identifiant incorrect Regards, Franck > > Kind regards > Alex > > > On 09/06/2017 11:30 AM, Franck Routier (perso) wrote: >> Hi, >> >> I am trying to get into smartcard usage, and would want to allow >> Authentication on my system with an OpenPGP Card (FSFE Fellowship >> smartcard). >> >> As I understand it (I might be wrong), the right pam module is Poldi. >> >> According to the Texinfo page (info poldi), current version is 0.4, >> and lacks the previous poldi-ctrl utility, so I have to create some >> config file manually. >> >> Specifically, here is the example that is given: >> >> >> First, the system administrator has to associate the user moritz >> with >> the card's serial number: >> >> $ echo "D2760001240101010001000006550000 moritz" >> >> /etc/poldi/localdb/users >> >> Second, the system administrator needs to write the card's key >> into a >> card-specific key file. Therefore he inserts Moritz' smartcard and >> executes: >> >> $ gpg-connect-agent "/datafile >> /etc/poldi/localdb/keys/D2760001240101010001000006550000" "SCD READKEY >> --advanced OPENPGP.3" /bye >> >> >> My problem is that the command gpg-connect-agent "/datafile myfile" >> "SCD READKEY --advanced OPENPGP.3" /bye returns an error: >> >> ERR 100663414 Identifiant incorrect >> >> >> Can anyone help me on this ? (or is there a better way to authenticate >> using an OpenPGP smartcard ?) (or is it just a bad idea ?) >> >> Thanks in advance >> >> Franck >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Sep 8 11:56:32 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 8 Sep 2017 11:56:32 +0200 Subject: Poldi example usage of gpg-connect-agent fails In-Reply-To: <7f5736e1-074e-40f0-9579-e5ad8cc137a1@mecadu.org> References: <7f5736e1-074e-40f0-9579-e5ad8cc137a1@mecadu.org> Message-ID: <3bf85874-372d-927e-009a-39379cbbdc7a@digitalbrains.com> On 06/09/17 11:30, Franck Routier (perso) wrote: > My problem is that the command gpg-connect-agent "/datafile myfile" > "SCD READKEY --advanced OPENPGP.3" /bye returns an error: > > ERR 100663414 Identifiant incorrect Hmmm, it works for me on Debian stretch/stable, with the system-provided GnuPG 2.1.18. If I am lazy and don't uppercase the slot identifier, I get a comparable result: $ gpg-connect-agent "/datafile /home/peter/bla.key" "SCD READKEY --advanced openpgp.3" /bye ERR 100663414 Invalid ID If I try it on a card which only has S and E keys, no A key, the result is something else: $ gpg-connect-agent "/datafile /home/peter/bla.key" "SCD READKEY --advanced OPENPGP.3" /bye ERR 100663305 No public key Which version of GnuPG are you using? It does not appear to be that the functionality no longer works in newer versions, since 2.1.18 is pretty recent. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lestofante88 at gmail.com Sat Sep 9 00:50:56 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sat, 9 Sep 2017 00:50:56 +0200 Subject: [Feature Request] Multiple level subkey Message-ID: Hello, Maybe this is not the right place to discuss about this, please be kind with a noob. My user case is simple; maintain my identity even if my master key is compromised. Tho achieve that, I think about a multilevel subkey system. Please i would love to hear any alternative. For the discussion purpose, we don't talk about HOW revoke and public key are exchanged between peers; it could be with existing key server, or other way. I would like to set up a system relatively secure, but with no hassle for everyday use. The idea is the following: A level 1 key, kept very safe (hw or paper wallet wallet). This key represent the identity is hopefully used only once to generate one subkey "level 2". The subkey level 2 is saved on one (or more, but trusted) main device. This key will be used to generate its own subkey (level 3), those subkey are used for various application and distributed between device using relatively unsafe method; losing, revoking or issuing a new key for a new application should be easy and transparent for the user. the idea is that the level 2 key is used for most of the normal operation, even in case one or more level 3 key are compromised; please remember that all they key just represent the identity of the level 1 key. This is very similar to the chain of trust with certificate. Now the nice thing: i guess most of the people will use their phone to keep the level 2 key, but we know those are not the most secure stuff, especially when get old or wit some producer allergic to patch. In the unlucky case the level 2 key get compromised, the user can use the level 1 key to: 1. revoke the level 2 key. This of course will automatically revoke the level 3 key that are direct subkey of that level 2 key. 2. issue a new level 2 key. At this point the main device will issue new level 3 key to replace all the key revoked in the step above. please note a user could have multiple level 2 key active; this could be for different reason, like updating to different algorithm still not fully supported. Lesto ps. is anyone aware of some kind P2P system to share keys? From maccallini.paolo at gmail.com Sat Sep 9 16:07:52 2017 From: maccallini.paolo at gmail.com (maccallini.paolo at gmail.com) Date: Sat, 9 Sep 2017 16:07:52 +0200 Subject: memory not safe Message-ID: <003701d32975$07236930$156a3b90$@gmail.com> Hi, I am new. I have downloaded Msys2 32 bit. The shall says "memoria non sicura in uso" which means "memory not safe in use". What does it mean? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.jackson at nordnet.fr Sat Sep 9 14:54:23 2017 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sat, 9 Sep 2017 14:54:23 +0200 Subject: Unable to sign or decrypt with card Message-ID: gpg (GnuPG) 2.1.11 in UbuntuStudio 16.04 LTS libgcrypt 1.6.5 At the end of April, I made a detached signature of a file that I was distributing. Today I updated that file and tried to make another detached signature. The operation failed with a not very informative error message : gpg: signing failed: Operation cancelled I checked the card-status and it seemed normal so I encrypted a test file and that was ok. The PIN is certainly correct. Then I tried to decrypt the test file and the operation failed with a better message : gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key So it looks like my secret key has vanished from sight and contact of gpg in the past 4 months although I have changed strictly nothing in my setup in that period - except regular UbuntuStudio security updates and I don't recall having seen and gpg stuff go through. gpg2 -K does list my secret key - Suggestions as to how to check and correct this situation would be appreciated. Philip From wk at gnupg.org Sun Sep 10 16:52:33 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Sep 2017 16:52:33 +0200 Subject: Unable to sign or decrypt with card In-Reply-To: (Philip Jackson's message of "Sat, 9 Sep 2017 14:54:23 +0200") References: Message-ID: <87wp56sj0u.fsf@wheatstone.g10code.de> On Sat, 9 Sep 2017 14:54, philip.jackson at nordnet.fr said: > Suggestions as to how to check and correct this situation would be > appreciated. Newer versions of gpg should print a better error message; at least with -v. I guess that your pinentry is not installed or can't be used. Do you have the option "pinentry-program" in your gpg-agent.conf ? Then check that it is really there. Is the environment variable GPG_TTY set as describen in the manual? Do you get a prompt when calling "pinentry"? If so, does it show up a window after entering "getpin"? More information about gpg-agent an pinentry interaction can be seen by putting --8<---------------cut here---------------start------------->8--- log-file /somewhere/gpg-agent.log verbose debug ipc debug-pinentry --8<---------------cut here---------------end--------------->8--- into gpg-agent.conf and restarting gpg-agent ("pkill gpg-agent" or "gpgconf --kill gpg-agent"). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Sep 10 16:36:58 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 10 Sep 2017 10:36:58 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: <87ingq39it.fsf@fifthhorseman.net> On Sat 2017-09-09 00:50:56 +0200, lesto fante wrote: > Maybe this is not the right place to discuss about this, please be > kind with a noob. this is the right place, welcome! > My user case is simple; maintain my identity even if my master key is > compromised. Tho achieve that, I think about a multilevel subkey > system. I'm not sure how the proposed multi-level system is an improvement over an offline primary key. It's certainly more complicated, but complexity is a bug, not a feature. can you explain why you think it's better? with an offline primary key, you only put subkeys on any device that's used regularly. That said, even offline primary keys aren't super easy-to-use at the moment, more work could be done to streamline that use case. > ps. is anyone aware of some kind P2P system to share keys? are you asking about secret key sharing (between devices controlled by the same person) or public key distribution? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From leo at gaspard.io Sun Sep 10 17:28:08 2017 From: leo at gaspard.io (Leo Gaspard) Date: Sun, 10 Sep 2017 17:28:08 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <87ingq39it.fsf@fifthhorseman.net> References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: On 09/10/2017 04:36 PM, Daniel Kahn Gillmor wrote:>> My user case is simple; maintain my identity even if my master key is >> compromised. Tho achieve that, I think about a multilevel subkey >> system. > > I'm not sure how the proposed multi-level system is an improvement over > an offline primary key. It's certainly more complicated, but complexity > is a bug, not a feature. can you explain why you think it's better? > > with an offline primary key, you only put subkeys on any device that's > used regularly. I can think of at least one use case it covers in addition to an offline masterkey (but that would also be covered by C subkeys): the ability to sign others? keys without using your masterkey. This would allow to not have to expose the keysigning device to untrusted data/software/hardware that would carry the to-be-signed key. It would also make an offline masterkey much more convenient to use, given one could just do like it never existed (even for keysigning), except once the subkeys become compromised -- and at that time, the recovery operation would be 1/ re-generate subkeys, 2/ re-sign all keys you had signed with your previous C subkey. What do you think about this? (maybe I should just raise the issue on rfc4880bis ML, but as the question arose here?) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Sun Sep 10 18:34:35 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 10 Sep 2017 17:34:35 +0100 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: <5B315771-2B66-441D-98EE-C246AC20C62F@andrewg.com> > On 10 Sep 2017, at 16:28, Leo Gaspard wrote: > > I can think of at least one use case it covers in addition to an offline > masterkey (but that would also be covered by C subkeys): the ability to > sign others? keys without using your masterkey. This would allow to not > have to expose the keysigning device to untrusted data/software/hardware > that would carry the to-be-signed key. I think C subkeys are a *much* simpler solution for that use case. Better to treat this scenario as "solved in principle" and put it aside for the time being. A From lestofante88 at gmail.com Sun Sep 10 17:23:51 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 15:23:51 +0000 Subject: [Feature Request] Multiple level subkey In-Reply-To: <87ingq39it.fsf@fifthhorseman.net> References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: Thanks! I though a bit more and I have now a bit more clear ideas. I want a "identity" key; this is the most important key and should be super-secure, like a hw wallet/card. In the best case scenario it is used to issue a master key, and never used again. Then we have one (or more) master key; those are used to issue and revoke subkey (application key). Those will be a bit less secure, as they will stay on one or more user device regularly in use (I plan to use the smartphone as central key storage and manager). Then the application are what are used by the application. Notice they all refer to the main identity; changing one of the key does not require nothing else than revoke the old key and issue a new one. The idea is to make the use and generation of subkey transparent and not requiring the super-secure identity key; the master key is used, and if compromised the super-secure identity key will revoke the master key and issue a new one. Then automatically (depending on settings, but bear with me) opening any application will trigger the recreation of a subkey dedicated; as they are still rapresenting the same identity, no question is asked by the service, as recognize the user. The p2p system would be a nice way to share PUBLIC key and REVOKE between peers. Now, I have been pointed out that the sanity card in EU (for non EU; all EU has the same sanity card.. So you can travel and not have to worry) come with a certificate inside! We could use that certificate, to sign a second certificate that sing our master key. The second certificate is needed because that way we can revoke it without having to revoke the identity (which could be difficult to explain to your authority, even if you could "loose" the card, and then a new certificate *should* be issued, but I don't know how it work. Also seems the CA are regional, so there are multiple server for country) My final goal is to have a secure key in case of big issue, and a series of less secure key to make using them seminless, actually even more easy than using a password or a password wallet! On Sun, Sep 10, 2017, 17:03 Daniel Kahn Gillmor wrote: > On Sat 2017-09-09 00:50:56 +0200, lesto fante wrote: > > > Maybe this is not the right place to discuss about this, please be > > kind with a noob. > > this is the right place, welcome! > > > My user case is simple; maintain my identity even if my master key is > > compromised. Tho achieve that, I think about a multilevel subkey > > system. > > I'm not sure how the proposed multi-level system is an improvement over > an offline primary key. It's certainly more complicated, but complexity > is a bug, not a feature. can you explain why you think it's better? > > with an offline primary key, you only put subkeys on any device that's > used regularly. > > That said, even offline primary keys aren't super easy-to-use at the > moment, more work could be done to streamline that use case. > > > ps. is anyone aware of some kind P2P system to share keys? > > are you asking about secret key sharing (between devices controlled by > the same person) or public key distribution? > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lestofante88 at gmail.com Sun Sep 10 18:36:54 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 18:36:54 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: I am a bit confused by your "C key" terminology, i assume you are referring to what i call "master key", or level 2 key, that now I want to call SIGN KEY. Lets all agree on the terminology please. I propose this: level 1: IDENTITY key - keep super safe. Paranoid level safe. level 2: SIGN key - keep password protected on you main devices. Normal user level safe level 3: APPLICATION KEY - can be clear and shared between multiple device. Quite unsafe, but convenient; completely transparent login! And still way safer than the classic "cookie to remember my login" approach Also i don't know what rfc4880bis ML is? is that some proposal somehow similar? Back to your email: You totally get it right! Make the system CONVENIENT, keep your masterkey under you bed and forget about it. if you use that system on you bank, the bank does NOT care what "application key" (well, read later) you are using, as long as it is not revoked, as it is all the same identity. We SHOULD think a way to integrate some permission in the key itself, like the name of the service it is supposed to be used; if someone stole a APPLICATION key can't use it to login to a different service. So we can imagine a situation where you create a APPLICATION key with permission to you use your bank account for up to 50?/week (of course, the limit for key is something implemented by the bank), and then give this key to you smart-fridge. Your fridge will not be able to sniff your facebook account, read your email or drain your ban account; and if something goes wrong, you KNOW what device is compromised. This could be as simple as the service giving you a ID to add somewhere IN the key, similar to how name and email can be set for a certificate right now. A bit more complex would be to avoid duplicate ID. This permission thing could be also extended to SIGN KEY, eventually, but then I think could be just complexity without really added benefit, as in my idea normally there is only one master key. But that can be changed, just i have no idea of the categories to create. This make SUPER convenient to revoke one or all you SIGN KEY and/or APPLICATION KEY without need for ANY other change; the reissuing process for the new key can be totally automated. Again I'm NOT taking into consideration how you share APPLICATION and SIGN key between your devices, that is a problem for another day discussion (would be extremely nice to have a standard way for any DEVICE to request a application key with SUGGESTED permission to the main device, but we have already too much on the fire right now) What we NEED is a clear standard to publish public key and revoke, and we could simply use the existing key server. Think about a company, with is own key server that identify its worker, customer and such; you use you smartphone to clock-in and out your work, to start your (encrypted) work computer, sign and, encrypt and decrypt message, and be a step safer from scammer and social engineering. Another advantage, is that you could generate and use one application key "on the spot" with your smartphone/pc, for example to sign a contract, without exposing your identity key. Your sign key and all its application key are exposed, but changing them is pretty easy, just revoke it and issue a new one. Now, compromising your IDENTITY would be a pain; or you signed a second identity some reasonable time before the revoke, or you have some sort of CA that issue it and link it to the previous identity. Otherwise you simply lose it all. I think the system is not really complex, im just bad to explain it :) On Sun, Sep 10, 2017, 17:28 Leo Gaspard wrote: > On 09/10/2017 04:36 PM, Daniel Kahn Gillmor wrote:>> My user case is > simple; maintain my identity even if my master key is > >> compromised. Tho achieve that, I think about a multilevel subkey > >> system. > > > > I'm not sure how the proposed multi-level system is an improvement over > > an offline primary key. It's certainly more complicated, but complexity > > is a bug, not a feature. can you explain why you think it's better? > > > > with an offline primary key, you only put subkeys on any device that's > > used regularly. > > I can think of at least one use case it covers in addition to an offline > masterkey (but that would also be covered by C subkeys): the ability to > sign others? keys without using your masterkey. This would allow to not > have to expose the keysigning device to untrusted data/software/hardware > that would carry the to-be-signed key. > > It would also make an offline masterkey much more convenient to use, > given one could just do like it never existed (even for keysigning), > except once the subkeys become compromised -- and at that time, the > recovery operation would be 1/ re-generate subkeys, 2/ re-sign all keys > you had signed with your previous C subkey. > > What do you think about this? (maybe I should just raise the issue on > rfc4880bis ML, but as the question arose here?) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at gaspard.io Sun Sep 10 18:59:24 2017 From: leo at gaspard.io (Leo Gaspard) Date: Sun, 10 Sep 2017 18:59:24 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: On 09/10/2017 06:36 PM, lesto fante wrote: > I am a bit confused by your "C key" terminology, i assume you are > referring to what i call "master key", or level 2 key, that now I want > to call SIGN KEY. Oh yes sorry, I forgot to explain my terminology. > Lets all agree on the terminology please. I propose this: > > level 1: IDENTITY key - keep super safe. Paranoid level safe. > > level 2: SIGN key - keep password protected on you main devices. Normal > user level safe > > level 3: APPLICATION KEY - can be clear and shared between multiple > device. Quite unsafe, but convenient; completely transparent login! And > still way safer than the classic "cookie to remember my login" approach This is the terminology that would be used under your proposal, do I understand correctly? What I called C subkeys is based on the terminology for the three major operations possible with keys under OpenPGP: Certify, Sign and Encrypt (I seem to remember Authenticate also exists, although I never used it myself). Certify usually means ?assert something about the owner of some other key,? Sign means ?assert I have written this content,? and Encrypt means ?make this content only accessible by someone.? OpenPGP already has Sign and Encrypt (S and E) subkeys, but currently, as far as I can remember, Certify (C) subkeys are hardly supported. > Also i don't know what rfc4880bis ML is? is that some proposal somehow > similar? RFC4880bis ML is the place where the evolutions to RFC4880 (the RFC describing OpenPGP) are usually discussed, although here is as good a place as there for a first draft. The ?C subkeys? proposal would be to allow people to have a subkey with the Certification capability (that is, allowed to perform this operation on behalf of the masterkey). Then, the proposal is close to what you proposed, except there is no hierarchy of keys: you just have a masterkey, and S, E and C subkeys directly signed by the masterkey. All these subkeys, when put together, have all the power the masterkey has -- except the masterkey can revoke them and issue new ones. > Back to your email: You totally get it right! > > Make the system CONVENIENT, keep your masterkey under you bed and forget > about it. > if you use that system on you bank, the bank does NOT care what > "application key" (well, read later) you are using, as long as it is not > revoked, as it is all the same identity. > > We SHOULD think a way to integrate some permission in the key itself, > like the name of the service it is supposed to be used; if someone stole > a APPLICATION key can't use it to login to a different service. So we > can imagine a situation where you create a APPLICATION key with > permission to you use your bank account for up to 50?/week (of course, > the limit for key is something implemented by the bank), and then give > this key to you smart-fridge. Your fridge will not be able to sniff your > facebook account, read your email or drain your ban account; and if > something goes wrong, you KNOW what device is compromised. This could be > as simple as the service giving you a ID to add somewhere IN the key, > similar to how name and email can be set for a certificate right now. A > bit more complex would be to avoid duplicate ID. I fear you are going a bit too far in the future. Besides, there is no need to give the same masterkey to your bank and your smart fridge, as they will (likely?) not participate in the Web of Trust anyway. > This permission thing could be also extended to SIGN KEY, eventually, > but then I think could be just complexity without really added benefit, > as in my idea normally there is only one master key. But that can be > changed, just i have no idea of the categories to create. > > This make SUPER convenient to revoke one or all you SIGN KEY and/or > APPLICATION KEY without need for ANY other change; the reissuing process > for the new key can be totally automated. Again I'm NOT taking into > consideration how you share APPLICATION and SIGN key between your > devices, that is a problem for another day discussion (would be > extremely nice to have a standard way for any DEVICE to request a > application key with SUGGESTED permission to the main device, but we > have already too much on the fire right now) > > What we NEED is a clear standard to publish public key and revoke, and > we could simply use the existing key server. Think about a company, with > is own key server that identify its worker, customer and such; you use > you smartphone to clock-in and out your work, to start your (encrypted) > work computer, sign and, encrypt and decrypt message, and be a step > safer from scammer and social engineering. Hmmm... The keyservers also exist and work quite well for public key publishing and revocation, so I don't get why we would need something else? It's the de-facto standard. Then, the company should not run a keyserver, but just sign the keys of all workers, and check the signature is valid and not revoked on use. > Another advantage, is that you could generate and use one application > key "on the spot" with your smartphone/pc, for example to sign a > contract, without exposing your identity key. Do you mean not exposing your public identity key or your private identity key? If you mean public identity key, then how is the other side of the contract supposed to ensure you are actually signing as yourself and not as someone else? If you mean private identity key, then there is already no need to expose any private part of any key when signing, as everything happens on your device and public-key cryptography ensures this property. > Your sign key and all its application key are exposed, but changing them > is pretty easy, just revoke it and issue a new one. > > Now, compromising your IDENTITY would be a pain; or you signed a second > identity some reasonable time before the revoke, or you have some sort > of CA that issue it and link it to the previous identity. Otherwise you > simply lose it all. > > I think the system is not really complex, im just bad to explain it :) I think I sort of get what you are doing, but don't really get the advantage compared to things already possible with OpenPGP (with C subkeys), that is: Master keypair |- Signature keypair (or many such, all revocable) |- Encryption keypair (or many such, all revocable) `- Certification keypair (or many such, all revocable) Cheers, Leo From dgouttegattat at incenp.org Sun Sep 10 19:47:07 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 10 Sep 2017 19:47:07 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> Hello, On 09/09/2017 12:50 AM, lesto fante wrote: > Tho achieve that, I think about a multilevel subkey system. The OpenPGP specification already has some support for a hierarchical system, in the form of "trust signatures". (Hereafter, I will use "trust-sign" as a verb to refer to the act of emitting a trust signature.) For a 3-levels hierarchy as you describe, you could do the following: a) You sign your level-3 key(s) with your level-2 key; b) You trust-sign your level-2 key with your level-1 key, with a trust depth of 1. c) Your correspondents trust-sign your level-1 key, with a trust depth of 2. If your level-1 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-1 key will be automatically valid for your correspondents. If your level-2 key is compromised, you revoke it, generate a new one, tsign it with the level-1 key, and use it to re-sign your level-1 key (although if the level-2 key is compromised, you may want to assume that the level-1 key is compromised as well, and generate a new one). Again, the new level-2 key will be valid and trusted by your correspondents, since it bears a trust signature from the level-1 key. The problem you may have with this method is that it depends on your correspondents *trust-signing* your level-1 key. If they use a normal signature instead (or a trust signature with a trust depth < 2), no ownertrust will be assigned to the level-2 key and therefore the level-3 key will not be considered valid. So you have to tell your correspondents to *trust-sign* your level-1 key, but you cannot force them to do so. This is kind of a design feature of OpenPGP, by the way: the user is always free to choose whom he wants to trust, and to what extent. This is by contrast with the X.509 world, where the fact that a certificate can only be signed by *one* authority gave rise to an ecosystem of CAs that are "too-big-to-fail" (or "too-big-to-choose-not-to-trust"). > Now the nice thing: i guess most of the people will use their phone > to keep the level 2 key, but we know those are not the most secure > stuff, especially when get old or wit some producer allergic to > patch. Slightly off-topic, but using a NFC-enabled token might be an easier way to deal with that particular concern. I know of at least two such tokens: the Yubikey NEO [1] and the Fidesmo Privacy Card [2]. Damien [1] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ [2] http://shop.fidesmo.com/product/fidesmo-privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From leo at gaspard.io Sun Sep 10 20:27:33 2017 From: leo at gaspard.io (Leo Gaspard) Date: Sun, 10 Sep 2017 20:27:33 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <87ingq39it.fsf@fifthhorseman.net> Message-ID: <0d97834c-ba3b-1906-faa3-32419031bfdc@gaspard.io> (you forgot to Cc: the list, I'm Cc-ing back as it doesn't seem voluntary to me) On 09/10/2017 07:50 PM, lesto fante wrote: >> Besides, there is no > need to give the same masterkey to your bank and your smart fridge, as > they will (likely?) not participate in the Web of Trust anyway > > not the same masterkey, but the same identity. Very important for > changing the key transparently. By ?masterkey? I meant ?most privileged key? (that is what you call ?identity key?). I'll try to use your terminology henceforth. > You are right, I don't need the same identity for the fridge and the > bank.. until I want the fridge to buy the milk. > Or, for a more realistic example, i want my bank key and amazon key to > be different, but to point to the same identity.. make more sense now? > Yes, i could do it with the current master key and sub-key, but with > the lack of a "master-master" key, a compromised master key would be a > hassle to manage (that remember, is on the user device.. probably the > smartphone. not exactly the safest device, and something quite easy to > lose or get stolen). I still don't get why you would want amazon and your bank to see the same identity key. The only point of an identity key is to accumulate signatures from the WoT, here there is no need of WoT and you could just say amazon to connect you with one key and to pay with [some private key you gave the corresponding public key to your bank]. >> Then, the company should not run a keyserver, but just sign the keys of > all workers, and check the signature is valid and not revoked on use. > > if you sign the identity of the worker, how do you revoke your sign? With OpenPGP's revocation signature, that GnuPG gives an ?easy? interface for? > AFAIK you should create a certificate for each worker and then sign > it, and use that certificate to sign the worker identity, so you can > revoke the worker certificate. That, to me, seems a bit more complex, > but on the bright side can be implemented right now. No, currently you'd just sign the worker's masterkey with the company's masterkey, and when the worker no longer works here you'd revoke the previous signature. > A company may want to run their own server maybe because they don't > want to expose all the certificate for all their worker. To me make a > lot of sense, especially for sector like security or social care. Indeed they may want to, but it is not (or maybe ?should not??) be a critical piece of the infrastructure: current keyserver software is most likely not as secure as the cryptography underlying signatures is. >> Do you mean not exposing your public identity key or your private > identity key? > > private identity key. Your public identity is well known, the private > key should be the most safe thing you have. Losing it is like losing > your documents. > Well, actually my end goal is to REPLACE documents (like passport) > with this system. This also help you to understand why is so important > to protect the identity, but still have a way to be able to issue it > to minor services for everyday usage. Well, you should never expose your private identity key to anyone, or any other private key linked to you for that matter. To take back your example with amazon and your bank, there is absolutely no need that the private key you give amazon is linked to your identity, it just need correspond to the public key you gave your bank. You could even not use public-key crypto, and only give the same 128-bit token to both sides, and it should be enough (though your bank may insist on public-key cryptography so that they can have a proof that such key issued such payment order). If you don't want to access your bank's website, you could just give a 128-bit token signed with your signing key or whatever to amazon (disclaimer: I'm writing this without thinking about all the security implications right now, just throwing an idea out in the air). >> If you mean private identity key, then there is already no need to > expose any private part of any key when signing > > you dont expose it *mathematically*, bu you expose it to the outside > world, where you can lose it, got it stolen.. and then all your > identity and related is compromised, and you have no easy or automated > way to get back the ownership. > Losing the SIGN key is scary, but as soon as you get home (or you > alert your "trust" person, that just have the revoke key for the SIGN > key, so it does not need to be *that* trusty), you will have your > master key revoked, and as soon as you create a new SIGN key, you will > *automatically* regain access to all services. I think I no longer get what you call masterkey. >> I think I sort of get what you are doing, but don't really get the > advantage compared to things already possible with OpenPGP (with C > subkeys), that is: > > this is interesting, i cant find much on how certification key work; > but if they can be used to create and revoke other key in the behalf > of the master key, then seems to be exactly what I'm looking for. I > just can't find anything, and I guess i'll have to find it on the RFC It doesn't allow to create other keys on behalf of the masterkey (or at least that's not how I'm seeing it to work). It just allows to delegate some more power from the masterkey to the subkeys. Currently, you can delegate signing and encryption powers from masterkey to subkeys. The only operation missing, from what I can tell, is Certification, that is signing someone else's masterkey to strengthen the WoT. That is to mean you can already have a signing subkey per device if you want to (encryption is a bit harder, but out of the scope of this discussion if I understood where you're going). From dgouttegattat at incenp.org Sun Sep 10 20:39:04 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 10 Sep 2017 20:39:04 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> Message-ID: <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> On 09/10/2017 08:30 PM, lesto fante wrote: >> If your level-1 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-1 key will be automatically valid for your correspondents. >> >> If your level-2 key is compromised, you revoke it, generate a new one, tsign it with the level-1 key > > this is exactly what i DON'T want. The level 2 key (or level 1, it > seems you mixed them up) Sorry, I did mix level-1 and level-3 keys in the first sentence you're quoting. What I meant was: If your level-3 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-3 key will be automatically valid for your correspondents. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lestofante88 at gmail.com Sun Sep 10 21:01:38 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 21:01:38 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <5B315771-2B66-441D-98EE-C246AC20C62F@andrewg.com> References: <87ingq39it.fsf@fifthhorseman.net> <5B315771-2B66-441D-98EE-C246AC20C62F@andrewg.com> Message-ID: can you please explain what are C subkey? unfortunately a search with those terms does not return nothing relevant, a direct link to some docs would be nice. Also i took a look at rfc4880bis but again i can't see how is related to C key or this argument at all. (sent again as sent only to andrew instead of all user list, sorry!) 2017-09-10 18:34 GMT+02:00 Andrew Gallagher : > >> On 10 Sep 2017, at 16:28, Leo Gaspard wrote: >> >> I can think of at least one use case it covers in addition to an offline >> masterkey (but that would also be covered by C subkeys): the ability to >> sign others? keys without using your masterkey. This would allow to not >> have to expose the keysigning device to untrusted data/software/hardware >> that would carry the to-be-signed key. > > I think C subkeys are a *much* simpler solution for that use case. Better to treat this scenario as "solved in principle" and put it aside for the time being. > > A From lestofante88 at gmail.com Sun Sep 10 21:02:55 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 21:02:55 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> Message-ID: (sent again because i forgot to add the mailing list in CC, sorry) >If your level-1 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-1 key will be automatically valid for your correspondents. > >If your level-2 key is compromised, you revoke it, generate a new one, tsign it with the level-1 key this is exactly what i DON'T want. The level 2 key (or level 1, it seems you mixed them up) is way less safe than the level 1, as the level 1 is on your smart-card, in a safe place, and the level 2 is in your PC, on your smartphone, and you basically carry it with you every time, as you want to be able to access new services without the hassle of having the smart-card with you. With all the security problem connected to having the smart-card with you; I assume keeping in in your house, or even in a security box, is way more safe. So again: trust goes in one direction only, the same direction of security. Level 1 > Level 2 > Level 3 >Slightly off-topic, but using a NFC-enabled token might be an easier way to deal with that particular concern. I have one of them. Result: * I do not carry them with me, I'm to scared to lose it * The card does not have NFC * I don't have NFC on my emergency smartphone, so i need to also carry the cable and hope the phone can handle it (driver + OTG usb) * If my smartphone/pc is compromised, when i connect the NFC they can do whatever they want, even sign THEIR key and revoke mine. With my system the level 2 key get revoked, and I know the device that have it are compromised, so i will format/change them before issuing a new level 2 key * I created some key on my pc and used them for a while for this email, until the for an unfortunate accident i lost them and their backup (remember to power up your USB key, they have an internal battery that need to be recharged sometimes, should be 10 years... should); if they would have somehow signed by my HW wallet (witch i assume NOT having the same power-related issue), i could have issued a new one, and uploaded them on the key server. Instead now i can't even revoke them. There are more, if i sit there and think about all frustration i had to manage my keys, and for sure there is a lot to do in the wallet side too. 2017-09-10 19:47 GMT+02:00 Damien Goutte-Gattat : > Hello, > > On 09/09/2017 12:50 AM, lesto fante wrote: >> >> Tho achieve that, I think about a multilevel subkey system. > > > The OpenPGP specification already has some support for a hierarchical > system, in the form of "trust signatures". > > (Hereafter, I will use "trust-sign" as a verb to refer to the act of > emitting a trust signature.) > > For a 3-levels hierarchy as you describe, you could do the following: > > a) You sign your level-3 key(s) with your level-2 key; > > b) You trust-sign your level-2 key with your level-1 key, with a trust depth > of 1. > > c) Your correspondents trust-sign your level-1 key, with a trust depth of 2. > > If your level-1 key is compromised, you revoke it, generate a new one and > sign it with the level-2 key. The new level-1 key will be automatically > valid for your correspondents. > > If your level-2 key is compromised, you revoke it, generate a new one, tsign > it with the level-1 key, and use it to re-sign your level-1 key (although if > the level-2 key is compromised, you may want to assume that the level-1 key > is compromised as well, and generate a new one). Again, the new level-2 key > will be valid and trusted by your correspondents, since it bears a trust > signature from the level-1 key. > > The problem you may have with this method is that it depends on your > correspondents *trust-signing* your level-1 key. If they use a normal > signature instead (or a trust signature with a trust depth < 2), no > ownertrust will be assigned to the level-2 key and therefore the level-3 key > will not be considered valid. So you have to tell your correspondents to > *trust-sign* your level-1 key, but you cannot force them to do so. > > This is kind of a design feature of OpenPGP, by the way: the user is always > free to choose whom he wants to trust, and to what extent. This is by > contrast with the X.509 world, where the fact that a certificate can only be > signed by *one* authority gave rise to an ecosystem of CAs that are > "too-big-to-fail" (or "too-big-to-choose-not-to-trust"). > > >> Now the nice thing: i guess most of the people will use their phone >> to keep the level 2 key, but we know those are not the most secure >> stuff, especially when get old or wit some producer allergic to >> patch. > > > Slightly off-topic, but using a NFC-enabled token might be an easier way to > deal with that particular concern. I know of at least two such tokens: the > Yubikey NEO [1] and the Fidesmo Privacy Card [2]. > > > Damien > > [1] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ > > [2] http://shop.fidesmo.com/product/fidesmo-privacy > From dgouttegattat at incenp.org Sun Sep 10 21:50:03 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 10 Sep 2017 21:50:03 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> Message-ID: <8d12a6cb-ff15-f13c-ea40-d3a8143a273b@incenp.org> On 09/10/2017 09:17 PM, lesto fante wrote: >> If your level-3 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-3 key will be automatically valid for your correspondents. > > what if i lose the level-2 key too? imagine level-2 and level-3 key > are both on my phone, with NO other copy of the level-2 and level-3 > private key. > Can i revoke all of them? You revoke the level-2 key, that will be enough to invalidate the signature on the level-3 key. > If my device is in the hand of a bad person, will he be able to > compromise my level-1 key Assuming the level-1 key is not on that device, then no. > Also i understand the key-level truthiness, but here i want to > AUTOMATE, make this thing MORE EASY to use than a common password > approach. I merely pointed out what is already feasible with the current state of the OpenPGP specification and the GnuPG implementation. > This approach MUST be "housewife proof"; her son/truth person will set > up the sign key for her and then just tell her to keep the smartcard > in a safe place. Then to choose a safe password for the SIGN key. That > is the only password out housewife need, unless she will loose or get > a compromised phone; at this point, she will call the trust person > that will take care revoke, and then issuing a new SIGN key on her new > phone. No need to go and reset ALL of her account and such; all the > key she had has been already replaced :) I do not really care for this "user is an idiot, we cannot trust him/her to do the right thing so we should do it for him/her" approach. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lestofante88 at gmail.com Sun Sep 10 21:17:33 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 21:17:33 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> Message-ID: >If your level-3 key is compromised, you revoke it, generate a new one and sign it with the level-2 key. The new level-3 key will be automatically valid for your correspondents. what if i lose the level-2 key too? imagine level-2 and level-3 key are both on my phone, with NO other copy of the level-2 and level-3 private key. Can i revoke all of them? If my device is in the hand of a bad person, will he be able to compromise my level-1 key meanwhile I get in contact with someone that can revoke the level-2 key (and so all of its subkey)? Also i understand the key-level truthiness, but here i want to AUTOMATE, make this thing MORE EASY to use than a common password approach. This approach MUST be "housewife proof"; her son/truth person will set up the sign key for her and then just tell her to keep the smartcard in a safe place. Then to choose a safe password for the SIGN key. That is the only password out housewife need, unless she will loose or get a compromised phone; at this point, she will call the trust person that will take care revoke, and then issuing a new SIGN key on her new phone. No need to go and reset ALL of her account and such; all the key she had has been already replaced :) 2017-09-10 20:39 GMT+02:00 Damien Goutte-Gattat : > On 09/10/2017 08:30 PM, lesto fante wrote: >>> >>> If your level-1 key is compromised, you revoke it, generate a new one and >>> sign it with the level-2 key. The new level-1 key will be automatically >>> valid for your correspondents. >>> >>> If your level-2 key is compromised, you revoke it, generate a new one, >>> tsign it with the level-1 key >> >> >> this is exactly what i DON'T want. The level 2 key (or level 1, it >> seems you mixed them up) > > > Sorry, I did mix level-1 and level-3 keys in the first sentence you're > quoting. What I meant was: > > If your level-3 key is compromised, you revoke it, generate a new one and > sign it with the level-2 key. The new level-3 key will be automatically > valid for your correspondents. > From lestofante88 at gmail.com Sun Sep 10 23:32:51 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 23:32:51 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <8d12a6cb-ff15-f13c-ea40-d3a8143a273b@incenp.org> References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <8d12a6cb-ff15-f13c-ea40-d3a8143a273b@incenp.org> Message-ID: >You revoke the level-2 key, that will be enough to invalidate the signature on the level-3 key. >I merely pointed out what is already feasible with the current state of the OpenPGP specification and the GnuPG implementation. you are right, after all if it is there, it can be automated. The real question is, would this break/interfere with something else? Your solution is quite different from the other and i need more time to evaluate it, but this is exactly why I'm there. >Assuming the level-1 key is not on that device, then no. just to be sure I don't misunderstand, the level 2 key cannot revoke the level 1 key, right? >I do not really care for this "user is an idiot, we cannot trust him/her to do the right thing so we should do it for him/her" approach. i do. EVERYBODY is an idiot, someone is idiot every day, someone after 10h of works, someone only when all the planets are aligned. But it WILL happen to the majority of the population, even the best: and the best cure is the prevention. My goal is to bring good privacy at the housewife, while making the process even more easier (as it will be as easy as using a wallet). 2017-09-10 21:50 GMT+02:00 Damien Goutte-Gattat : > On 09/10/2017 09:17 PM, lesto fante wrote: >>> >>> If your level-3 key is compromised, you revoke it, generate a new one and >>> sign it with the level-2 key. The new level-3 key will be automatically >>> valid for your correspondents. >> >> >> what if i lose the level-2 key too? imagine level-2 and level-3 key >> are both on my phone, with NO other copy of the level-2 and level-3 >> private key. >> Can i revoke all of them? > > > You revoke the level-2 key, that will be enough to invalidate the signature > on the level-3 key. > > >> If my device is in the hand of a bad person, will he be able to >> compromise my level-1 key > > > Assuming the level-1 key is not on that device, then no. > > >> Also i understand the key-level truthiness, but here i want to >> AUTOMATE, make this thing MORE EASY to use than a common password >> approach. > > > I merely pointed out what is already feasible with the current state of the > OpenPGP specification and the GnuPG implementation. > > >> This approach MUST be "housewife proof"; her son/truth person will set >> up the sign key for her and then just tell her to keep the smartcard >> in a safe place. Then to choose a safe password for the SIGN key. That >> is the only password out housewife need, unless she will loose or get >> a compromised phone; at this point, she will call the trust person >> that will take care revoke, and then issuing a new SIGN key on her new >> phone. No need to go and reset ALL of her account and such; all the >> key she had has been already replaced :) > > > I do not really care for this "user is an idiot, we cannot trust him/her to > do the right thing so we should do it for him/her" approach. > > Damien > From lestofante88 at gmail.com Sun Sep 10 23:49:15 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 23:49:15 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <0d97834c-ba3b-1906-faa3-32419031bfdc@gaspard.io> References: <87ingq39it.fsf@fifthhorseman.net> <0d97834c-ba3b-1906-faa3-32419031bfdc@gaspard.io> Message-ID: (THIS IS THE FULL MAIL I FORGOT TO CC, for future reference) >This is the terminology that would be used under your proposal, do I understand correctly? yes, we can change it, but i think this is pretty understandable. >What I called C subkeys is based on the terminology for the three major operations possible with keys under OpenPGP: Certify, Sign and Encrypt (I seem to remember Authenticate also exists, although I never used it myself). oh, OK, now I get it, I know those stuff :) >Besides, there is no need to give the same masterkey to your bank and your smart fridge, as they will (likely?) not participate in the Web of Trust anyway not the same masterkey, but the same identity. Very important for changing the key transparently. You are right, I don't need the same identity for the fridge and the bank.. until I want the fridge to buy the milk. Or, for a more realistic example, i want my bank key and amazon key to be different, but to point to the same identity.. make more sense now? Yes, i could do it with the current master key and sub-key, but with the lack of a "master-master" key, a compromised master key would be a hassle to manage (that remember, is on the user device.. probably the smartphone. not exactly the safest device, and something quite easy to lose or get stolen). What im doing here is not create a super wall around my key killing usability, but instead making the *inevitable* easier to fix. >The keyservers also exist and work quite well for public key publishing and revocation, so I don't get why we would need something else? never said to use something else, actually I said "[...] we could simply use the existing key server [...]" >Then, the company should not run a keyserver, but just sign the keys of all workers, and check the signature is valid and not revoked on use. if you sign the identity of the worker, how do you revoke your sign? AFAIK you should create a certificate for each worker and then sign it, and use that certificate to sign the worker identity, so you can revoke the worker certificate. That, to me, seems a bit more complex, but on the bright side can be implemented right now. A company may want to run their own server maybe because they don't want to expose all the certificate for all their worker. To me make a lot of sense, especially for sector like security or social care. >Do you mean not exposing your public identity key or your private identity key? private identity key. Your public identity is well known, the private key should be the most safe thing you have. Losing it is like losing your documents. Well, actually my end goal is to REPLACE documents (like passport) with this system. This also help you to understand why is so important to protect the identity, but still have a way to be able to issue it to minor services for everyday usage. >If you mean private identity key, then there is already no need to expose any private part of any key when signing you dont expose it *mathematically*, bu you expose it to the outside world, where you can lose it, got it stolen.. and then all your identity and related is compromised, and you have no easy or automated way to get back the ownership. Losing the SIGN key is scary, but as soon as you get home (or you alert your "trust" person, that just have the revoke key for the SIGN key, so it does not need to be *that* trusty), you will have your master key revoked, and as soon as you create a new SIGN key, you will *automatically* regain access to all services. This is a killer feature, in my opinion. >I think I sort of get what you are doing, but don't really get the advantage compared to things already possible with OpenPGP (with C subkeys), that is: this is interesting, i cant find much on how certification key work; but if they can be used to create and revoke other key in the behalf of the master key, then seems to be exactly what I'm looking for. I just can't find anything, and I guess i'll have to find it on the RFC 2017-09-10 20:27 GMT+02:00 Leo Gaspard : > (you forgot to Cc: the list, I'm Cc-ing back as it doesn't seem > voluntary to me) > > On 09/10/2017 07:50 PM, lesto fante wrote: >>> Besides, there is no >> need to give the same masterkey to your bank and your smart fridge, as >> they will (likely?) not participate in the Web of Trust anyway >> >> not the same masterkey, but the same identity. Very important for >> changing the key transparently. > > By ?masterkey? I meant ?most privileged key? (that is what you call > ?identity key?). I'll try to use your terminology henceforth. > >> You are right, I don't need the same identity for the fridge and the >> bank.. until I want the fridge to buy the milk. >> Or, for a more realistic example, i want my bank key and amazon key to >> be different, but to point to the same identity.. make more sense now? >> Yes, i could do it with the current master key and sub-key, but with >> the lack of a "master-master" key, a compromised master key would be a >> hassle to manage (that remember, is on the user device.. probably the >> smartphone. not exactly the safest device, and something quite easy to >> lose or get stolen). > > I still don't get why you would want amazon and your bank to see the > same identity key. The only point of an identity key is to accumulate > signatures from the WoT, here there is no need of WoT and you could just > say amazon to connect you with one key and to pay with [some private key > you gave the corresponding public key to your bank]. > >>> Then, the company should not run a keyserver, but just sign the keys of >> all workers, and check the signature is valid and not revoked on use. >> >> if you sign the identity of the worker, how do you revoke your sign? > > With OpenPGP's revocation signature, that GnuPG gives an ?easy? > interface for? > >> AFAIK you should create a certificate for each worker and then sign >> it, and use that certificate to sign the worker identity, so you can >> revoke the worker certificate. That, to me, seems a bit more complex, >> but on the bright side can be implemented right now. > > No, currently you'd just sign the worker's masterkey with the company's > masterkey, and when the worker no longer works here you'd revoke the > previous signature. > >> A company may want to run their own server maybe because they don't >> want to expose all the certificate for all their worker. To me make a >> lot of sense, especially for sector like security or social care. > > Indeed they may want to, but it is not (or maybe ?should not??) be a > critical piece of the infrastructure: current keyserver software is most > likely not as secure as the cryptography underlying signatures is. > >>> Do you mean not exposing your public identity key or your private >> identity key? >> >> private identity key. Your public identity is well known, the private >> key should be the most safe thing you have. Losing it is like losing >> your documents. >> Well, actually my end goal is to REPLACE documents (like passport) >> with this system. This also help you to understand why is so important >> to protect the identity, but still have a way to be able to issue it >> to minor services for everyday usage. > > Well, you should never expose your private identity key to anyone, or > any other private key linked to you for that matter. > > To take back your example with amazon and your bank, there is absolutely > no need that the private key you give amazon is linked to your identity, > it just need correspond to the public key you gave your bank. You could > even not use public-key crypto, and only give the same 128-bit token to > both sides, and it should be enough (though your bank may insist on > public-key cryptography so that they can have a proof that such key > issued such payment order). > > If you don't want to access your bank's website, you could just give a > 128-bit token signed with your signing key or whatever to amazon > (disclaimer: I'm writing this without thinking about all the security > implications right now, just throwing an idea out in the air). > >>> If you mean private identity key, then there is already no need to >> expose any private part of any key when signing >> >> you dont expose it *mathematically*, bu you expose it to the outside >> world, where you can lose it, got it stolen.. and then all your >> identity and related is compromised, and you have no easy or automated >> way to get back the ownership. >> Losing the SIGN key is scary, but as soon as you get home (or you >> alert your "trust" person, that just have the revoke key for the SIGN >> key, so it does not need to be *that* trusty), you will have your >> master key revoked, and as soon as you create a new SIGN key, you will >> *automatically* regain access to all services. > > I think I no longer get what you call masterkey. > >>> I think I sort of get what you are doing, but don't really get the >> advantage compared to things already possible with OpenPGP (with C >> subkeys), that is: >> >> this is interesting, i cant find much on how certification key work; >> but if they can be used to create and revoke other key in the behalf >> of the master key, then seems to be exactly what I'm looking for. I >> just can't find anything, and I guess i'll have to find it on the RFC > > It doesn't allow to create other keys on behalf of the masterkey (or at > least that's not how I'm seeing it to work). > > It just allows to delegate some more power from the masterkey to the > subkeys. > > Currently, you can delegate signing and encryption powers from masterkey > to subkeys. The only operation missing, from what I can tell, is > Certification, that is signing someone else's masterkey to strengthen > the WoT. > > That is to mean you can already have a signing subkey per device if you > want to (encryption is a bit harder, but out of the scope of this > discussion if I understood where you're going). From dgouttegattat at incenp.org Mon Sep 11 00:01:24 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 11 Sep 2017 00:01:24 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <8d12a6cb-ff15-f13c-ea40-d3a8143a273b@incenp.org> Message-ID: <6676939a-442a-d782-905d-1f531ff1a2d8@incenp.org> On 09/10/2017 11:32 PM, lesto fante wrote: > just to be sure I don't misunderstand, the level 2 key cannot revoke > the level 1 key, right? No it cannot. And to be more precise, in the situation where the level-2 key is compromised, you actually do not revoke the level-2 key itself (using the corresponding level-2 private key), you revoke the trust signature on the level-2 key (using the level-1 private key). The level-2 will then cease to be valid in the eyes of your correspondents. > My goal is to bring good privacy at the housewife, while making the > process even more easier (as it will be as easy as using a wallet). So you want to bring privacy to the housewife while at the same time make her rely on someone else (the "son/trust person" you mentioned) to manage her privacy? But is it still privacy then? If I had to trust someone else with my privacy, I think I would rather trust the faceless algorithms running in a Google datacenter than a person close to me and who keep telling me "don't worry, I'm taking care of everything, just relax." (If you think that your son or your "trust person" cannot betray you, well, by definition you can be betrayed *only* by someone you trust.) GnuPG (and free software in general) should empower users to take privacy in their own hands, not incite then to rely on a "trust person". That's only my opinion, of course. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lestofante88 at gmail.com Mon Sep 11 01:09:41 2017 From: lestofante88 at gmail.com (lesto fante) Date: Mon, 11 Sep 2017 01:09:41 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <6676939a-442a-d782-905d-1f531ff1a2d8@incenp.org> References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <8d12a6cb-ff15-f13c-ea40-d3a8143a273b@incenp.org> <6676939a-442a-d782-905d-1f531ff1a2d8@incenp.org> Message-ID: >And to be more precise, in the situation where the level-2 key is compromised, you actually do not revoke the level-2 key itself (using the corresponding level-2 private key), you revoke the trust signature on the level-2 key (using the level-1 private key). The level-2 will then cease to be valid in the eyes of your correspondents. this is perfect, it also mean that revoking level2 i would also invalidate all its subkeys. I will look into it. >So you want to bring privacy to the housewife while at the same time make her rely on someone else (the "son/trust person" you mentioned) to manage her privacy? But is it still privacy then? the idea is that the system is very simple for the end user, as of now, you really have to KNOW exactly what you are doing, and if you get something wrong you compromise your whole security; this scare away all this less-than-perfect user (such as myself), the more the system is error-resistant, the more likely they jump in, and do themselves. In reality the great improvement is more on the user interface side, but i need to understand what i can do on the lower level, and build up around it. A housewife that need help to set this up (aka, install the software, connect the hw wallet and press one button and add a password), is one that need help to set up his homebank, email and socials; she would use the same user/password for all the services, with the password probably "password" or something else in the list of the 100 most used password. So she is not really loosing any privacy over this; actually we are making the system safer even for her. 2017-09-11 0:01 GMT+02:00 Damien Goutte-Gattat : > On 09/10/2017 11:32 PM, lesto fante wrote: >> >> just to be sure I don't misunderstand, the level 2 key cannot revoke >> the level 1 key, right? > > > No it cannot. > > And to be more precise, in the situation where the level-2 key is > compromised, you actually do not revoke the level-2 key itself (using the > corresponding level-2 private key), you revoke the trust signature on the > level-2 key (using the level-1 private key). The level-2 will then cease to > be valid in the eyes of your correspondents. > > >> My goal is to bring good privacy at the housewife, while making the >> process even more easier (as it will be as easy as using a wallet). > > > So you want to bring privacy to the housewife while at the same time make > her rely on someone else (the "son/trust person" you mentioned) to manage > her privacy? But is it still privacy then? > > If I had to trust someone else with my privacy, I think I would rather trust > the faceless algorithms running in a Google datacenter than a person close > to me and who keep telling me "don't worry, I'm taking care of everything, > just relax." > > (If you think that your son or your "trust person" cannot betray you, well, > by definition you can be betrayed *only* by someone you trust.) > > GnuPG (and free software in general) should empower users to take privacy in > their own hands, not incite then to rely on a "trust person". > > That's only my opinion, of course. > > Damien > From philip.jackson at nordnet.fr Mon Sep 11 18:57:16 2017 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Mon, 11 Sep 2017 18:57:16 +0200 Subject: Unable to sign or decrypt with card In-Reply-To: <87wp56sj0u.fsf@wheatstone.g10code.de> References: <87wp56sj0u.fsf@wheatstone.g10code.de> Message-ID: On 10/09/17 16:52, Werner Koch wrote: > On Sat, 9 Sep 2017 14:54, philip.jackson at nordnet.fr said: > >> Suggestions as to how to check and correct this situation would be >> appreciated. > > Newer versions of gpg should print a better error message; at least with > -v. I guess that your pinentry is not installed or can't be used. I don't think the pinentry is a problem. When I launch the command to decrypt a document, the pinentry dialog box opens, I enter the pin and click ok and the operation promptly fails. > Do you have the option "pinentry-program" in your gpg-agent.conf ? Then > check that it is really there. I looked in gpg-agent.conf and found that I had commented out the pinentry-program line back around March 2015 when I was trying to move from gpg 2.0.22 to 2.0.26 and I was getting two pinentry dialog boxes when trying to decrypt emails in enigmail. Commenting out the line in gpg-agent.conf solved this problem at the time and the file has remained like this ever since. However, just to check, I uncommented it (and pinentry-gtk-2 is installed on the machine) : pinentry-program /usr/bin/pinentry-gtk-2 and tried again to decrypt the document. The only difference was that this time the pinentry dialog box carried the name of 'pinentry-gtk-2' instead of being anonymous. But the operation failed just the same. > > Is the environment variable GPG_TTY set as describen in the manual? GPG_TTY=/dev/pts/6 Which doesn't mean much to me, I'm afraid. > Do you get a prompt when calling "pinentry"? If so, does it show up a > window after entering "getpin"? Yes, pinentry gives 'OK Pleased to meet you' and a prompt. Then entering getpin produces the pinentry box in which I enter the pin and the next line is D zzzzzz (where zzzzzz is the pin I entered) followed by OK > > More information about gpg-agent an pinentry interaction can be seen by > putting > > --8<---------------cut here---------------start------------->8--- > log-file /somewhere/gpg-agent.log > verbose > debug ipc > debug-pinentry > --8<---------------cut here---------------end--------------->8--- > > into gpg-agent.conf and restarting gpg-agent ("pkill gpg-agent" or > "gpgconf --kill gpg-agent"). OK, I added this to gpg-agent.conf and I now have a log file of a single attempt to decrypt a sample file with command : gpg2 -v -o encrypt-decrypt -d encrypt_test.gpg This produced the pinentry dialog into which I put my pin and the operation promptly failed with this on the screen : # off=0 ctb=85 tag=1 hlen=3 plen=268 :pubkey enc packet: version 3, algo 1, keyid 79D467BFF5DF6C91 data: [2048 bits] gpg: public key is 0x79D467BFF5DF6C91 gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: using subkey 0x79D467BFF5DF6C91 instead of primary key 0x26BD500A23543A63 # off=271 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey 0x79D467BFF5DF6C91 instead of primary key 0x26BD500A23543A63 gpg: encrypted with 2048-bit RSA key, ID 0x79D467BFF5DF6C91, created 2014-10-28 "Philip Jackson (Jan 2013 +) " gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key I have the log file which I attach. It shows a number of reports of the same error (lines 89,91,97,99,101) ERR 83886254 Unknown option , before it asks me for the pin (line 111). It says 'confidential data not shown' three times but I only entered the pin once. Can you determine anything from this ? Regards, Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-agent-failed-decrypt.log Type: text/x-log Size: 10382 bytes Desc: not available URL: From lestofante88 at gmail.com Sun Sep 10 20:59:04 2017 From: lestofante88 at gmail.com (lesto fante) Date: Sun, 10 Sep 2017 20:59:04 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <0d97834c-ba3b-1906-faa3-32419031bfdc@gaspard.io> References: <87ingq39it.fsf@fifthhorseman.net> <0d97834c-ba3b-1906-faa3-32419031bfdc@gaspard.io> Message-ID: >(you forgot to Cc: the list, I'm Cc-ing back as it doesn't seem voluntary to me) yes i did with all of my email. I *should* have reply to all by default, but seems not the case. >I still don't get why you would want amazon and your bank to see the same identity key Mainly to be able to replace ANY other key in a completely automated fashion, starting by having ONLY the identity key. Imagine to lose the device with the SIGN and many or all APPLICATION key; you will have to revoke the master key, but only using the IDENTITY key. Oh, and then issue a new SIGN key, that will issue new APPLICATION key (that your wallet will distribute to the devices that require them, but again, that is not part of gpg) >If you don't want to access your bank's website, you could just give a 128-bit token signed with your signing key or whatever to amazon this seems to me to be at risk of re-usability, or it is a one-time token, then if you want something that buy biscuit for you, like a "dash button", he need to have your amazon AND bank key.. and you DON'T want to give the bank key to the dash button. >I think I no longer get what you call masterkey. this is why I didn't use anywhere this term, and i clearly stated my terminology :) >That is to mean you can already have a signing subkey per device if you want to I'm outside for a late party, someone show me the new cool app with gpg AND market support, and want to show me, so he ask me to join so we can be friend and check our signature. case 1: Oh, too bad, i don't have my smartcard with me. I never have it with me when i need it! case 2: Oh, too bad, i lost my smartcard somewhere on the dancefloor. Why did i even take it with me?! Now i have to MANUALLY give a new key to ALL MY SERVICE AND PEOPLE. case 3: you use your public and private key with the app, that is just a scam, and as your private key is also connected to you facebook and bank, the app will shap itself on FB and then clean your bank account. Yes, you can still charge back the transaction, but until the bank does not approve it, you have no money. Its not a nice situation. with this system: you issue a new key for the service. As it is connected with your identity, it will automatically be recognized by your bank as soon as it get uploaded to the key server. The key get automatically.. 10?? so you can but the nice premium-feature, and even if it was scam, charging back is still an option. 2017-09-10 20:27 GMT+02:00 Leo Gaspard : > (you forgot to Cc: the list, I'm Cc-ing back as it doesn't seem > voluntary to me) > > On 09/10/2017 07:50 PM, lesto fante wrote: >>> Besides, there is no >> need to give the same masterkey to your bank and your smart fridge, as >> they will (likely?) not participate in the Web of Trust anyway >> >> not the same masterkey, but the same identity. Very important for >> changing the key transparently. > > By ?masterkey? I meant ?most privileged key? (that is what you call > ?identity key?). I'll try to use your terminology henceforth. > >> You are right, I don't need the same identity for the fridge and the >> bank.. until I want the fridge to buy the milk. >> Or, for a more realistic example, i want my bank key and amazon key to >> be different, but to point to the same identity.. make more sense now? >> Yes, i could do it with the current master key and sub-key, but with >> the lack of a "master-master" key, a compromised master key would be a >> hassle to manage (that remember, is on the user device.. probably the >> smartphone. not exactly the safest device, and something quite easy to >> lose or get stolen). > > I still don't get why you would want amazon and your bank to see the > same identity key. The only point of an identity key is to accumulate > signatures from the WoT, here there is no need of WoT and you could just > say amazon to connect you with one key and to pay with [some private key > you gave the corresponding public key to your bank]. > >>> Then, the company should not run a keyserver, but just sign the keys of >> all workers, and check the signature is valid and not revoked on use. >> >> if you sign the identity of the worker, how do you revoke your sign? > > With OpenPGP's revocation signature, that GnuPG gives an ?easy? > interface for? > >> AFAIK you should create a certificate for each worker and then sign >> it, and use that certificate to sign the worker identity, so you can >> revoke the worker certificate. That, to me, seems a bit more complex, >> but on the bright side can be implemented right now. > > No, currently you'd just sign the worker's masterkey with the company's > masterkey, and when the worker no longer works here you'd revoke the > previous signature. > >> A company may want to run their own server maybe because they don't >> want to expose all the certificate for all their worker. To me make a >> lot of sense, especially for sector like security or social care. > > Indeed they may want to, but it is not (or maybe ?should not??) be a > critical piece of the infrastructure: current keyserver software is most > likely not as secure as the cryptography underlying signatures is. > >>> Do you mean not exposing your public identity key or your private >> identity key? >> >> private identity key. Your public identity is well known, the private >> key should be the most safe thing you have. Losing it is like losing >> your documents. >> Well, actually my end goal is to REPLACE documents (like passport) >> with this system. This also help you to understand why is so important >> to protect the identity, but still have a way to be able to issue it >> to minor services for everyday usage. > > Well, you should never expose your private identity key to anyone, or > any other private key linked to you for that matter. > > To take back your example with amazon and your bank, there is absolutely > no need that the private key you give amazon is linked to your identity, > it just need correspond to the public key you gave your bank. You could > even not use public-key crypto, and only give the same 128-bit token to > both sides, and it should be enough (though your bank may insist on > public-key cryptography so that they can have a proof that such key > issued such payment order). > > If you don't want to access your bank's website, you could just give a > 128-bit token signed with your signing key or whatever to amazon > (disclaimer: I'm writing this without thinking about all the security > implications right now, just throwing an idea out in the air). > >>> If you mean private identity key, then there is already no need to >> expose any private part of any key when signing >> >> you dont expose it *mathematically*, bu you expose it to the outside >> world, where you can lose it, got it stolen.. and then all your >> identity and related is compromised, and you have no easy or automated >> way to get back the ownership. >> Losing the SIGN key is scary, but as soon as you get home (or you >> alert your "trust" person, that just have the revoke key for the SIGN >> key, so it does not need to be *that* trusty), you will have your >> master key revoked, and as soon as you create a new SIGN key, you will >> *automatically* regain access to all services. > > I think I no longer get what you call masterkey. > >>> I think I sort of get what you are doing, but don't really get the >> advantage compared to things already possible with OpenPGP (with C >> subkeys), that is: >> >> this is interesting, i cant find much on how certification key work; >> but if they can be used to create and revoke other key in the behalf >> of the master key, then seems to be exactly what I'm looking for. I >> just can't find anything, and I guess i'll have to find it on the RFC > > It doesn't allow to create other keys on behalf of the masterkey (or at > least that's not how I'm seeing it to work). > > It just allows to delegate some more power from the masterkey to the > subkeys. > > Currently, you can delegate signing and encryption powers from masterkey > to subkeys. The only operation missing, from what I can tell, is > Certification, that is signing someone else's masterkey to strengthen > the WoT. > > That is to mean you can already have a signing subkey per device if you > want to (encryption is a bit harder, but out of the scope of this > discussion if I understood where you're going). From dkg at fifthhorseman.net Tue Sep 12 18:01:11 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Sep 2017 12:01:11 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> Message-ID: <87poavzz20.fsf@fifthhorseman.net> On Sun 2017-09-10 21:17:33 +0200, lesto fante wrote: > here i want to AUTOMATE, make this thing MORE EASY to use than a > common password approach. I understand that you're trying to make *your* life easier. But the choices you make also have an impact on the people who look at your public keys. An OpenPGP certificate with a single master certification-capable public key and several different signing/encrypting/authenticating subkeys is already pretty complex, but we have toolchains that are (starting to be) able to deal with that situation. If you try to introduce this multi-level arrangement, you're pretty likely to force *other* people (whose toolchains you have even less control over) into situations that will be LESS EASY and NON-AUTOMATABLE. I don't think this is a great tradeoff for the ecosystem. Keep it simple :) > This approach MUST be "housewife proof"; Please don't default to using a woman as the canonical example non-technical/clueless user. The computer security community already has enough problems with gender bias. It's unfriendly and unwelcoming in ways that we need to outgrow. And it's wrong -- real-world housewives (and "moms" and "grandmas" to name a few other common sexist "female clueless user" tropes) are often expected to figure out many things that are outside of their field of expertise and then aren't given any intellectual credit for navigating complex and changing requirements and exepctations. If you need an example of someone who doesn't really understand things at a technical level but needs to have stuff Just Work for them anyway, i've seen Cory Doctorow suggest using "your boss" as the canonical example :P All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From lestofante88 at gmail.com Tue Sep 12 19:39:27 2017 From: lestofante88 at gmail.com (lesto fante) Date: Tue, 12 Sep 2017 19:39:27 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <87poavzz20.fsf@fifthhorseman.net> References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <87poavzz20.fsf@fifthhorseman.net> Message-ID: > I understand that you're trying to make *your* life easier. i think my user-case if one of the most common, especially if we want to create something like a state-provided identity (on you smartacard-document), that want want to make easily usable on everyday services (remeber, all services is really "pointing" to the master identity, so any subkey can be reissued without having to re-register in the system. >An OpenPGP certificate with a single master certification-capable public key and several different signing/encrypting/authenticating subkeys is already pretty complex I am not aware of the implementation, but I see 2 issue there: One is how to create a subkey of a subkey; as i know the maskerkey sign the subkey, so we can do the same here, we have to define where the information about the sign will be stored, or a flag to tell this is a sub-sub key. The second problem is the sharing of the keys and revoke certificate, something that is already solved by keyserver. >we have toolchains that are (starting to be) able to deal with that situation. If this is in the standard, and the standard is used, then is likely that other tool will implement it. In general, we can be almost completely retro-compatible if engineered in the right way (i'm thinking, level 1 key is seen by legacy as invalid(?) key, level 2 as master key, and level 2 as subkey of master. at this point, when we revoke level 1 key, to keep retrocompatibility we always have to issue a revoke for all level 2 key first. >Keep it simple :) How would you implement this? > Please don't default to using a woman as the canonical example non-technical/clueless user. AFAIK housewife does not have any male translation, so it is technically genderless :) and why i can't use a female gender, but then discriminate against a role? Sterile discussion aside, lets agree on a real definition like Average Internet User, or AIU for short. Characteristic (based on personal experience, so lets agree on that) are: - its main device is the smartphone, where basically all the login are stored. - generally stick with a "one password for all" - is willing to make a bit more secure like 2 step authentication, but setup is scary if take more than 2 passages - understand the rick of phishing and opening attachment BUT - open the .ppt sent by his friend in the email chain - download that app too see X for free or get free life for the game Y - always click the wrong download button before getting what he is looking for Basically: he keep important stuff on his device. That has relatively high possibility to be violated or lost, so WE need to make sure we have a backup solution for him. (in my case, with the level1 key, the user just have to revoke and reissue a new level 2 key! and he does not even need to update the "password" or "key" to all its service, if compatible with this system otherwise is the same old game as always.) 2017-09-12 18:01 GMT+02:00 Daniel Kahn Gillmor : > On Sun 2017-09-10 21:17:33 +0200, lesto fante wrote: >> here i want to AUTOMATE, make this thing MORE EASY to use than a >> common password approach. > > I understand that you're trying to make *your* life easier. But the > choices you make also have an impact on the people who look at your > public keys. An OpenPGP certificate with a single master > certification-capable public key and several different > signing/encrypting/authenticating subkeys is already pretty complex, but > we have toolchains that are (starting to be) able to deal with that > situation. > > If you try to introduce this multi-level arrangement, you're pretty > likely to force *other* people (whose toolchains you have even less > control over) into situations that will be LESS EASY and > NON-AUTOMATABLE. I don't think this is a great tradeoff for the > ecosystem. > > Keep it simple :) > >> This approach MUST be "housewife proof"; > > Please don't default to using a woman as the canonical example > non-technical/clueless user. The computer security community already > has enough problems with gender bias. It's unfriendly and unwelcoming > in ways that we need to outgrow. And it's wrong -- real-world > housewives (and "moms" and "grandmas" to name a few other common sexist > "female clueless user" tropes) are often expected to figure out many > things that are outside of their field of expertise and then aren't > given any intellectual credit for navigating complex and changing > requirements and exepctations. > > If you need an example of someone who doesn't really understand things > at a technical level but needs to have stuff Just Work for them anyway, > i've seen Cory Doctorow suggest using "your boss" as the canonical > example :P > > All the best, > > --dkg From rjh at sixdemonbag.org Tue Sep 12 21:07:57 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 12 Sep 2017 15:07:57 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <87poavzz20.fsf@fifthhorseman.net> Message-ID: <89678963-62ce-62e3-c355-ccf001c5ec37@sixdemonbag.org> > i think my user-case if one of the most common, especially if we want > to create something like a state-provided identity... Until and unless you present a usability study involving 100+ people composing a representative sample of an identifiable community, you don't know a thing. Over the last 25 years I cannot count the number of people who were sure their use case was common, or their pet idea would result in widespread GnuPG usage, or what-have-you. And without exception, not one has been successful. I understand you have a belief that your use case is common. Until and unless you present a study showing that it actually *is* common, I will not share in your belief. I suspect many people here share in this sentiment. >> Please don't default to using a woman as the canonical example > non-technical/clueless user. > > AFAIK housewife does not have any male translation, so it is > technically genderless :) Househusband. English has used this word since 1858. https://www.merriam-webster.com/dictionary/househusband Either way, please don't use housewives or househusbands as examples of "clueless users". They are far from it. They may lack sophisticated technical skills, but that's not the same as being foolish or clueless. If you want people to use your product, you need to start by respecting your users. > Sterile discussion aside, lets agree on a real definition like Average > Internet User, or AIU for short. No. Big, emphatic, *NO*. There is no average user. Please repeat that sentence until it sticks. There is no average user. Average users don't exist. They're myths. Unicorns. And if you design for an average user, you're going to make it a poor experience for essentially everyone. During WW2, the United States government spent a lot of money doing measurements of fighter pilots. Height, weight, build, length of arms, length of legs, size of their hands, and more. With all this data they built cockpits that would be comfortable for 90% of pilots. Pilots hated their cockpits because they were terribly uncomfortable. Real people fell outside of the 90% mark in at least a few categories. In the course of making a cockpit that would fit almost everyone comfortably, it fit almost no one comfortably. Modern fighter jets have instead embraced customizability. The American F-15E fighter can accommodate pilots from 5'4" to 6'6" (1.62m to 1.98m), a variety of builds, reaches, and more. By recognizing there was no such thing as an average pilot, the designers opened the door to make a cockpit that was comfortable for the vast majority of users. Your "average internet user" is a 1940s-style way of thinking. We need to do better than that. From ndk.clanbo at gmail.com Tue Sep 12 22:25:59 2017 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 12 Sep 2017 22:25:59 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <245349db-0466-c191-84cc-4d95255676e8@incenp.org> <4c86d83e-c4d1-5d33-c40e-83374e0a5de7@incenp.org> <87poavzz20.fsf@fifthhorseman.net> Message-ID: <41aebdd0-ef0b-83d0-1598-67a29879f8cd@gmail.com> Il 12/09/2017 19:39, lesto fante ha scritto: > i think my user-case if one of the most common, especially if we want > to create something like a state-provided identity (on you > smartacard-document), that want want to make easily usable on everyday > services (remeber, all services is really "pointing" to the master > identity, so any subkey can be reissued without having to re-register > in the system. Such a thing already exists, at least here in Italy: CIE/CNS. X509-based certs. It's got its own set of weaknesses, but since you're thinking about a trusted third party (the State), X509 is a better fit. Possibly extended by another applet that handles service-tokens (actually wrapped private keys + metadata). Anyway that's something that IMVHO does not fit well with GPG. Just my ?.02 ... BYtE, Diego From ryan at splintermail.com Tue Sep 12 21:07:25 2017 From: ryan at splintermail.com (ryan at splintermail.com) Date: Tue, 12 Sep 2017 14:07:25 -0500 Subject: Explicit command for particular behavior Message-ID: Hi Gnupg-Users, I am developing an email service that automatically gpg-encrypts all email that a user recieves before it is written to disk. To manage this reasonably, I was developing a tool for users to submit their public key, as output from: gpg --export --armored some_key_id > keyfile But then I wanted perform some basic checks on the file submitted, and I found this fantastic behavior: cat keyfile | gpg --with-colons --with-fingerprints which outputs something that is stable and easily parsable. Except... It also gives me the following error: gpg: WARNING: no command supplied. Trying to guess what you mean ... But I tried literally every command from `gpg --dump-options`, and nothing replicated the output I needed without the same error. So... is there a command that explicitly calls for the behavior I want? Ryan PS: I also discovered that gpgme is the "correct answer" to my problem, but nonetheless I am curious why there is no command for this desired output. From rick at nakroshis.com Wed Sep 13 02:45:17 2017 From: rick at nakroshis.com (Rick Nakroshis) Date: Tue, 12 Sep 2017 20:45:17 -0400 Subject: Explicit command for particular behavior In-Reply-To: <59b84df5.ca17190a.f202.dc6cSMTPIN_ADDED_MISSING@mx.google.com> References: <59b84df5.ca17190a.f202.dc6cSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Tue, Sep 12, 2017 at 3:07 PM, wrote: > Hi Gnupg-Users, > > I am developing an email service that automatically gpg-encrypts all > email that a user recieves before it is written to disk. To manage this > reasonably, I was developing a tool for users to submit their public > key, as output from: > > gpg --export --armored some_key_id > keyfile > > But then I wanted perform some basic checks on the file submitted, and I > found this fantastic behavior: > > cat keyfile | gpg --with-colons --with-fingerprints > > which outputs something that is stable and easily parsable. Except... > It also gives me the following error: > > gpg: WARNING: no command supplied. Trying to guess what you mean ... > > But I tried literally every command from `gpg --dump-options`, and > nothing replicated the output I needed without the same error. > > > So... is there a command that explicitly calls for the behavior I want? > > Ryan > Ryan, What version of GPG are you using? I used v2.2.0 and had to make some minor changes --armor instead of --armored --fingerprint instead of --with-fignerprints After those changes, it worked just fine, and did output four lines that were nicely parseable and without any error messages. Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Sep 13 10:36:35 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Sep 2017 10:36:35 +0200 Subject: Explicit command for particular behavior In-Reply-To: (ryan@splintermail.com's message of "Tue, 12 Sep 2017 14:07:25 -0500") References: Message-ID: <87bmmfj8q4.fsf@wheatstone.g10code.de> On Tue, 12 Sep 2017 21:07, ryan at splintermail.com said: > gpg --export --armored some_key_id > keyfile (Please try to use the fingerprint instead of the key_id.) > But then I wanted perform some basic checks on the file submitted, and I > found this fantastic behavior: > > cat keyfile | gpg --with-colons --with-fingerprints There is actually a better way since 2.1.23: gpg --with-colons --import-options show-only --import From lestofante88 at gmail.com Thu Sep 14 00:20:57 2017 From: lestofante88 at gmail.com (lesto fante) Date: Thu, 14 Sep 2017 00:20:57 +0200 Subject: [Feature Request] Multiple level subkey Message-ID: >Such a thing already exists, at least here in Italy: CIE/CNS. X509-based certs. exactly, this is what started the idea; we have no power over those certificate for revoke, and i have no idea if a new certificate is issued if you loose your document. What I found out is that the CA seems to be region-based, so i will have to track all of them. If you know something more, I am very interesting to hear, all the info i got is pieces found here and there. I also hope the same apply on the rest of the EU, since AFAIK that certificate is on the European Health Insurance Card. BUT, of course using a card reader is not possible, especially if we think the smartphone as main device. So would be nice if somehow the certificate can sign (and revoke! that is also important!) a "normal" key, that is stored on the phone, and act as main key that generate the subkey for all the application requiring it. All the application save the user by the "certificate" identity, so even changing key the user is automatically recognized. Do you think this is feasible and i should research in this direction? >Anyway that's something that IMVHO does not fit well with GPG. Can you explain why? also, i said in my first email i am not sure there is the right place, but i didn't know anywhere else where to have this discussion, so tips on this regards are also appreciated. From lestofante88 at gmail.com Thu Sep 14 01:20:06 2017 From: lestofante88 at gmail.com (lesto fante) Date: Thu, 14 Sep 2017 01:20:06 +0200 Subject: [Feature Request] Multiple level subkey Message-ID: >Until and unless you present a usability study involving 100+ people composing a representative sample of an identifiable community, you don't know a thing. * I think * is NOT * I know *. I may be wrong: I don't care. First of all i want to implement this for myself, and if i'm right and is something that people like, that is good for them. I will expose my reasoning instead; unfortunately i don't have the resources or knowledge for a full study. - smartphone outnumber pc since 2011 (http://www.marketwatch.com/story/one-chart-shows-how-mobile-has-crushed-pcs-2016-04-20) - smartphone are already carried everyday by most people owning them (http://www.nydailynews.com/life-style/addicted-phones-84-worldwide-couldn-single-day-mobile-device-hand-article-1.1137811) - smartphone have NFC, BT, WiFi, making contacless payment or key exchange extremly easy, convenient, and fast. In fact, i know payment and even public transport access by NFC is already a reality. (no source needed, i hope) - smartphone are easy to loose or get stolen (45% of 18-24 years hold has lost at least one phone according https://www.statista.com/statistics/241365/us-cell-phone-users-whose-device-has-been-lost-or-stolen-by-age-group/) - many smartphone are not safe (http://thehackernews.com/2016/08/hack-android-phone.html) - some documents in different country already come with a personal certificate/key bound to the person My idea is to make possible for the everyday user to add/manage new services with a main password (by using the level 2 key, encrypted), accessing services eventually passwordless (level 3 key), but in case of the loss of the device, reissue all certificate in a automatic fashion on the new device, staring from the safe key describing the original identity (level1) Now, from the *user* point of view, I think we can all agree that the reissuing of the key is quite a pain, and having safe way to do it automatically is quite nice. but no stat on that. On the server side, we already have something going in the right direction with openID (but i don't think can be made transparent-compatible, that is another big discussion) >And without exception, not one has been successful. better one more try, that one less >Househusband. English has used this word since 1858. TIL >They may lack sophisticated technical skills, but that's not the same as being foolish or clueless. But my target is not fools or clueless, my target is who is lacking the technical skill. For those person is all about convenience; 50% of android user does NOT lock the phone (https://www.elie.net/blog/survey-most-people-dont-lock-their-android-phones-but-should). Since apple has implemented touchID, they say >80% of the user use it. (http://appleinsider.com/articles/16/04/19/average-iphone-user-unlocks-device-80-times-per-day-89-use-touch-id-apple-says) This, in my opinion, is exactly the target, make the deploy of the key easier, especially in case of device loss (aka level 2 and 3 key compromised) >Your "average internet user" is a 1940s-style way of thinking. We need to do better than that. Then explain FB, google, youtube, amazon... all of them does NOT provide a great deal of personalization, if at all. UX, usability, all is about create a "average user" out of your target audience, and make things work for most of them. It is extremely hard to do, but now we have much more literature. From rjh at sixdemonbag.org Thu Sep 14 04:57:58 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 Sep 2017 22:57:58 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: >> Your "average internet user" is a 1940s-style way of thinking. We need to do better than that. > > Then explain FB, google, youtube, amazon... all of them does NOT > provide a great deal of personalization, if at all. They all provide intensely personalized experiences. Just because they don't expose the dials and switches to you doesn't mean they don't exist. As an example: Google Chrome scans the content of webpages you visit, and uses that to guide autocomplete in the search bar. Your autocomplete settings are automatically personalized based on your browsing history with no user intervention needed. Automatic personalization of user experience based on the software learning the user's behavior is pretty much the gold standard in UX design nowadays. It's a commendable goal and worth pursuing. From gniibe at fsij.org Thu Sep 14 07:26:07 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Sep 2017 14:26:07 +0900 Subject: Unable to sign or decrypt with card In-Reply-To: References: <87wp56sj0u.fsf@wheatstone.g10code.de> Message-ID: <87zi9xsvf4.fsf@iwagami.gniibe.org> Philip Jackson wrote: > I have the log file which I attach. > > It shows a number of reports of the same error (lines 89,91,97,99,101) > ERR 83886254 Unknown option , before it asks me for the pin > (line 111). It says 'confidential data not shown' three times but I only > entered the pin once. > > Can you determine anything from this ? Not much. It fails just after sending a command to the card. It seems that there is some communication problem between host and card reader. How 'gpg --card-status' works? You can try to debug scdaemon by having .gnupg/scdaemon.conf: ============================= debug-level guru debug-all verbose debug-ccid-driver log-file /run/user/1000/scd.log ============================= Here is what we can see in your log. > 2017-09-11 18:10:21 gpg-agent[8972] gpg-agent (GnuPG) 2.1.11 started [...] gpg-agent started. > 2017-09-11 18:10:22 gpg-agent[8972] no running SCdaemon - starting it [...] And then, scdaemon started after PKDECRYPT command from gpg to gpg-agent. > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 -> SERIALNO > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- S SERIALNO D2760001240102000005000028700000 0 > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- OK [...] Card works fine to answer its serial number. > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 -> PKDECRYPT OPENPGP.2 > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- INQUIRE NEEDPIN ||Please enter the PIN > 2017-09-11 18:10:22 gpg-agent[8972] starting a new PIN Entry [...] gpg-agent asks PKDECRYPT command to scdaemon, and scdaemon inquires PIN for the authentication. > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> SETDESC Please enter the PIN > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 <- OK > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> SETPROMPT PIN > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 <- OK > 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> [[Confidential data not shown]] > 2017-09-11 18:10:23 gpg-agent[8972] SIGUSR2 received - updating card event counter > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 <- [[Confidential data not shown]] > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 <- [[Confidential data not shown]] > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 -> BYE [...] This is interaction between pinentry and gpg-agent. SIGUSR2 (it means: a card is found) comes from scdaemon to gpg-agent, because scdaemon periodically checks if card is inserted. > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 -> END > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 <- ERR 100663395 Operation cancelled > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 -> CAN > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 <- ERR 100663571 Unknown IPC command > 2017-09-11 18:10:30 gpg-agent[8972] smartcard decryption failed: Operation cancelled > 2017-09-11 18:10:30 gpg-agent[8972] command 'PKDECRYPT' failed: Operation cancelled > 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_6 -> ERR 100663395 Operation cancelled [...] gpg-agent sends the PIN to scdaemon (until "END"), and I think that scdaemon sends command to the card through card reader. But it fails. There are two ways to access card reader for GnuPG. One is through PC/SC, and another is internal CCID driver of GnuPG. If it doesn't work well with PC/SC, it's worth to try the internal CCID driver (or vice virsa). -- From peter at digitalbrains.com Thu Sep 14 11:40:59 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 14 Sep 2017 11:40:59 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: <248a0d0a-5f5f-8b92-f951-07def061de24@digitalbrains.com> On 10/09/17 17:23, lesto fante wrote: > Now, I have been pointed out that the sanity card in EU (for non EU; > all EU has the same sanity card.. So you can travel and not have to > worry) come with a certificate inside! On 14/09/17 00:20, lesto fante wrote: > I also hope the same apply on the rest of the EU, since AFAIK that > certificate is on the European Health Insurance Card. Dutch person here; I had no idea what a European Health Insurance Card is. All I have is a credit-card sized piece of plastic that mentions my customer number at OHRA, the insurance company where I have my health insurance. The piece of plastic has a black bar where the magstripe is located, but I'd be very surprised if it's a magstripe. It's just inked to look similar to one. (Never understood why they do that) I've looked on the interwebs what a European Health Insurance Card is, and yes, many Dutch people can request one free of charge. But given that I have never heard of it before, I don't think many people do. And there are insurance companies that don't give them out at all. And even if you got one, the Dutch information about the card says its validity period depends on your insurance company as well, ranging from just the duration of your stay abroad up to maximally one year. This does not sound like an obvious target for Dutch people who want a government-issued certificate. My 2 cents, Peter. PS: Yes, I do travel abroad. But I simply depend on my travel insurance and a "medication passport", which is a document that includes all the standardized names of medication I have to take, in case I lose them. Oh, and my organ donor card for when it really goes wrong :-). -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sandhya.sharma at morpho.com Thu Sep 14 14:26:56 2017 From: sandhya.sharma at morpho.com (SHARMA Sandhya (MORPHO)) Date: Thu, 14 Sep 2017 12:26:56 +0000 Subject: Signing data with user specified Key Message-ID: <48775625fbcf42bfb39e871cb48e564c@Y0032RM.rd1.rf1> Hello, I am using GPG4Win and have to sign data with a specified key through my code in C++.But I didn't find much help on how to specify key for signing data in GPG document. Please find the below lines of code I am using for signing data: error = gpgme_op_sign(context,Plaindata,Signdata,GPGME_SIG_MODE_NORMAL); PRet = (char*)gpgme_strerror(error) ; gpgme_sign_result_t result = gpgme_op_sign_result(context); Thanks & Regards Sandhya Sharma # " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." # -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Sep 14 17:48:37 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Sep 2017 17:48:37 +0200 Subject: Signing data with user specified Key In-Reply-To: <48775625fbcf42bfb39e871cb48e564c@Y0032RM.rd1.rf1> (SHARMA Sandhya's message of "Thu, 14 Sep 2017 12:26:56 +0000") References: <48775625fbcf42bfb39e871cb48e564c@Y0032RM.rd1.rf1> Message-ID: <87fubps2lm.fsf@wheatstone.g10code.de> On Thu, 14 Sep 2017 14:26, sandhya.sharma at morpho.com said: > I am using GPG4Win and have to sign data with a specified key through > my code in C++.But I didn't find much help on how to specify key for > signing data in GPG You need to put the signer into the context. See this secion in the gpgme manual: 7.7.4.1 Selecting Signers ......................... The key or the keys used to create a signature are stored in the context. The following functions can be used to manipulate this list. If no signer has been set into the context a default key is used for signing. -- Function: void gpgme_signers_clear (gpgme_ctx_t CTX) The function ?gpgme_signers_clear? releases a reference for each key on the signers list and removes the list of signers from the context CTX. Every context starts with an empty list. -- Function: gpgme_error_t gpgme_signers_add (gpgme_ctx_t CTX, const gpgme_key_t KEY) The function ?gpgme_signers_add? adds the key KEY to the list of signers in the context CTX. Calling this function acquires an additional reference for the key. [...] There is also an example program: gpgme/tests/run-sign.c Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lestofante88 at gmail.com Thu Sep 14 23:12:30 2017 From: lestofante88 at gmail.com (lesto fante) Date: Thu, 14 Sep 2017 23:12:30 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: > Just because they don't expose the dials and switches to you doesn't mean they don't exist. my goal instead is became as invisible as possible for the end user.he should forget about my app running in the background, of course a password sometimes when he add a new service, but that is all. After this infrastructure is in place, you can decide to DIY every single step and personalize whatever you want. The problem here is the lack of potentiality. But even if you don't agree with my "vision", lets keep it technical; what would be the best way to implement this system in your opinion? 2017-09-14 4:57 GMT+02:00 Robert J. Hansen : >>> Your "average internet user" is a 1940s-style way of thinking. We need to do better than that. >> >> Then explain FB, google, youtube, amazon... all of them does NOT >> provide a great deal of personalization, if at all. > > They all provide intensely personalized experiences. Just because they > don't expose the dials and switches to you doesn't mean they don't exist. > > As an example: Google Chrome scans the content of webpages you visit, > and uses that to guide autocomplete in the search bar. Your > autocomplete settings are automatically personalized based on your > browsing history with no user intervention needed. > > Automatic personalization of user experience based on the software > learning the user's behavior is pretty much the gold standard in UX > design nowadays. It's a commendable goal and worth pursuing. From rjh at sixdemonbag.org Thu Sep 14 23:58:30 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Sep 2017 17:58:30 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> > But even if you don't agree with my "vision", lets keep it technical; > what would be the best way to implement this system in your opinion? Create a GitHub repo and start committing code. What you want to do is not something that's within the scope of the OpenPGP RFC. It's close, but it's not quite there. If you do this, you'll have to go beyond the RFC. So go off, start with a clean sheet of paper, design a system, and start hacking. Probably 95% of the crypto code is already written for you. All you need to do is design a protocol, implement it, and give it to the world. You've already heard a lot of good advice from people here. Now's the time to go off and start committing code. From lestofante88 at gmail.com Fri Sep 15 00:40:11 2017 From: lestofante88 at gmail.com (lesto fante) Date: Fri, 15 Sep 2017 00:40:11 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> References: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> Message-ID: >You've already heard a lot of good advice from people here I got a couple of ideas, but so far the only real information is that I cant do with actual system in place. And one nice idea from a guy to use level of thrust already implemented, but i'm not sure if i understand all of its possible downside, I'm still waiting for an answer. You say that i can use 90% of crypto out there, and you are right, and i WANT to avoid writing code as much as possible. >now's the time to go off and start committing code. hope you are kidding.. I'm not even finished to collect all the information and ideas, then i need to crunch them up, come out with a protocol schema, check with whatever is interested if sound.. if i have to write even a alpha version of a protocol/rfc is going to be HUGE. That is why ii insist to find alternative to avoid writing code, especially on the "cryptography" side IF the crypt was there, and all i needed to do was to add a bit of glue code, then yes, maybe i would be already writing the code. I hope that when and if i will get result, will be fine to share them there to get some feedback 2017-09-14 23:58 GMT+02:00 Robert J. Hansen : >> But even if you don't agree with my "vision", lets keep it technical; >> what would be the best way to implement this system in your opinion? > > Create a GitHub repo and start committing code. > > What you want to do is not something that's within the scope of the > OpenPGP RFC. It's close, but it's not quite there. If you do this, > you'll have to go beyond the RFC. So go off, start with a clean sheet > of paper, design a system, and start hacking. Probably 95% of the > crypto code is already written for you. All you need to do is design a > protocol, implement it, and give it to the world. > > You've already heard a lot of good advice from people here. Now's the > time to go off and start committing code. > From rjh at sixdemonbag.org Fri Sep 15 10:52:32 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 Sep 2017 04:52:32 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> Message-ID: <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> >> now's the time to go off and start committing code. > > hope you are kidding.. I'm not even finished to collect all the > information and ideas, then i need to crunch them up, come out with a > protocol schema, check with whatever is interested if sound.. Nope. Not kidding. The first version of your product will be awful. That's to be expected. Look into PGP 1.0 sometime: it was so terrible PRZ had to basically burn it down and start over. And, you know, *that's okay*. Often, the best way to begin learning how to do something is to go out and do it. Linus Torvalds was a mediocre C programmer who barely understood Minix when he first started working on Linux. PRZ's initial PGP 1.0 was a joke. Pretty much every successful software project you see today started from a bungled beginning, but the people working on the project learned from their mistakes and slowly things became very, very good. The best way to discover what problems you'll have to solve is to go out and encounter them. Once you do that, *then* build solutions. From lestofante88 at gmail.com Fri Sep 15 11:04:16 2017 From: lestofante88 at gmail.com (lesto fante) Date: Fri, 15 Sep 2017 09:04:16 +0000 Subject: [Feature Request] Multiple level subkey In-Reply-To: <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> References: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> Message-ID: I understand what you say, but for now I'm still thinking if use a certificate for lvl1 or a key.. For sure in the next days I want to produce a basic schematic of the system, protocol, expected workflow.. I already attempted something but so far I always changed idea halfway thought. On Fri, Sep 15, 2017, 10:52 Robert J. Hansen wrote: > >> now's the time to go off and start committing code. > > > > hope you are kidding.. I'm not even finished to collect all the > > information and ideas, then i need to crunch them up, come out with a > > protocol schema, check with whatever is interested if sound.. > > Nope. Not kidding. > > The first version of your product will be awful. That's to be expected. > Look into PGP 1.0 sometime: it was so terrible PRZ had to basically > burn it down and start over. And, you know, *that's okay*. > > Often, the best way to begin learning how to do something is to go out > and do it. Linus Torvalds was a mediocre C programmer who barely > understood Minix when he first started working on Linux. PRZ's initial > PGP 1.0 was a joke. Pretty much every successful software project you > see today started from a bungled beginning, but the people working on > the project learned from their mistakes and slowly things became very, > very good. > > The best way to discover what problems you'll have to solve is to go out > and encounter them. Once you do that, *then* build solutions. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.jackson at nordnet.fr Fri Sep 15 00:53:23 2017 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Fri, 15 Sep 2017 00:53:23 +0200 Subject: Unable to sign or decrypt with card In-Reply-To: <87zi9xsvf4.fsf@iwagami.gniibe.org> References: <87wp56sj0u.fsf@wheatstone.g10code.de> <87zi9xsvf4.fsf@iwagami.gniibe.org> Message-ID: <0a21decc-a1e5-3b1a-8e35-0b8195352022@nordnet.fr> On 14/09/17 07:26, NIIBE Yutaka wrote: > Philip Jackson wrote: >> I have the log file which I attach. >> >> It shows a number of reports of the same error (lines 89,91,97,99,101) >> ERR 83886254 Unknown option , before it asks me for the pin >> (line 111). It says 'confidential data not shown' three times but I only >> entered the pin once. >> >> Can you determine anything from this ? > > Not much. It fails just after sending a command to the card. It seems > that there is some communication problem between host and card reader. > > How 'gpg --card-status' works? Card status seems to be ok : gpg --card-status Application ID ...: D2760001240102000005000028700000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00002870 Name of cardholder: Philip Jackson Language prefs ...: en Sex ..............: male URL of public key : [not set] Login data .......: [not set] Private DO 1 .....: [not set] Private DO 2 .....: [not set] Signature PIN ....: forced Key attributes ...: 0R 0R 0R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 406 Signature key ....: 60FF 4A45 7DD4 C4E2 CCAB D98D 5154 49A8 9A99 D8BD created ....: 2014-10-28 23:13:28 Encryption key....: C04C 016C 3460 2B42 CDBB 2566 79D4 67BF F5DF 6C91 created ....: 2014-10-28 23:18:24 Authentication key: [none] gpg: using subkey 0x515449A89A99D8BD instead of primary key 0x26BD500A23543A63 General key info..: pub 2048R/0x515449A89A99D8BD 2014-10-28 Philip Jackson (Jan 2013 +) sec 2048R/0x26BD500A23543A63 created: 2013-01-22 expires: never ssb 2048R/0x2ACB19812A3EC90F created: 2013-01-22 expires: never ssb> 2048R/0x515449A89A99D8BD created: 2014-10-28 expires: never card-no: 0005 00002870 ssb> 2048R/0x79D467BFF5DF6C91 created: 2014-10-28 expires: never card-no: 0005 00002870 > > You can try to debug scdaemon by having .gnupg/scdaemon.conf: > > ============================= > debug-level guru > debug-all > verbose > debug-ccid-driver > log-file /run/user/1000/scd.log > ============================= I created the scdaemon.conf file as you suggested and then ran a decrypt test : gpg2 -v -o encrypt_test_decrypt -d encrypt_test.gpg this failed just as previously stated in the earlier post. The debug log covering the period of this test is attached : scd_decrypterror.log I see on line 377 the request for the PIN and on line 471 that the operation failed. Perhaps there is something you can see which explains the problem ? Thanks for your help. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: scd_decrypterror.log Type: text/x-log Size: 50096 bytes Desc: not available URL: From martini5468 at gmail.com Fri Sep 15 13:13:00 2017 From: martini5468 at gmail.com (martin) Date: Fri, 15 Sep 2017 12:13:00 +0100 Subject: Unable to sign or decrypt with card In-Reply-To: <0a21decc-a1e5-3b1a-8e35-0b8195352022@nordnet.fr> References: <87wp56sj0u.fsf@wheatstone.g10code.de> <87zi9xsvf4.fsf@iwagami.gniibe.org> <0a21decc-a1e5-3b1a-8e35-0b8195352022@nordnet.fr> Message-ID: <92706949-b0de-3160-1151-8ffccdff7b70@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14/09/17 23:53, Philip Jackson wrote: > Card status seems to be ok : > > gpg --card-status > Application ID ...: D2760001240102000005000028700000 > Version ..........: 2.0 > Manufacturer .....: ZeitControl > Serial number ....: 00002870 > Name of cardholder: Philip Jackson > Language prefs ...: en > Sex ..............: male > URL of public key : [not set] > Login data .......: [not set] > Private DO 1 .....: [not set] > Private DO 2 .....: [not set] > Signature PIN ....: forced > Key attributes ...: 0R 0R 0R > Max. PIN lengths .: 32 32 32 > PIN retry counter : 3 0 3 > Signature counter : 406 > Signature key ....: 60FF 4A45 7DD4 C4E2 CCAB D98D 5154 49A8 9A99 D8BD > created ....: 2014-10-28 23:13:28 > Encryption key....: C04C 016C 3460 2B42 CDBB 2566 79D4 67BF F5DF 6C91 > created ....: 2014-10-28 23:18:24 > Authentication key: [none] > gpg: using subkey 0x515449A89A99D8BD instead of primary key > 0x26BD500A23543A63 > General key info..: pub 2048R/0x515449A89A99D8BD 2014-10-28 Philip > Jackson (Jan 2013 +) > sec 2048R/0x26BD500A23543A63 created: 2013-01-22 expires: never > ssb 2048R/0x2ACB19812A3EC90F created: 2013-01-22 expires: never > ssb> 2048R/0x515449A89A99D8BD created: 2014-10-28 expires: never > card-no: 0005 00002870 > ssb> 2048R/0x79D467BFF5DF6C91 created: 2014-10-28 expires: never > card-no: 0005 00002870 Hi Philip, A few weeks ago I experienced a very similar problem to what you describe. I was not able to sign any of my mail with my smart card and I was unable to decrypt files. Output of my gpg --card-status showed the same: Key attributes ...: 0R 0R 0R ... sec rsa4096/0x7BDDCD7C31F200DC created: 2015-11-24 expires:.. I have the exact same card reader at home and when running the status command I would get: Key attributes ...: rsa4096 rsa4096 rsa4096 ... sec> rsa4096/0x7BDDCD7C31F200DC created: 2015-11-24 expires: 2017-11-23 card-no: 0005 0000426B So I just re-checked my card reader at work. As I use the Gemalto PC Twin Reader it turned out that the connection between the USB cable and the card reader was slightly loose. Afterwards I was able to use my card as before. I would suggest (if you haven't tried that already). To try a different machine and/or a different reader combos and see if the problem is not a trivial faulty reader. Regards, Martin -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEXpvIcrLGPB3dYM2b2/3pjiVWvVwFAlm7takACgkQ2/3pjiVW vVweoQ//biDPhktWhhSgCYCtQy1wFTQsSkfss8qvJ1jwmvdZ7FOwAIoUD86yBR9j 8iVW8cOkOIyoOGXrszVpdwp0rylnYnfPxNnPd5Z4njvtaPeWXRoQFRNxIcWjasKA ypSMY/cTasbIk4mTpskjuEjK+XrQNWH1zI2Laj3wbBBVAjQX+CRbUJVHYV7kEhX9 FHWxLc3aPrO4+YF8usDMMW7f9s9q2N5tGSzWo71UDoBjwsc9QJRmParcVi8Il0k4 RxHcjQq9/uLz+YEv1cG/5d9JMGEXSQ/DcLoJAx6nknrUhe8GTZXl3alwRoi7m/Ow dlA+dHv7tX/LO4hh1V2jTr/KyTkB564vzAe6ZU97jjcDf/75XxmrEA/MQfsu7RK/ I+iVRB5pWKVlsGELn2ce+jTSPoB/fmFIIICMUOFSAz7NhzsPBBHQxDs5MSq7GNlP wFhyCewvqB4HVwMjcI07mh7nppT6DwiyGo0aK7XxzECckBtPgfVpWIqcU2fn6p23 nc9qwEcGsD4TqM0fUS4XnRteg/RsPtSIxoaDzlY/LyEr9Z2gDFQKUJmo7Hlsuaq8 FhPbI6b8TOMUq/lCVi4qLJygMqBZpqVT5vJeD1sGfOL8XJcF05EAgI+3++3IiRHU aGrwhL04AYGZClYjMlf9d57NZrL7UeFCGW5fn3sv5aLI7hS7Q0k= =V4i6 -----END PGP SIGNATURE----- From m16+gnupg at monksofcool.net Fri Sep 15 14:41:15 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Fri, 15 Sep 2017 14:41:15 +0200 Subject: [Feature Request] Multiple level subkey In-Reply-To: <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> References: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> Message-ID: On 15.09.2017 10:52, Robert J. Hansen wrote: > Often, the best way to begin learning how to do something is to go out > and do it. While I have nothing against (rapid) prototyping in general, it is not the advisable method for each and every project or person. I prefer spending time designing software, with pencil and paper or what have you, before writing the first lines of code. That helps with figuring out what one is trying to achieve, and the basics of how to achieve it, lowering the risk of getting bogged down in issues of design oversight or of the chosen programming language. This, of course, should best be discussed elsewhere. ;-) -Ralph From rjh at sixdemonbag.org Fri Sep 15 16:57:34 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 Sep 2017 10:57:34 -0400 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: <4c80018a-e31a-fe98-8964-74603140995b@sixdemonbag.org> <7c6cad2f-19c3-da1c-0763-470b203754c9@sixdemonbag.org> Message-ID: > While I have nothing against (rapid) prototyping in general, it is not > the advisable method for each and every project or person. Enthusiastically agreed. > This, of course, should best be discussed elsewhere. ;-) This, as well. :) From gniibe at fsij.org Fri Sep 15 17:19:48 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 16 Sep 2017 00:19:48 +0900 Subject: Unable to sign or decrypt with card In-Reply-To: <0a21decc-a1e5-3b1a-8e35-0b8195352022@nordnet.fr> References: <87wp56sj0u.fsf@wheatstone.g10code.de> <87zi9xsvf4.fsf@iwagami.gniibe.org> <0a21decc-a1e5-3b1a-8e35-0b8195352022@nordnet.fr> Message-ID: <877ex0c7l7.fsf@fsij.org> Philip Jackson wrote: > I created the scdaemon.conf file as you suggested and then ran a decrypt > test : Thank you. > Perhaps there is something you can see which explains the problem ? As far as I can see, it looks like no problem of scdaemon, but card failure. Here is the decrypt operation started: > 2017-09-15 00:30:20 scdaemon[8306] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=257 le=2048 em=1 Since it's long command, it is devided into two blocks, (1) and (2). This is the first block (1): > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock: > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 258 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 29 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bBWI ..............: 0x04 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: wLevelParameter ...: 0x0000 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 20 FE 00 2A 80 ^ The first block has "more"-bit -------------------------------------- Then, this is the reply asking next block: > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock: > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 4 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 29 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bStatus ...........: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 90 00 90 This is the next block (2): > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock: > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 16 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 30 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bBWI ..............: 0x04 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: wLevelParameter ...: 0x0000 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 40 0C FD E0 81 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0016] 35 DD 4C B4 CA 38 6E 08 00 54 This block is final with no "more" bit. The expected behavior is the card reader returns text after decryption by card. But, card reader returns only three bytes, where more than four bytes are expected at least. > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock: > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 3 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 30 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bStatus ...........: 0 > 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 00 00 So, it is interpreted as lower-level communication error. > 2017-09-15 00:30:20 scdaemon[8306] ccid_transceive failed: (0x1000d) > 2017-09-15 00:30:20 scdaemon[8306] apdu_send_simple(0) failed: aborted Sending APDU, the command is somehow aborted. > 2017-09-15 00:30:20 scdaemon[8306] operation decipher result: Operation cancelled > 2017-09-15 00:30:20 scdaemon[8306] app_decipher failed: Operation cancelled > 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663395 Operation cancelled > 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 <- CAN > 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663571 Unknown IPC command This part is a little buggy, though. The error code of GPG_ERR_CANCEL is not that appropriate, I suppose. Because of erroneous GPG_ERR_CANCEL, gpg-agent wrongly send "CAN" (cancel) command to scdaemon, which is unknown by scdaemon in this stage. I'll fix this part. I don't know the reason why card error occurs. -- From dseaward925 at gmail.com Sun Sep 17 08:32:26 2017 From: dseaward925 at gmail.com (David Seaward) Date: Sun, 17 Sep 2017 08:32:26 +0200 Subject: Help: Copied gnupg folder not recognised Message-ID: <1505629946.3343.5.camel@gmail.com> Hi, I copied ~/.gnupg from my old machine, because I want to copy all keys, trust data etc. [1] However, on my new machine, nothing seems to be recognising the GnuPG files: * "gnupg --list-keys" is empty ("gnupg --help" confirms that ~/.gnupg is the folder being used) * The "GnuPG keys" pane of "GNOME Password and Keys" is empty * Email client is not able to encrypt/decrypt messages How can I diagnose what the problem is? Failing that, how can I export/import an entire .gnupg folder (including trust data)? Regards, David [1] https://www.phildev.net/pgp/gpg_moving_keys.html From youcanlinux at gmail.com Sun Sep 17 13:06:08 2017 From: youcanlinux at gmail.com (Daniel Villarreal) Date: Sun, 17 Sep 2017 07:06:08 -0400 Subject: Help: Copied gnupg folder not recognised In-Reply-To: <1505629946.3343.5.camel@gmail.com> References: <1505629946.3343.5.camel@gmail.com> Message-ID: <21a461b7-c4f7-4f5c-7655-d767712bebdb@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/17/17 02:32, David Seaward wrote: > Hi, > > I copied ~/.gnupg from my old machine, because I want to copy all > keys, trust data etc. [1] > > However, on my new machine, nothing seems to be recognising the > GnuPG files: > > * "gnupg --list-keys" is empty ("gnupg --help" confirms that > ~/.gnupg is the folder being used) > > * The "GnuPG keys" pane of "GNOME Password and Keys" is empty > > * Email client is not able to encrypt/decrypt messages > > How can I diagnose what the problem is? Failing that, how can I > export/import an entire .gnupg folder (including trust data)? > > Regards, David > > [1] https://www.phildev.net/pgp/gpg_moving_keys.html I'm just pointing out some messages that helped me... Robert J. Hansen, Jan 15, 2017; 5:40pm http://gnupg.10057.n7.nabble.com/Sherpa-0-3-0-td50700.html Peter Lebbing, Jul 14, 2017; 2:56pm http://gnupg.10057.n7.nabble.com/A-Quick-Question-td52732.html#a52736 Werner Koch, Dec 09, 2016; 2:10pm http://gnupg.10057.n7.nabble.com/How-restore-backuped-gnupg-private-keys - -v1-d-td50286.html#a50290 Robert J. Hansen, Nov 17, 2016; 3:03pm http://gnupg.10057.n7.nabble.com/Fresh-OS-installation-td49869.html#a498 70 Werner Koch, Sep 19, 2016; 1:49am http://gnupg.10057.n7.nabble.com/What-is-a-reliable-way-to-backup-restor e-my-keys-and-test-td48847.html#a48906 Daniel Kahn Gillmor, Sep 14, 2016; 4:05pm http://gnupg.10057.n7.nabble.com/What-is-a-reliable-way-to-backup-restor e-my-keys-and-test-tp48847p48854.html hope this helps, Daniel - -- Daniel Villarreal http://www.youcanlinux.org youcanlinux at gmail.com PGP key 2F6E 0DC3 85E2 5EC0 DA03 3F5B F251 8938 A83E 7B49 https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49 -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZvlcaAAoJEPJRiTioPntJ+NkH/05xRLuG79plxQNiAuZAjbcu EEdXWJa+Ow4lnVJLTtidOr49/x2QepkpqCdk3CucM2Awit9ZVneNdURdJAlUsAYT PMqYBdtJamIBTyNftLLzeiFdXzbkQRFCA57CLUBG8UHZd2lfX9WNmqBc3jZ8Nb93 dMf93HYrzYbCPP2+Ilmyel4THB7E9580rhLcBweI20Okg9XT6hwszwmqsa6fadT1 fVUJaiRrQkuloM7De2vVJN5QnhUTiQMvmVLTW3++acSodisSjM8mD0u2FbHv1IBc qWUUiiDD9w1p7ol7t3NtcakTZchqV1sA7XOxG+CJe9KUOl78U6ufg/o/28nz7sw= =noVu -----END PGP SIGNATURE----- From lestofante88 at gmail.com Mon Sep 18 08:19:08 2017 From: lestofante88 at gmail.com (lesto fante) Date: Mon, 18 Sep 2017 06:19:08 +0000 Subject: [Feature Request] Multiple level subkey In-Reply-To: References: Message-ID: ok, just to clarify; my original question boils down to be able to generate Sign key using a subkey. I guess there should be an arbitrary hard limit on the number of sub-subkey, Aside from this, the validation algorithm should be made recursive, up to the hard limit. Would be possible to use the GnuPG code to create a fork, and add this kind of behaviur? 2017-09-09 0:50 GMT+02:00 lesto fante : > Hello, > > Maybe this is not the right place to discuss about this, please be > kind with a noob. > > My user case is simple; maintain my identity even if my master key is > compromised. Tho achieve that, I think about a multilevel subkey > system. > Please i would love to hear any alternative. > For the discussion purpose, we don't talk about HOW revoke and public > key are exchanged between peers; it could be with existing key server, > or other way. > > I would like to set up a system relatively secure, but with no hassle > for everyday use. > > The idea is the following: > A level 1 key, kept very safe (hw or paper wallet wallet). This key > represent the identity is hopefully used only once to generate one > subkey "level 2". > > The subkey level 2 is saved on one (or more, but trusted) main device. > This key will be used to generate its own subkey (level 3), those > subkey are used for various application and distributed between device > using relatively unsafe method; losing, revoking or issuing a new key > for a new application should be easy and transparent for the user. > > the idea is that the level 2 key is used for most of the normal > operation, even in case one or more level 3 key are compromised; > please remember that all they key just represent the identity of the > level 1 key. > > This is very similar to the chain of trust with certificate. > > Now the nice thing: i guess most of the people will use their phone to > keep the level 2 key, but we know those are not the most secure stuff, > especially when get old or wit some producer allergic to patch. > > In the unlucky case the level 2 key get compromised, the user can use > the level 1 key to: > 1. revoke the level 2 key. This of course will automatically revoke > the level 3 key that are direct subkey of that level 2 key. > > 2. issue a new level 2 key. At this point the main device will issue > new level 3 key to replace all the key revoked in the step above. > > please note a user could have multiple level 2 key active; this could > be for different reason, like updating to different algorithm still > not fully supported. > > Lesto > > ps. is anyone aware of some kind P2P system to share keys? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bozho at kset.org Mon Sep 18 12:38:44 2017 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 18 Sep 2017 11:38:44 +0100 Subject: Extending expiration date and SSH Message-ID: <8541bdc5-f4c1-555e-7d45-72dda7dfdb07@kset.org> Hi all, I use my authentication GPG key for SSHing into different machines. My GPG keys are stored on a Yubikey and I use gpg-agent to interface with the Yubikey and use the keys for SSH authentication. My GPG keys have expired and while that doesn't have any effect on SSH authentication, I'd still like to extend their expiration date. Will that change the SSH public key (as it is exported using ssh-add -L for adding to .ssh/authorized_keys)? I'm looking for a best practice approach to avoid locking myself out of my machines :) Thank you! -- Marko From peter at digitalbrains.com Mon Sep 18 16:48:48 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 18 Sep 2017 16:48:48 +0200 Subject: Extending expiration date and SSH In-Reply-To: <8541bdc5-f4c1-555e-7d45-72dda7dfdb07@kset.org> References: <8541bdc5-f4c1-555e-7d45-72dda7dfdb07@kset.org> Message-ID: <0de4ff40-c9e9-58b4-3be9-13c5162f1686@digitalbrains.com> On 18/09/17 12:38, Marko Bo?ikovi? wrote: > Will that change the SSH public key (as it is exported using ssh-add -L for > adding to .ssh/authorized_keys)? No, if it is a regular SSH key, it will not change by changing the expiration date. > I'm looking for a best practice approach to avoid locking myself out of my > machines :) Back up your .gnupg dir, and if something goes wrong, put it back from backup. Always good advice. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From patrick-mailinglists at whonix.org Mon Sep 18 15:50:00 2017 From: patrick-mailinglists at whonix.org (Patrick Schleizer) Date: Mon, 18 Sep 2017 13:50:00 +0000 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) Message-ID: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> gpg --keyserver hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com gpg --keyserver=hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com gpg: no keyserver known (use option --keyserver) gpg: keyserver search failed: No keyserver available What am I doing wrong? From dgouttegattat at incenp.org Mon Sep 18 18:00:07 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 18 Sep 2017 18:00:07 +0200 Subject: Extending expiration date and SSH In-Reply-To: <8541bdc5-f4c1-555e-7d45-72dda7dfdb07@kset.org> References: <8541bdc5-f4c1-555e-7d45-72dda7dfdb07@kset.org> Message-ID: <3d7a6041-3399-8522-9492-284abf42fa31@incenp.org> Hi, On 09/18/2017 12:38 PM, Marko Bo?ikovi? wrote: > Will that change the SSH public key (as it is exported using ssh-add -L for > adding to .ssh/authorized_keys)? No. The expiration date of the subkey is not part of the key material itself, it is stored in the subkey binding signature. A modification of the expiration date has no effect on the public key as seen by SSH. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From thejze at gmx.at Mon Sep 18 17:32:51 2017 From: thejze at gmx.at (Thomas Hejze) Date: Mon, 18 Sep 2017 17:32:51 +0200 Subject: OT: Which smartphone would you use Message-ID: <3771476.PIQjPmmXgn@linux.suse> Hello everyone, I know this is off-topic, but since it is related to IT security and therefore more or less to GNUPG, I hope that I get some helping answers, though. Having been objecting to smartphones for a long time I fear that the time has come that I get one for myself. The question is which one. IPhone is not an option, Android probably not, due to security considerations. I want a hardware/software combination which provides a decent amount of security for my personal data. Jolla or Tizen comes to my mind, but as far as I have come with my research, hardware for those is difficult to get at least in Europe. So I am looking for some advice from the experts which are regulars on this mailing list and recommendations which hardware/software combination they would use resp. are using. Thanks in advance and best regards Thomas Hejze From fsantiago at garbage-juice.com Mon Sep 18 17:49:29 2017 From: fsantiago at garbage-juice.com (Fabian A. Santiago) Date: Mon, 18 Sep 2017 15:49:29 +0000 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) In-Reply-To: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> References: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 September 18, 2017 11:43 AM, "Patrick Schleizer" wrote: > gpg --keyserver hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg --keyserver=hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg: no keyserver known (use option --keyserver) > gpg: keyserver search failed: No keyserver available > > What am I doing wrong? > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users remove the hkp prefix from your server address: someserver.com instead of hkp://...:... and no equal sign either after keyserver. - -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v2.5.4 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJZv+sECRBVUCsO65Bw/AAAJ+AP/1P16+FHSJtOeH/SSLAY 9MsYw2SdJJlR7KM0dijb6MjthzFeSuX3sRZ/vcfHbgro1V12VNFCZqAPKOxi aWt06MF+hig0Lz6VablrnszwnTffftCMPOALMUipOI9l3jdwKKosdObX8JAS ckTzrU6Fg3XKMzI/h7LDkocPCujSHUh9G/vcvVeTpcHX5NUqVGDyY1rBe+z8 GIvtVZbaX/f0fT/Th5/zurTiExkBkTsXBwOBv5EF/ICK9E3txF2x4LIPywEn XV4rqwHfGmxPKpb08IIFG/jw82mPk5AYr5+AkTMRLxeALoawaZrYoFq/slG+ VRIw/Y4ynPkiJykpx37IBF/+8RnI9OKtlFGSiO1HmjYxO6l8bCLzkuRNnUOF Nn+iHvvLVh0Vg20SNy4ffUnms+of4Dj8eYwDx7HU1vAtMy5s0k/ou+Jd0rzw q51quIGG8yG07I/CT0adZV1tqYXBZRJgnk3t0x2uBuLKINHAFPM1jT0+185K Ikr2jyXKNLm080sU4zNOUH99UINq/DgLfq+hPadJVDpNBty5qNcp50oSGvV2 pg1EYZbh2bK5ExSyn01C+GRDFGoyUM4DY0caLsKiuMgT8M6DQ5LmABwvUQ56 DGsszdJ0m1QhvSBPMm09AzljTtrefadn5mA1stvMxcb01sVA7zyn/e7dVEi7 dAPa =0Omz -----END PGP SIGNATURE----- From ler762 at gmail.com Mon Sep 18 18:13:20 2017 From: ler762 at gmail.com (Lee) Date: Mon, 18 Sep 2017 12:13:20 -0400 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) In-Reply-To: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> References: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> Message-ID: On 9/18/17, Patrick Schleizer wrote: > gpg --keyserver hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg --keyserver=hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg: no keyserver known (use option --keyserver) > gpg: keyserver search failed: No keyserver available > > What am I doing wrong? Try it without the port number $ gpg --keyserver hkp://pgp.mit.edu --search-keys torbrowser at torproject.org gpg: searching for "torbrowser at torproject.org" from hkp server pgp.mit.edu (1) Tor Browser Developers (unknown) 4096 bit RSA key 0x669ECC703A7C585A, created: 2017-08-18, expires: 2020-08-24 (2) Tor Browser Developers 4096 bit RSA key 0xB9294788BE63AEFC, created: 2017-08-18, expires: 2017-08-25 (expired) (3) Tor Browser Developers (signing key) 4096 bit RSA key 0x4E2C6E8793298290, created: 2014-12-15, expires: 2020-08-24 Keys 1-3 of 3 for "torbrowser at torproject.org". Enter number(s), N)ext, or Q)uit > q From guru at unixarea.de Mon Sep 18 20:04:10 2017 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 18 Sep 2017 20:04:10 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <3771476.PIQjPmmXgn@linux.suse> Message-ID: <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> On Monday, 18 September 2017 17:32:51 CEST, Thomas Hejze wrote: > Hello everyone, > I know this is off-topic, but since it is related to IT > security and therefore > more or less to GNUPG, I hope that I get some helping answers, though. > > Having been objecting to smartphones for a long time I fear > that the time has > come that I get one for myself. The question is which one. > > IPhone is not an option, Android probably not, due to security > considerations. > ... I'm using for more than two years an Ubuntu phone BQ E4.5. The project was driven by Canonical and BQ as the hardware OEM. The project died in March of this year, but is now moved to a community of OpenSource entusiast. The software novadays is mostly Ubuntu 15.04, with some Android blobs in the kernel for the hardware access. Check https://forums.ubports.com/ matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ From dotancohen at gmail.com Mon Sep 18 18:55:49 2017 From: dotancohen at gmail.com (Dotan Cohen) Date: Mon, 18 Sep 2017 19:55:49 +0300 Subject: OT: Which smartphone would you use In-Reply-To: <3771476.PIQjPmmXgn@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> Message-ID: The answer pretty much depends on what smartphone features you are looking for. Do you need to run a web browser? Email integration? AnkiDroid? A decent camera? Let us know what features you are looking for. On Mon, Sep 18, 2017 at 6:32 PM, Thomas Hejze wrote: > Hello everyone, > I know this is off-topic, but since it is related to IT security and therefore > more or less to GNUPG, I hope that I get some helping answers, though. > > Having been objecting to smartphones for a long time I fear that the time has > come that I get one for myself. The question is which one. > > IPhone is not an option, Android probably not, due to security considerations. > I want a hardware/software combination which provides a decent amount of > security for my personal data. Jolla or Tizen comes to my mind, but as far as > I have come with my research, hardware for those is difficult to get at least > in Europe. So I am looking for some advice from the experts which are regulars > on this mailing list and recommendations which hardware/software combination > they would use resp. are using. > > Thanks in advance and best regards > Thomas Hejze > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dotan Cohen http://gibberish.co.il http://what-is-what.com From guru at unixarea.de Mon Sep 18 20:13:14 2017 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 18 Sep 2017 20:13:14 +0200 Subject: OT: Which smartphone would you use In-Reply-To: References: <3771476.PIQjPmmXgn@linux.suse> <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> Message-ID: <1660204c-db61-4a80-a6a5-8d937083bcac@unixarea.de> On Monday, 18 September 2017 20:07:38 CEST, Mauricio Tavares wrote: >> I'm using for more than two years an Ubuntu phone BQ E4.5. The >> project was >> driven by Canonical and BQ as the hardware OEM. The project >> died in March of >> this year, but is now moved to a community of OpenSource entusiast. The >> software novadays is mostly Ubuntu 15.04, with some Android blobs in the >> kernel for the hardware access. >> > Wasn't there also at least one company in Europe selling the > Ubuntu phones? Yes, as I said BQ.com -- Sent from my Ubuntu phone http://www.unixarea.de/ From peter at digitalbrains.com Mon Sep 18 20:27:19 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 18 Sep 2017 20:27:19 +0200 Subject: How to encrypt using public certificate\key In-Reply-To: References: <700a9d2b-d2d0-0d63-9cf1-0518e6d74f9d@digitalbrains.com> <9cead936-7ad9-daac-71d5-e13d032f5beb@digitalbrains.com> Message-ID: On 07/09/17 12:58, shaarang tyagi wrote: > I am trying to understand the encryption process and the all the input > that is required to perform encryption. > > So according to this RFC, section 2.1: If you want to learn about what makes an OpenPGP message, gpg --list-packets is very useful: $ echo Talking to myself | gpg -r peter at digitalbrains.com -e | gpg --list-packets And now you see which packets make up a message encrypted to me. > https://tools.ietf.org/html/rfc4880#section-2.1 > > There can be 2 sources for encryption key, either a session > key(generated randomly) or a shared pass phrase (key is derived from > this phrase) ? Well, in a sense that's correct, but it's missing an important point. What GnuPG does is: - Create a random session key, unique for each encrypted message. This is what the data is encrypted with. - For each public key the data is encrypted to, include a Public-Key Encrypted Session Key Packet[1] (PKESK), which is the session key encrypted to a specific public key. - If decryption by passphrase is requested (--symmetric), also create a Symmetric-Key Encrypted Session Key Packet[2] (SKESK), which allows to decrypt the session key with the passphrase. RFC 4880 section 2.1 indeed also mentions a different method where the passphrase is used to derive the key to encrypt the data, rather than using a random session key. This is possible if the data is preceded by a single SKESK that specifies how to derive the key from the passphrase, as in section 5.3 [2]. But this type of data is never produced by GnuPG, to my knowledge. So /the/ method, the single method, to create an encrypted message is to generate a random session key which is used to encrypt the data. Then get that session key to your recipient, be that by public key or by shared passphrase. Finally, multiple passphrases that all decrypt the data (multiple SKESK packets) are permitted, but I don't think GnuPG can create such messages (I'm not sure). > gpg -e -u "Sender User Name" -r "Receiver User Name" somefile What you /should/ do is put all options before the command; that way the command line is unambiguous and gpg will always catch your meaning. "-e" is the command, and "somefile" is the command argument. So: $ gpg -u "Sender User Name" -r "Receiver User Name" -e somefile When you include options after the command, it might work, but it requires guesswork on the part of gpg, so you should avoid it. > Which method does this command uses exactly? It encrypts the data with a random session key, and encrypts the session key to the public key belonging to "Receiver User Name". To be exact, the first public key it finds in its keyring that matches "Receiver User Name". Which one is the first, you don't know, so it's best to make sure only one key matches what you give. And the command line contains useless cruft, as it specifies a signing key, but doesn't request signing of the data. So the "-u" argument is silently ignored as not relevant but not harmful either. If there is only one private key, it's never necessary to specify it by "-u". > It does message encryption with a given username's certificate's pub > key?(Is this a third method which is not mentioned in that RFC ) ? No, there's no third method to decrypt data, it's either encrypted to a public key, or a passphrase unlocks it, or both. Okay, I guess that does make three ;-). > Also, Where can i find all the commands for all the possibilities using > different key sources? Either the man page if you're on a UNIXy OS: $ man gpg Or the Texinfo documentation which is on the web[3] and can also be read on UNIXy OSes by: $ info gnupg (or a different info reader, I usually use "pinfo"). The Texinfo manual has more than the man page, and is also a lot easier to navigate. But they are mostly reference manuals, you'll still need other documentation to get you started. Let me point out, as you're perusing the OpenPGP RFC, that there is even another method[4] to encrypt data[5] to a passphrase defined there, but it's deprecated. As it should be, no salting!, obsolete cipher: > [...] If no packets of these types precede the encrypted data, > the IDEA algorithm is used with the session key calculated as the MD5 > hash of the passphrase, though this use is deprecated. Just ignore this, it's ancient. If somebody sends you such messages, please page them or send them a fax, requesting them to come over to the 21st century. It's not that scary on most days. And there is more such stuff in the RFC. If it says something like "deprecated" or SHOULD NOT or something, you can probably skip it. HTH, Peter. [1] [2] [3] [4] [5] Okay, that puts "is there a third method to encrypt" into a different light again :-) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From pvoigt at uos.de Mon Sep 18 20:01:54 2017 From: pvoigt at uos.de (Dr. Peter Voigt) Date: Mon, 18 Sep 2017 20:01:54 +0200 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) In-Reply-To: References: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> Message-ID: <20170918200154.2d0ef53f@kirk> On Mon, 18 Sep 2017 12:13:20 -0400 Lee wrote: > Try it without the port number > $ gpg --keyserver hkp://pgp.mit.edu --search-keys > torbrowser at torproject.org gpg: searching for > "torbrowser at torproject.org" from hkp server pgp.mit.edu (1) Tor > Browser Developers (unknown) 4096 bit RSA > key 0x669ECC703A7C585A, created: 2017-08-18, expires: 2020-08-24 > (2) Tor Browser Developers > 4096 bit RSA key 0xB9294788BE63AEFC, created: 2017-08-18, > expires: 2017-08-25 (expired) > (3) Tor Browser Developers (signing key) > 4096 bit RSA key 0x4E2C6E8793298290, > created: 2014-12-15, expires: 2020-08-24 > Keys 1-3 of 3 for "torbrowser at torproject.org". Enter number(s), > N)ext, or Q)uit > q Hhm, it's working on my machine both with "hkp://" and with port number: # gpg --keyserver hkp://pgp.mit.edu:11371 --search-keys torbrowser at torproject.org gpg: data source: http://pgp.mit.edu:11371 (1) Tor Browser Developers (unknown) 4096 bit RSA key 669ECC703A7C585A, created: 2017-08-18, expires: 2020-08-24 (2) Tor Browser Developers 4096 bit RSA key B9294788BE63AEFC, created: 2017-08-18, expires: 2017-08-25 (expired) (3) Tor Browser Developers (signing key) 4096 bit RSA key 4E2C6E8793298290, created: 2014-12-15, expires: 2020-08-24 Keys 1-3 of 3 for "torbrowser at torproject.org". Enter number(s), N)ext, or Q)uit > My GnuPG version is 2.1.18. Under Debian Stretch I have solved similar keyserver related issues with the option "standard-resolver" in ~/.gnupg/dirmngr.conf. I hope it helps. Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From raubvogel at gmail.com Mon Sep 18 20:07:38 2017 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 18 Sep 2017 14:07:38 -0400 Subject: OT: Which smartphone would you use In-Reply-To: <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> References: <3771476.PIQjPmmXgn@linux.suse> <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> Message-ID: On Mon, Sep 18, 2017 at 2:04 PM, Matthias Apitz wrote: > On Monday, 18 September 2017 17:32:51 CEST, Thomas Hejze > wrote: >> >> Hello everyone, >> I know this is off-topic, but since it is related to IT security and >> therefore more or less to GNUPG, I hope that I get some helping answers, >> though. >> >> Having been objecting to smartphones for a long time I fear that the time >> has come that I get one for myself. The question is which one. >> >> IPhone is not an option, Android probably not, due to security >> considerations. >> ... > > > I'm using for more than two years an Ubuntu phone BQ E4.5. The project was > driven by Canonical and BQ as the hardware OEM. The project died in March of > this year, but is now moved to a community of OpenSource entusiast. The > software novadays is mostly Ubuntu 15.04, with some Android blobs in the > kernel for the hardware access. > Wasn't there also at least one company in Europe selling the Ubuntu phones? > Check https://forums.ubports.com/ > > matthias > > > > -- > Sent from my Ubuntu phone > http://www.unixarea.de/ > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gk at leniwiec.biz Mon Sep 18 20:45:52 2017 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Mon, 18 Sep 2017 20:45:52 +0200 Subject: Automating and integrating GPG Message-ID: <59C01460.8010403@leniwiec.biz> Hello, I am working on a project (in Python and bash) that requires me to use GPG in "headless mode" to generate keys and edit OpenPGP smartcard (to set some properties and transfer some of the generated keys). This includes transfering any passwords and PINs from my program to GPG, instead of requiring user to enter them using pinentry. I wonder what method of integration of GPG with such project is best, most future-proof and recommended and are there any other advices you may give me? Thank you in advance. -- Grzegorz Kulewski From dkg at fifthhorseman.net Mon Sep 18 23:37:13 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 Sep 2017 17:37:13 -0400 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) In-Reply-To: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> References: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> Message-ID: <87d16nsn7a.fsf@fifthhorseman.net> On Mon 2017-09-18 13:50:00 +0000, Patrick Schleizer wrote: > gpg --keyserver hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg --keyserver=hkp://pgp.mit.edu:11371 --search-keys my at e-mail.com > > gpg: no keyserver known (use option --keyserver) > gpg: keyserver search failed: No keyserver available > > What am I doing wrong? what version of gpg? what version of dirmngr? modern versions of gpg should default to the hkps pool, and shouldn't need any explicit configuration. --dkg From dkg at fifthhorseman.net Mon Sep 18 23:45:37 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 Sep 2017 17:45:37 -0400 Subject: Automating and integrating GPG In-Reply-To: <59C01460.8010403@leniwiec.biz> References: <59C01460.8010403@leniwiec.biz> Message-ID: <87a81rsmta.fsf@fifthhorseman.net> On Mon 2017-09-18 20:45:52 +0200, Grzegorz Kulewski wrote: > I am working on a project (in Python and bash) that requires me to use > GPG in "headless mode" to generate keys and edit OpenPGP smartcard (to > set some properties and transfer some of the generated keys). This > includes transfering any passwords and PINs from my program to GPG, > instead of requiring user to enter them using pinentry. > > I wonder what method of integration of GPG with such project is best, > most future-proof and recommended and are there any other advices you > may give me? GnuPG upstream developers tend to recommend the use of GPGME for system integration projects that require a stable interface. If you're using python, the GnuPG team maintains gpgme bindings for python, available in debian and debian-derived systems (e.g. ubuntu) as "python-gpg". I don't know how much smartcard interaction gpgme supports, though. hth, --dkg From dank at kegel.com Tue Sep 19 00:38:55 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 18 Sep 2017 15:38:55 -0700 Subject: Automating and integrating GPG In-Reply-To: <87a81rsmta.fsf@fifthhorseman.net> References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> Message-ID: On Mon, Sep 18, 2017 at 2:45 PM, Daniel Kahn Gillmor wrote: > GnuPG upstream developers tend to recommend the use of GPGME for system > integration projects that require a stable interface. dpkg does that, but it doesn't help people trying to automate dpkg :-) - Dan From dank at kegel.com Mon Sep 18 23:10:40 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 18 Sep 2017 14:10:40 -0700 Subject: Automating and integrating GPG In-Reply-To: <59C01460.8010403@leniwiec.biz> References: <59C01460.8010403@leniwiec.biz> Message-ID: On Mon, Sep 18, 2017 at 11:45 AM, Grzegorz Kulewski wrote: > I am working on a project (in Python and bash) that requires me to use GPG in "headless mode" to generate keys and edit OpenPGP smartcard (to set some properties and transfer some of the generated keys). This includes transfering any passwords and PINs from my program to GPG, instead of requiring user to enter them using pinentry. > > I wonder what method of integration of GPG with such project is best, most future-proof and recommended and are there any other advices you may give me? Good question. I wrote a bit about doing that in shell scripts, see https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058158.html It's challenging to make it both future- and past- proof, as gpg keeps changing. What range of Linux distributions / versions of gpg do you need to support? The new requirement for the agent is very challenging, and should not be taken lightly. You may need to expose the agent concept to your program; a transparent wrapper may not be possible. I keep running into problems with this. https://github.com/Oblong/obs/ has my ugly code, and an automated test that sometimes fails on slow systems like raspberry pi because of my poor transparent wrapper around the gpg agent. It is somewhat obscured by site-specific stuff (e.g. it uses gpg via apt). I could try to do a clean demo without apt sometime if that would be helpful. - Dan From wk at gnupg.org Tue Sep 19 09:18:57 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Sep 2017 09:18:57 +0200 Subject: using --keyserver but still getting gpg: no keyserver known (use option --keyserver) In-Reply-To: <87d16nsn7a.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 18 Sep 2017 17:37:13 -0400") References: <9942d5b0-ba13-afa8-200f-1707c24f2936@riseup.net> <87d16nsn7a.fsf@fifthhorseman.net> Message-ID: <87shfjm9zy.fsf@wheatstone.g10code.de> On Mon, 18 Sep 2017 23:37, dkg at fifthhorseman.net said: > modern versions of gpg should default to the hkps pool, and shouldn't > need any explicit configuration. Right, and it is also more future proof to use the keyserver option in dirmngr.conf instead of gpg.conf. But as you say, no configuration is even better. FWIW, I just released 2.2.1 which fixes problems with some keyservers, in particular on Windows where the default installer is built against libntbtls. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From steven at jetway.com.tw Tue Sep 19 05:44:32 2017 From: steven at jetway.com.tw (Steven) Date: Tue, 19 Sep 2017 11:44:32 +0800 Subject: How to complete the public PGP key application Message-ID: <00d401d330f9$9aac2800$d0047800$@com.tw> Hi Sir We are based on the "HDCP Signing Facility User's Guide" to apply public PGP key, but we could not find out like gpg.exe from the directory. Could you help to ask any of shortcut to complete the public PGP key application? Thanks! Steven Tao Jetway Information Co., Ltd. TEL: +886-2-89132711 EXT 111 FAX: +886-2-89132722 Website: www.jetwayipc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Sep 19 13:10:46 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Sep 2017 13:10:46 +0200 Subject: [Announce] GnuPG 2.2.1 released Message-ID: <87poankkp5.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.1. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. As an Universal Crypto Engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.1 =================================== * gpg: Fix formatting of the user id in batch mode key generation if only "name-email" is given. * gpgv: Fix annoying "not suitable for" warnings. * wks: Convey only the newest user id to the provider. This is the case if different names are used with the same addr-spec. * wks: Create a complying user id for provider policy mailbox-only. * wks: Add workaround for posteo.de. * scd: Fix the use of large ECC keys with an OpenPGP card. * dirmngr: Use system provided root certificates if no specific HKP certificates are configured. If build with GNUTLS, this was already the case. Further, the Windows installer has been built against an updated NTBTLS libary which does now support ECC curves secp384r1, secp521r1, as well as brainpool curves. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.1 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.1.tar.bz2 (6385k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.1.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.1_20170919.exe (3799k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.1_20170919.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. The new Gpg4win 3.0 installer featuring this version of GnuPG will be available in a few days. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.1.tar.bz2 you would use this command: gpg --verify gnupg-2.2.1.tar.bz2.sig gnupg-2.2.1.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.1.tar.bz2, you run the command like this: sha1sum gnupg-2.2.1.tar.bz2 and check that the output matches the next line: 5455373fd7208b787f319027de2464721cdd4413 gnupg-2.2.1.tar.bz2 bcf1905655e52e2eec794bcbba72485f7b9ed2d3 gnupg-w32-2.2.1_20170919.exe 72ab40a7336be7b2c9fb4f6ff1f15e5c5b8cdb6f gnupg-w32-2.2.1_20170919.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 2 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and for financing the project. Happy hacking, Your GnuPG Team p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From mailinglists at gusnan.se Tue Sep 19 13:44:53 2017 From: mailinglists at gusnan.se (Andreas Ronnquist) Date: Tue, 19 Sep 2017 13:44:53 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <3771476.PIQjPmmXgn@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> Message-ID: <20170919134453.26107fa7@debian-i7> On Mon, 18 Sep 2017 17:32:51 +0200, Thomas Hejze wrote: >Hello everyone, >I know this is off-topic, but since it is related to IT security and >therefore more or less to GNUPG, I hope that I get some helping >answers, though. > >Having been objecting to smartphones for a long time I fear that the >time has come that I get one for myself. The question is which one. > >IPhone is not an option, Android probably not, due to security >considerations. I want a hardware/software combination which provides >a decent amount of security for my personal data. Jolla or Tizen comes >to my mind, but as far as I have come with my research, hardware for >those is difficult to get at least in Europe. So I am looking for some >advice from the experts which are regulars on this mailing list and >recommendations which hardware/software combination they would use >resp. are using. > If I had the money, I would pledge for one of these: https://puri.sm/shop/librem-5/ I believe It will fit with the GnuPG thoughts on privacy and security very well. -- Andreas R?nnquist mailinglists at gusnan.se andreas at ronnquist.net From aheinlein at gmx.com Tue Sep 19 15:53:46 2017 From: aheinlein at gmx.com (Andreas Heinlein) Date: Tue, 19 Sep 2017 15:53:46 +0200 Subject: Automating and integrating GPG In-Reply-To: <87a81rsmta.fsf@fifthhorseman.net> References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> Message-ID: Am 18.09.2017 um 23:45 schrieb Daniel Kahn Gillmor: > I don't know how much smartcard interaction gpgme supports, though. None, as it seems. I have started developing with python-gpg and gpgme some weeks ago, but haven't yet done anything with smartcards yet. But as far as I can tell from the docs, gpgme completely hides the internals of key storage, to gpgme it doesn't matter whether the key is located on disk or stored in a smartcard or token. Having said that, I must say that your goal is somewhat difficult to achieve. Handling of the passphrase is about one of the most sensitive tasks when dealing with encryption. I currently can think of no way you could handle passphrases on your own in python which I would call 'secure'. Don't pass it on the command line to a gpg subprocess, that will be readable in the process list for everyone. But even if you pass it along with e.g. gpgme, it might be possible to read the memory of that python process and steal the passphrase. That part of the memory might also be swapped out. Read the relevant part of the FAQ: https://www.gnupg.org/faq/gnupg-faq.html#insecure_memory Furthermore, for me one of the best reasons for using smartcards is that you don't enter the PIN/passphrase on the (potentially compromised) computer at all, but use a class 2 or 3 smartcard reader for that. Using a class 1 reader and juggling around the PIN in scripts defeats 50% of the purpose of a smartcard to me (the other 50% being that you can't copy the secret key from the card, this stays untouched). I guess you just have no choice when you say you are "required to", but keep that in mind. If you must use python and cannot use gpgme, your best bet might be to write the passphrase out to a file which only you can read, and pass it to the gpg command line using '--passphrase-file' or "--passphrase-fd'. You will need to trust root on that machine in any case. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 19 16:41:29 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 19 Sep 2017 16:41:29 +0200 Subject: Automating and integrating GPG In-Reply-To: References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> Message-ID: On 09/19/2017 03:53 PM, Andreas Heinlein wrote: > Handling of the passphrase is about one of the most sensitive > tasks when dealing with encryption. I currently can think of no way you > could handle passphrases on your own in python which I would call > 'secure'. In such a scenario I'd likely use a custom pinentry, that'd be the same recommendation for a password manager etc, as for security info is passed in the socket that is protected using regular unix user permissions / ACLs and anyways same as regular pinentry uses. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "To live is the rarest thing in the world. Most people exist, that is all." Oscar Wilde -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 20 09:02:41 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Sep 2017 09:02:41 +0200 Subject: Automating and integrating GPG In-Reply-To: <87a81rsmta.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 18 Sep 2017 17:45:37 -0400") References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> Message-ID: <87poalj1im.fsf@wheatstone.g10code.de> On Mon, 18 Sep 2017 23:45, dkg at fifthhorseman.net said: > I don't know how much smartcard interaction gpgme supports, though. Everything you need. Have a look at GPA's smartcard features. I assume it is the most advanced GUI to handle the OpenPGP card as well as several other cards. For example it includes full support for the Telesec card with their NullPIN feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aheinlein at gmx.com Thu Sep 21 11:03:05 2017 From: aheinlein at gmx.com (Andreas Heinlein) Date: Thu, 21 Sep 2017 11:03:05 +0200 Subject: Automating and integrating GPG In-Reply-To: <87poalj1im.fsf@wheatstone.g10code.de> References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> <87poalj1im.fsf@wheatstone.g10code.de> Message-ID: <446e8baa-4417-daa6-7fd5-5c514564132e@gmx.com> Am 20.09.2017 um 09:02 schrieb Werner Koch: > On Mon, 18 Sep 2017 23:45, dkg at fifthhorseman.net said: > >> I don't know how much smartcard interaction gpgme supports, though. > Everything you need. Have a look at GPA's smartcard features. I assume > it is the most advanced GUI to handle the OpenPGP card as well as > several other cards. For example it includes full support for the > Telesec card with their NullPIN feature. Interesting. I haven't found anything smartcard related in the GPGME docs. I am really not good at C, but I took a look at the sources of GPA, specifically the change_pin function in cm-openpgp.c, and it looks like GPA is using assuan protocol through gpgme here: char?command[100]; snprintf?(command,?sizeof?command,?"SCD?PASSWD%s?%d", ???????????????? reset_mode??"?--reset":"",?pinno+1); err?=?gpgme_op_assuan_transact_ext?(gpgagent,?command, ?????????????????????????????????????????? NULL,?NULL,?NULL,?NULL,?NULL,?NULL, ?????????????????????????????????????????? &operr); I hadn't thought of that possibility. Python-GPG should support this, too - take a look at assuan.py in the examples folder. But I haven't yet found any documentation of the assuan commands you need here. This probably isn't as easy as a Python programmer might expect... Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Thu Sep 21 16:44:57 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 16:44:57 +0200 Subject: Houston, we have a problem Message-ID: <20170921164431.48a03cb3@iria.my-fqdn.de> Hi all, http://pgp.zdv.uni-mainz.de:11371/pks/lookup?op=vindex&search=Erika+Mustermann Question for the experts, how can a casual or new GnuPG user, like Alice and Bob, detect a Signature forgery on a pub key, when using Web based key servers? Note for native English speakers, Erika Mustermann is well known among german users, same as Jon Doe. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From rjh at sixdemonbag.org Thu Sep 21 16:55:26 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Sep 2017 10:55:26 -0400 Subject: Houston, we have a problem In-Reply-To: <20170921164431.48a03cb3@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> Message-ID: <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> > Question for the experts, how can a casual or new GnuPG user, like Alice > and Bob, detect a Signature forgery on a pub key, when using Web based > key servers? By remembering that anyone can create a key claiming to be anyone, and that seeing a signature allegedly from Werner (or anyone) means absolutely nothing until and unless you've verified the signing certificate actually belongs to him. Key validation -- ensuring a key really belongs to who it says -- is an important step. It cannot be skipped. It is not optional. From wk at gnupg.org Thu Sep 21 16:54:53 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Sep 2017 16:54:53 +0200 Subject: Automating and integrating GPG In-Reply-To: <446e8baa-4417-daa6-7fd5-5c514564132e@gmx.com> (Andreas Heinlein's message of "Thu, 21 Sep 2017 11:03:05 +0200") References: <59C01460.8010403@leniwiec.biz> <87a81rsmta.fsf@fifthhorseman.net> <87poalj1im.fsf@wheatstone.g10code.de> <446e8baa-4417-daa6-7fd5-5c514564132e@gmx.com> Message-ID: <87r2v0f6f6.fsf@wheatstone.g10code.de> On Thu, 21 Sep 2017 11:03, aheinlein at gmx.com said: > Interesting. I haven't found anything smartcard related in the GPGME > docs. I am really not good at C, but I took a look at the sources of Yes, it is a generic interface to make a core libassuan function (which is already used by gpgme) available as GPGME API. The actual API to the smartcard daemon is Assuan based and there is not much documentation than the reference you get when running $ gpg-connect-agent > scd help this lists all smartcard commands. gpg-agent intercepts some of the calls to provide a Pinentry but despite of this the "scd " prefix forwards all command to scdaemon. > I hadn't thought of that possibility. Python-GPG should support this, > too - take a look at assuan.py in the examples folder. But I haven't yet GPGME's Python interface supports this. Here is code from the distributed example: --8<---------------cut here---------------start------------->8--- """Demonstrate the use of the Assuan protocol engine""" From __future__ import absolute_import, print_function, unicode_literals del absolute_import, print_function, unicode_literals import gpg with gpg.Context(protocol=gpg.constants.protocol.ASSUAN) as c: # Invoke the pinentry to get a confirmation. err = c.assuan_transact(['GET_CONFIRMATION', 'Hello there']) print("You chose {}.".format("cancel" if err else "ok")) --8<---------------cut here---------------end--------------->8--- Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thejze at gmx.at Thu Sep 21 19:09:01 2017 From: thejze at gmx.at (Thomas Hejze) Date: Thu, 21 Sep 2017 19:09:01 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <1660204c-db61-4a80-a6a5-8d937083bcac@unixarea.de> References: <3771476.PIQjPmmXgn@linux.suse> <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> <1660204c-db61-4a80-a6a5-8d937083bcac@unixarea.de> Message-ID: <2539217.4tTC13fNCR@linux.suse> Am Montag, 18. September 2017, 20:13:14 CEST schrieb Matthias Apitz: > >> I'm using for more than two years an Ubuntu phone BQ E4.5. The > >> project was > >> driven by Canonical and BQ as the hardware OEM. The project > >> died in March of > >> this year, but is now moved to a community of OpenSource entusiast. > > Wasn't there also at least one company in Europe selling the > > > > Ubuntu phones? > > Yes, as I said BQ.com Unfortunately their hardware dos not seem to support Ubuntu any more. I found the "Ubuntu Edition" under "obsolete models", even a cyanogen edition, but all their current models run on Android. The rest of their homepage is all marketing gibberish as it is the use, nowadays. Best regards Thomas From thejze at gmx.at Thu Sep 21 18:54:43 2017 From: thejze at gmx.at (Thomas Hejze) Date: Thu, 21 Sep 2017 18:54:43 +0200 Subject: OT: Which smartphone would you use In-Reply-To: References: <3771476.PIQjPmmXgn@linux.suse> Message-ID: <14781413.dnX79WH965@linux.suse> Hi Dotan, Am Montag, 18. September 2017, 19:55:49 CEST schrieb Dotan Cohen: > The answer pretty much depends on what smartphone features you are > looking for. Do you need to run a web browser? Email integration? well first of all I would like to make phone calls. I use kdepim for contacts, calendar and email, so kdepim should run on it or at least be syncable. And gnupg should run on it. And yes, a secure browser, too. Everything else is a nice-to-have. So I guess Linux is the OS of choice. Hardware is anything-that-runs-on-Linux. I know it is possible to jailbreak an Android phone, the question is how difficult is this (for me). Best regards. Thomas From guru at unixarea.de Thu Sep 21 19:48:34 2017 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 21 Sep 2017 19:48:34 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <2539217.4tTC13fNCR@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> <6626074a-1f50-4fe1-aa15-0df7a25fc623@unixarea.de> <1660204c-db61-4a80-a6a5-8d937083bcac@unixarea.de> <2539217.4tTC13fNCR@linux.suse> Message-ID: <20170921174834.GA2358@c720-r314251> El d?a jueves, septiembre 21, 2017 a las 07:09:01p. m. +0200, Thomas Hejze escribi?: > Am Montag, 18. September 2017, 20:13:14 CEST schrieb Matthias Apitz: > > >> I'm using for more than two years an Ubuntu phone BQ E4.5. The > > >> project was > > >> driven by Canonical and BQ as the hardware OEM. The project > > >> died in March of > > >> this year, but is now moved to a community of OpenSource entusiast. > > > > Wasn't there also at least one company in Europe selling the > > > > > > Ubuntu phones? > > > > Yes, as I said BQ.com > > Unfortunately their hardware dos not seem to support Ubuntu any more. I found > the "Ubuntu Edition" under "obsolete models", even a cyanogen edition, but all > their current models run on Android. The rest of their homepage is all > marketing gibberish as it is the use, nowadays. Look for second hand devices of the BQ "Ubuntu Edition" (BQ does not produce nor sell them anymore). Such devices you could reflash to the software available at ubports.com matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From thejze at gmx.at Thu Sep 21 19:33:40 2017 From: thejze at gmx.at (Thomas Hejze) Date: Thu, 21 Sep 2017 19:33:40 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <20170919134453.26107fa7@debian-i7> References: <3771476.PIQjPmmXgn@linux.suse> <20170919134453.26107fa7@debian-i7> Message-ID: <3290527.E9oQLpDK85@linux.suse> Am Dienstag, 19. September 2017, 13:44:53 CEST schrieb Andreas Ronnquist: > > If I had the money, I would pledge for one of these: > > https://puri.sm/shop/librem-5/ > That project looks promising, however, I fear I am not able to spend $924.000 for my smartphone ;-) Anyway that is what I am looking for, I hope they will make it. Nevertheless, even then it will take at least one year for them to bring their product to the market. Looking at Tizen, Jolla, Firefox OS and Ubuntu Touch, I start to worry for the future of Open Source. Isn't there a business case for a FOSS smartphone? Best regards Thomas From guru at unixarea.de Thu Sep 21 20:20:59 2017 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 21 Sep 2017 20:20:59 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <14781413.dnX79WH965@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> <14781413.dnX79WH965@linux.suse> Message-ID: <20170921182059.GA2636@c720-r314251> El d?a jueves, septiembre 21, 2017 a las 06:54:43p. m. +0200, Thomas Hejze escribi?: > Hi Dotan, > > > Am Montag, 18. September 2017, 19:55:49 CEST schrieb Dotan Cohen: > > The answer pretty much depends on what smartphone features you are > > looking for. Do you need to run a web browser? Email integration? > > > well first of all I would like to make phone calls. > > I use kdepim for contacts, calendar and email, so kdepim should run on it or > at least be syncable. > > And gnupg should run on it. And yes, a secure browser, too. I have ported gpg2 and the password storage manger 'pass' to my Ubuntu phone BQ E4.5. I'm still working on the pcscd daemon to get the GnuPG-card working in the phone. The tricky part is that you normally can not install or compile additional software in the root file system of the device (because it's mounted for good reasons read-only). You must setup an additional complete system and chroot to it. If you later want to run such compiled/installed software from outside the chroot, you must set LD_IBRARY_PATH (...) so the software can find its stuff, for example in a small shell wrapper script: cat gpg2.sh #!/bin/sh LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/phablet/myRoot/usr/lib/arm-linux-gnueabihf export LD_LIBRARY_PATH /home/phablet/myRoot/usr/bin/gpg-agent --homedir /home/phablet/.gnupg \ --use-standard-socket --daemon \ --pinentry-program /home/phablet/myRoot/usr/bin/pinentry-curses /home/phablet/myRoot/usr/bin/gpg-connect-agent /bye PATH=$PATH:myRoot/usr/bin export PATH /home/phablet/myRoot/usr/bin/gpg2 $* This way I have gpg2 and pass working. I can SSH into the phone (or do the same on the terminal-app) and run: $ ssh phablet at ubphone Welcome to Ubuntu 15.04 (GNU/Linux 3.4.67 armv7l) phablet at ubuntu-phablet-bq:~$ phablet at ubuntu-phablet-bq:~$ ls -l .password-store/web/bla.gpg -rw------- 1 phablet phablet 356 Sep 20 12:58 .password-store/web/bla.gpg phablet at ubuntu-phablet-bq:~$ phablet at ubuntu-phablet-bq:~$ ./pass.sh web/bla ?????????????????????????????????????????????????????????????????????????????????????? ? Please enter the passphrase to unlock the secret key for the OpenPGP certificate: ? ? "Matthias Apitz " ? ? 2048-bit RSA key, ID 76254069, ? ? created 2017-09-20 (main key ID CBE83911). ? ? ? ? ? ? Passphrase _______________________________________________________________________ ? ? ? ? ? ?????????????????????????????????????????????????????????????????????????????????????? abc123 Username: guru at unixarea.de -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stefan.claas at posteo.de Thu Sep 21 20:49:49 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 20:49:49 +0200 Subject: Houston, we have a problem In-Reply-To: <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> Message-ID: <20170921204939.75749613@iria.my-fqdn.de> On Thu, 21 Sep 2017 10:55:26 -0400, Robert J. Hansen wrote: > > Question for the experts, how can a casual or new GnuPG user, like > > Alice and Bob, detect a Signature forgery on a pub key, when using > > Web based key servers? > > By remembering that anyone can create a key claiming to be anyone, and > that seeing a signature allegedly from Werner (or anyone) means > absolutely nothing until and unless you've verified the signing > certificate actually belongs to him. > > Key validation -- ensuring a key really belongs to who it says -- is > an important step. It cannot be skipped. It is not optional. Thanks for your reply. Let's assume the following: You would be also a german national, we both are friends and would have bad things in mind... I issue now fake signatures (from a german CA) to our fake keys* and then we would start some bad business on the Internet. How could customers, not pros like all you guys here on the list, could verify that we both are the persons the keys/signatures are claiming? * Due to my stupidness i no longer have access to my passphrase nor can i find my rev cert, in case someone would use my key, which i used here for signing previous post from me. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From m16+gnupg at monksofcool.net Thu Sep 21 21:11:17 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Thu, 21 Sep 2017 21:11:17 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921204939.75749613@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> Message-ID: <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> On 21.09.17 20:49, Stefan Claas wrote: > How could customers, not pros like all you guys here on the list, > could verify that we both are the persons the keys/signatures are > claiming? Legal identification is required. Since you are German, you can use https://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html as a reference for how this can be done. -Ralph From stefan.claas at posteo.de Thu Sep 21 21:38:44 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 21:38:44 +0200 Subject: Houston, we have a problem In-Reply-To: <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> Message-ID: <20170921213844.3d0b37e5@iria.my-fqdn.de> On Thu, 21 Sep 2017 21:11:17 +0200, Ralph Seichter wrote: > On 21.09.17 20:49, Stefan Claas wrote: > > > How could customers, not pros like all you guys here on the list, > > could verify that we both are the persons the keys/signatures are > > claiming? > > Legal identification is required. Since you are German, you can use > https://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html > as a reference for how this can be done. Hi Ralph, i am well aware of Heise's CA, because an old pub key of mine bears a sig3 from them. The thing is someone could issue a fake sig3 from Heise's CA key to someone else's pub key, without that that customers would detect it, nor Heise would know it, until of course they would see the keys in question. I don't know if CA's here in Germany scan key servers for their issued signatures. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From m16+gnupg at monksofcool.net Thu Sep 21 21:59:26 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Thu, 21 Sep 2017 21:59:26 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921213844.3d0b37e5@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> Message-ID: On 21.09.17 21:38, Stefan Claas wrote: > The thing is someone could issue a fake sig3 from Heise's CA key to > someone else's pub key, without that that customers would detect it, > nor Heise would know it, until of course they would see the keys in > question. I'm not certain what problem you see that has not been around for as long as PGP/GPG exists? You can only ever be certain of a signature if you have personally verified the signing key and the signer's identity. That's why the default owner trust level is "unknown" (not trusted). -Ralph From bradley.v.zynda at nasa.gov Thu Sep 21 20:24:10 2017 From: bradley.v.zynda at nasa.gov (Brad Zynda) Date: Thu, 21 Sep 2017 14:24:10 -0400 Subject: Passphrases no longer found in keyring Message-ID: <1987153e-4f48-bdbf-9147-e25e505916da@nasa.gov> Hello, Wanted to follow forward with the below topic here as Patrick from Enigmail suggested. Quick Summary: CentOS 7 1708 enigmail/pinetry now asks for passphrase all the time which was not the behavior prior to the recent update. Thanks, Brad Yeah just ran through all the troubleshooting stuff and all works as expected. Pop up box with hello key passhrase prompt and completion with gpg2 --sign no errors Will get in touch with the gnupg folks Thanks, Brad On 09/21/2017 02:00 PM, Patrick Brunschwig wrote: > This really looks like some issue with gpg-agent (as if it were started > by gpg each time something needs to be done). > > I can only recommend you to check our troubleshooting guide for gpg-agent: > https://www.enigmail.net/index.php/en/faq-en?view=topic&id=14 > > If that doesn't help, you better ask for help at the GnuPG mailing list. > > -Patrick > > On 21.09.17 14:42, Brad Zynda wrote: >> Here is the conf: >> >> # GPGConf disabled this option here at Thu 14 Sep 2017 10:10:58 AM EDT >> # default-cache-ttl 300 >> # GPGConf disabled this option here at Thu 14 Sep 2017 10:10:58 AM EDT >> # max-cache-ttl 999999 >> ###+++--- GPGConf ---+++### >> default-cache-ttl 86400 >> max-cache-ttl 864000 >> ###+++--- GPGConf ---+++### Thu 14 Sep 2017 10:21:45 AM EDT >> # GPGConf edited this configuration file. >> # It will disable options before this marked block, but it will >> # never change anything below these lines. >> use-standard-socket >> enable-ssh-support >> ~ >> >> The 2 at the bottom were added to try and fix the issue based on forum >> and mail list replies I had found, i can remove those if not needed. >> >> >> Thanks, >> Brad >> >> On 09/21/2017 08:36 AM, Patrick Brunschwig wrote: >>> You need to check the following two settings in gpg-agent.conf. The >>> values are in seconds. Standard default is 5 minutes, but Linux >>> distributions may choose to use different defaults. >>> >>> default-cache-ttl >>> max-cache-ttl >>> >>> -Patrick >>> >>> On 21.09.17 14:28, Brad Zynda wrote: >>>> Hi Patrick, >>>> >>>> Sorry I never received the first response I will look at the timeout >>>> settings, any in particular? >>>> >>>> and will ps auxx gpg-agent. >>>> >>>> Thanks, >>>> Brad >>>> >>>> On 09/21/2017 08:22 AM, Patrick Brunschwig wrote: >>>>> On 21.09.17 14:09, Brad Zynda wrote: >>>>>> Hello >>>>>> >>>>>> With Centos 7.4 (1708) enigmail now constantly asks for a passphrase >>>>>> (Pinetry-gtk-2) box. >>>>>> >>>>>> Thunderbird 52.3.0 64bit >>>>>> Enigmail 1.9.8.2 >>>>>> >>>>>> Added use-standard-socket to .gnupg/gpg-agent.conf and rebooted, didn't >>>>>> help. >>>>>> >>>>>> tried a fresh install of thunderbird and enigmail, created new keys, >>>>>> still asking for passphrase constantly. >>>>> >>>>> I already replied to your first email on 09/17. Did you follow my advice? >>>>> >>>>> This either means that the timeout settings are not correct, or that >>>>> gpg-agent is terminated after every operation. You can check the latter >>>>> doing "ps ax | grep gpg-agent". >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> >>> >>> > > _______________________________________________ enigmail-users mailing list enigmail-users at enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net From stefan.claas at posteo.de Thu Sep 21 22:11:26 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 22:11:26 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> Message-ID: <20170921221126.2af714c2@iria.my-fqdn.de> On Thu, 21 Sep 2017 21:59:26 +0200, Ralph Seichter wrote: > On 21.09.17 21:38, Stefan Claas wrote: > > > The thing is someone could issue a fake sig3 from Heise's CA key to > > someone else's pub key, without that that customers would detect it, > > nor Heise would know it, until of course they would see the keys in > > question. > > I'm not certain what problem you see that has not been around for as > long as PGP/GPG exists? You can only ever be certain of a signature if > you have personally verified the signing key and the signer's > identity. That's why the default owner trust level is "unknown" (not > trusted). Well, call me a stupid Mac dummie, but how in the world could GnuPG users , living in different areas verify that? As one more example i give name here Governikus CA. If someone would issue a fake sig3 from Governikus to someone else how could you, for example, verify that the sig3 is from Governikus? https://pgp.governikus-eid.de/pgp/ Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From rjh at sixdemonbag.org Thu Sep 21 22:13:56 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Sep 2017 16:13:56 -0400 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> Message-ID: <645876b3-5c7d-c8d7-7014-ee024a1e50d5@sixdemonbag.org> > I'm not certain what problem you see that has not been around for as > long as PGP/GPG exists? You can only ever be certain of a signature if > you have personally verified the signing key and the signer's identity. > That's why the default owner trust level is "unknown" (not trusted). About 25 years ago I first saw the suggestion that signatures from unvalidated certificates should simply not be visible to the end-user, as a signature from an unvalidated certificate is meaningless and the risk of people believing "oh, Frank (or whoever) signed this!" is so high. (A command of --list-all-sigs would need to be added, to force display of signatures from unvalidated certificates.) I've thought it was a good idea ever since I first saw it. I have always been in a distinct minority, though... From rjh at sixdemonbag.org Thu Sep 21 22:16:12 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Sep 2017 16:16:12 -0400 Subject: Houston, we have a problem In-Reply-To: <20170921221126.2af714c2@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> Message-ID: > If someone would issue a fake sig3 from Governikus to someone > else how could you, for example, verify that the sig3 is from > Governikus? By validating Governikus's certificate. You seem to be asking the same question (and getting the same answer) over and over again. Perhaps try a different phrasing? Or is it that the answer isn't clear? From stefan.claas at posteo.de Thu Sep 21 22:37:38 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 22:37:38 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> Message-ID: <20170921223738.7ac9ff43@iria.my-fqdn.de> On Thu, 21 Sep 2017 16:16:12 -0400, Robert J. Hansen wrote: > > If someone would issue a fake sig3 from Governikus to someone > > else how could you, for example, verify that the sig3 is from > > Governikus? > > By validating Governikus's certificate. Do i understand you right, i validate Werner's pub key and when i get a signed email from Erika Mustermann the sig should be then o.k. from her, because i signed Werner's key? > You seem to be asking the same question (and getting the same answer) > over and over again. Perhaps try a different phrasing? Or is it that > the answer isn't clear? I'm sorry! Let me say one last word. If i would be a programmer of software like GnuPG, my software would not allow to receive unwanted signatures on my pub key, nor would it allow that someone else can fake a sig on someone else's pub key with my key-id. Good night and best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From m16+gnupg at monksofcool.net Thu Sep 21 22:38:06 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Thu, 21 Sep 2017 22:38:06 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921221126.2af714c2@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> Message-ID: <2f3e620e-3e94-7515-42ea-8ff4dd0e2b74@monksofcool.net> On 21.09.17 22:11, Stefan Claas wrote: > > You can only ever be certain of a signature if you have personally > > verified the signing key and the signer's identity. > > Well, call me a stupid Mac dummie, but how in the world could GnuPG > users , living in different areas verify that? They can't. That's one of the reasons the "web of trust" is a tricky concept. Among all of the people I know to use PGP, I trust only two to verify both key fingerprints and identities as thoroughly as I do. That means I usually have to jump through hoops to verify stuff myself, and that only works for people I have personally met (and checked their Personalausweis or what have you). My web of trust is almost non-existent. Yours might be extensive. It all depends on what you verify yourself and who else you trust to verify. As Robert wrote, you seem to keep rehashing the same issue, and an old one at that. > https://pgp.governikus-eid.de/pgp/ You mean there are people who actually use Online-PA, and trust the BSI on top of that? You're kidding, right? ;-) I neither care nor trust what Governikus signs. I've been providing IT security services for decades, and find it extremely hard to trust others in this field, based on my own experience. -Ralph From m16+gnupg at monksofcool.net Thu Sep 21 23:05:24 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Thu, 21 Sep 2017 23:05:24 +0200 Subject: Houston, we have a problem In-Reply-To: <645876b3-5c7d-c8d7-7014-ee024a1e50d5@sixdemonbag.org> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <645876b3-5c7d-c8d7-7014-ee024a1e50d5@sixdemonbag.org> Message-ID: On 21.09.17 22:13, Robert J. Hansen wrote: > About 25 years ago I first saw the suggestion that signatures from > unvalidated certificates should simply not be visible to the end-user > [...] Yeah, that would be one way to make these sigs less obvious. Of course it does not solve the underlying issue, but for the layman it might be an improvement. -Ralph From rjh at sixdemonbag.org Thu Sep 21 23:06:18 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Sep 2017 17:06:18 -0400 Subject: Houston, we have a problem In-Reply-To: <20170921223738.7ac9ff43@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> Message-ID: > Do i understand you right, i validate Werner's pub key and when > i get a signed email from Erika Mustermann the sig should be then > o.k. from her, because i signed Werner's key? No. When you see something claiming to be Werner's sig on Erika's certificate, ask yourself: * Is it correct? * Does the signing cert really belong to Werner? * Do you trust Werner? If you can positively answer all three questions 'yes', then you should trust it. Otherwise, you shouldn't. From stefan.claas at posteo.de Thu Sep 21 23:06:21 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 23:06:21 +0200 Subject: Houston, we have a problem In-Reply-To: <2f3e620e-3e94-7515-42ea-8ff4dd0e2b74@monksofcool.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <2f3e620e-3e94-7515-42ea-8ff4dd0e2b74@monksofcool.net> Message-ID: <20170921230621.7e273e3c@iria.my-fqdn.de> On Thu, 21 Sep 2017 22:38:06 +0200, Ralph Seichter wrote: > On 21.09.17 22:11, Stefan Claas wrote: > > > > You can only ever be certain of a signature if you have personally > > > verified the signing key and the signer's identity. > > > > Well, call me a stupid Mac dummie, but how in the world could GnuPG > > users , living in different areas verify that? > > They can't. That's one of the reasons the "web of trust" is a tricky > concept. Among all of the people I know to use PGP, I trust only two > to verify both key fingerprints and identities as thoroughly as I do. > That means I usually have to jump through hoops to verify stuff > myself, and that only works for people I have personally met (and > checked their Personalausweis or what have you). My web of trust is > almost non-existent. Yours might be extensive. It all depends on what > you verify yourself and who else you trust to verify. As Robert > wrote, you seem to keep rehashing the same issue, and an old one at > that. Thank you for your detailed point of view. > > https://pgp.governikus-eid.de/pgp/ > > You mean there are people who actually use Online-PA, and trust the > BSI on top of that? You're kidding, right? ;-) I neither care nor > trust what Governikus signs. I've been providing IT security services > for decades, and find it extremely hard to trust others in this > field, based on my own experience. Well, i used once their service to obtain a sig3. I think under normal circumstances this would be a better idea to check if a Personalausweis is valid or fake, assuming GnuPG Signatures could be used in the future for online business, because then "carefully" crafted WoT signatures would have imho no weight in the business world. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From m16+gnupg at monksofcool.net Thu Sep 21 23:11:23 2017 From: m16+gnupg at monksofcool.net (Ralph Seichter) Date: Thu, 21 Sep 2017 23:11:23 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921223738.7ac9ff43@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> Message-ID: <38d3cffb-ca6f-a466-3999-3fb19f4bb01a@monksofcool.net> On 21.09.17 22:37, Stefan Claas wrote: > If i would be a programmer of software like GnuPG, my software would > not allow to receive unwanted signatures on my pub key, nor would it > allow that someone else can fake a sig on someone else's pub key with > my key-id. If you can solve the design problem of having a decentralised key infrastucture, the ability for everyone to create and sign keys without third party involvement, and the detection/prevention of "fake" sigs (whatever fake may mean), I'm sure we all would be interested. ;-) -Ralph From dkg at fifthhorseman.net Thu Sep 21 23:05:35 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Sep 2017 17:05:35 -0400 Subject: Houston, we have a problem In-Reply-To: <20170921223738.7ac9ff43@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> Message-ID: <878th73gps.fsf@fifthhorseman.net> On Thu 2017-09-21 22:37:38 +0200, Stefan Claas wrote: > I'm sorry! Let me say one last word. If i would be a programmer of > software like GnuPG, my software would not allow to receive unwanted > signatures on my pub key The way the universe works is that once data is public, other data might refer to that public data, and even the person who created the first bit of data can't prevent it. An OpenPGP certificate is, at minimum: * a public primary key K * a User ID U * a signature from K that binds U to K Once this data is published, anyone with a different key X can make a new certification, which also claims that U is correctly bound to K. This is what "signing a key" means. Your choice of software implementation can't prevent those third-party certifications from being produced, nor from being published, nor can it prevent other people's software from discovering them and making inferences based on them. There are some good (and some bad) arguments that software capable of interpreting OpenPGP certificates should only accept third-party certifications that the first-party (the party being certified) has explicitly endorsed, which might come close to meeting your requirement here. But no one has spec'ed out exactly how to do that or written such a constraint, and existing OpenPGP software will continue to exist even if new (improved) software is developed and distributed. > nor would it allow that someone else can fake a sig on someone else's > pub key with my key-id. If by "key-id" you mean your actual public key, then the cryptography behind OpenPGP does actually enforce this already. It's not believed to be possible to forge an OpenPGP signature from any reasonably strong modern OpenPGP key. If by "key-id" you mean the 32-bit long thing like "D21739E9", then there's no way to cryptographically secure that -- it's just too low-entropy. I've written elsewhere about why key ids are bad: https://debian-administration.org/users/dkg/weblog/105 Hope this helps to clear things up, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From stefan.claas at posteo.de Thu Sep 21 23:24:48 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 23:24:48 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> Message-ID: <20170921232448.7dcb39f6@iria.my-fqdn.de> On Thu, 21 Sep 2017 17:06:18 -0400, Robert J. Hansen wrote: > > Do i understand you right, i validate Werner's pub key and when > > i get a signed email from Erika Mustermann the sig should be then > > o.k. from her, because i signed Werner's key? > > No. When you see something claiming to be Werner's sig on Erika's > certificate, ask yourself: > > * Is it correct? > * Does the signing cert really belong to Werner? > * Do you trust Werner? > > If you can positively answer all three questions 'yes', then you > should trust it. Otherwise, you shouldn't. I can only say now i don't know if i should ever "trust" signatures again on someone else's pub key, because in the past i have had only communicated with people i did not know personally. And with Erika's key example while trusting Werner's key i don't like the idea when clicking in the Web interface on Werner's key-id that it leads to Werner's key. That's all what i can say now. I better should start now using my class3 S/MIME certificate... Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Thu Sep 21 23:37:01 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 23:37:01 +0200 Subject: Houston, we have a problem In-Reply-To: <38d3cffb-ca6f-a466-3999-3fb19f4bb01a@monksofcool.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> <38d3cffb-ca6f-a466-3999-3fb19f4bb01a@monksofcool.net> Message-ID: <20170921233701.5ba33d86@iria.my-fqdn.de> On Thu, 21 Sep 2017 23:11:23 +0200, Ralph Seichter wrote: > On 21.09.17 22:37, Stefan Claas wrote: > > > If i would be a programmer of software like GnuPG, my software would > > not allow to receive unwanted signatures on my pub key, nor would it > > allow that someone else can fake a sig on someone else's pub key > > with my key-id. > > If you can solve the design problem of having a decentralised key > infrastucture, the ability for everyone to create and sign keys > without third party involvement, and the detection/prevention of > "fake" sigs (whatever fake may mean), I'm sure we all would be > interested. ;-) Long ago when we had a discussion here on the Mailing List on how to prevent unwanted signatures i made a proposal that signing someone's public key should work similar to revocation certificates. If you would like to sign my pub key you had to send me a, let's call it, Signature Request Certificate, if i accept it i enter my passphrase and then the Software would extract the needed signature bits from the request cert and add those bits to my pub key. Like i said i'm no programmer and can't therefore test if such a feature proposal would work. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Thu Sep 21 23:42:05 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 21 Sep 2017 23:42:05 +0200 Subject: Houston, we have a problem In-Reply-To: <878th73gps.fsf@fifthhorseman.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> <878th73gps.fsf@fifthhorseman.net> Message-ID: <20170921234157.1aaf0df4@iria.my-fqdn.de> On Thu, 21 Sep 2017 17:05:35 -0400, Daniel Kahn Gillmor wrote: > If by "key-id" you mean the 32-bit long thing like "D21739E9", then > there's no way to cryptographically secure that -- it's just too > low-entropy. I've written elsewhere about why key ids are bad: > > https://debian-administration.org/users/dkg/weblog/105 > > Hope this helps to clear things up, Yes, i was referring to those bits and thanks for your other detailed explanation. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Sep 22 00:28:20 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 21 Sep 2017 23:28:20 +0100 Subject: OT: Which smartphone would you use In-Reply-To: <3290527.E9oQLpDK85@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> <20170919134453.26107fa7@debian-i7> <3290527.E9oQLpDK85@linux.suse> Message-ID: <163702112.20170921232820@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 21 September 2017 at 6:33:40 PM, in , Thomas Hejze wrote:- > I start to worry for the > future of Open Source. Isn't there a business case > for a FOSS smartphone? I think Fairphone tries, but they still have proprietary hardware drivers. "Made using conflict-free minerals." Too dear for me (529 euros from Fairphone themselves, 465 GBP new or 385 GBP refurbished from . - -- Best regards MFPA When duty calls...hang up immediately -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWcQ9D18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +jmUAQDxchKAt309STLCAkGJTgEckUP7bB5r7UfrnovnogJRdQEA1ZkuiAVY8O3s 1cQfq6UukipLzxPPiQctndaZzUJ0NAGJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWcQ9D18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/7jvEACkLELN+gDQ4eMUddi+F8uB6ol9 srnKEDF0WtgEXLP40RaQDZkTbV3AtxLZh+vjoDUhaV2jHzUHZSizEcCbvhc3M5gK yoZaAEBERJ41l/vTQ2Fz/4uUo8CyVudnLOt/1XY1N9qafS2XD29HKACMpN5wPfa0 IPB6jmKrv0Rb3Btrb/KnVGbukkiyPB09Ranut4X7UsnZTl8t7c1A37m6jGFT4e0/ dRNB38IN7LHcFL/nbdg3Jq0KIXLJ/B8KsHdNlg4o6Lf47n3VFh2tlFO+C6fiyhWe DN/Yp/ZKKe8SybNkXopUv3cAnsb3aKfRkV6zXPURzj7lMiB43fwJex53NOBmanka pU5j7o7LmZzz6N02cSA/R59F9psTrjd1X51rpyQP+oK4hTJFvqRb2Dyr4Gw32etP D4ToJpqNZgck+JtNXjXr4BXsMLC2h3B1jjYF405nN4jqN6e9uP7WEwk4712GhSjP kbd39BxZMGb+CNisIFmkmt1MlMcw1xK5mTw97J8l3MbZWkFcz/epnBFE65WEw8h9 9/jMLS/he+hZF5yv9YGYv+r6VXx0glRHosMRcW/w56UKgxK0VfGVgfzRVHL2sgdr vxLESshqGwJx8agFVSDxuPf/VFlnkq0KyGPZkrqArJSTqmrGqH/dBRLQJB079oC7 kH80lDwaoFhRu4JGxg== =Dr8t -----END PGP SIGNATURE----- From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Sep 22 00:47:14 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 21 Sep 2017 23:47:14 +0100 Subject: automatic conversion from keyring to keybox files? Message-ID: <714482652.20170921234714@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Now that the upgrade path for GnuPG 2.0.x users is to 2.2.x versions, will be there any automatic conversion from keyring to keybox files, either offered by the installer or available as a command? - -- Best regards MFPA Don't cry because it is over - smile because it happened -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWcRBdF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +q0DAP49k3V/xfx9yCSC6hrQEEPUdqhcsZL2+jLQEtNFnLVW7wEApFUrtbW80Ijx dKrnc5qoSWN42HQk+TZNQK+SAQqcwwGJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWcRBdF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/1MLEACFmmyebuYeT0Suoo8YAED7cnp8 YqNawt7CGcs1ShJCPWVQJtCjyT44DylsrM3h7kB+dZPy79SYK2gOuv7rIpbdIP8H LpHOQfxf1nlRo54OAAi8vxA18Rb3e2KIvPsHR+ZawBK9zcnaIRp4yLsJPuHqqbWD 56hP8IoIDT+S+6IqMxTJ+eXhNo6x/6u5YzCWtTRuRy4TZl/702Dp+W4SJiqSe/Rj 4d6TG0/IhB66wvxSQooPNcUVxt/1M9n13/203uNdhU2VjlKfq12OekLzJF13ohf+ NVHIbaii0F7SADr2fI8Ru0GRAwHesFt08KMDA3i8mtSE7HDLebAfLM9sg0A+iwDr mJeZ0s/gdP/s74pZQKF+FNOcsr7xLMJGdyURHQmX+6mhlc7MaYgPERb8GtYTzx58 JDn8/3qPrNGhiKEVtvfLQAE77FpdSg3UP7sBJkWZXd1pze0SAMrlCghNwSiedha/ DDqDw21OKTCFwyuF1HPvRWZvEyLMIjll0QAgGbXqapYKNVHitMYCv0y6WByk1QO3 9fCReVj8xMdFZhneB0W3eZt3VrKkuvxEfEzAqt4YoJ2bn4G948DlH/rdeOGYXbQc L5+7LMxBI9JxIjjfHKBmHd2JwlZ6Q+YizNLfFJLLUJvv4BX3GZXTnjtdfNcMcuWu Rd7Z+hfqIsNtAhKbrg== =ZpxC -----END PGP SIGNATURE----- From angel at pgp.16bits.net Fri Sep 22 02:37:40 2017 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 Sep 2017 02:37:40 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921233701.5ba33d86@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> <38d3cffb-ca6f-a466-3999-3fb19f4bb01a@monksofcool.net> <20170921233701.5ba33d86@iria.my-fqdn.de> Message-ID: <1506040660.1175.4.camel@16bits.net> On 2017-09-21 at 23:37 +0200, Stefan Claas wrote: > Long ago when we had a discussion here on the Mailing List on > how to prevent unwanted signatures i made a proposal that > signing someone's public key should work similar to revocation > certificates. If you would like to sign my pub key you had to > send me a, let's call it, Signature Request Certificate, if i accept > it i enter my passphrase and then the Software would extract > the needed signature bits from the request cert and add those > bits to my pub key. Like i said i'm no programmer and can't > therefore test if such a feature proposal would work. > > Regards > Stefan Nope. This would solve the case of ?Key of legitimate user signed by fake user?? but not ?Fake user signed by another fake user?, which is the problem. ? Assuming the legitimate one would notice and not allow his key to be signed by the evil one, which is no problem, actually. The proposal would be technically feasible (invalidating all existing signatures, and probably conflicting with local sigs, but feasible). However, it wouldn't solve the underlying problem. Best From rjh at sixdemonbag.org Fri Sep 22 07:22:13 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 22 Sep 2017 01:22:13 -0400 Subject: Prince Jones v US Message-ID: <5c19ac6a-f367-583c-a1df-505a87732483@sixdemonbag.org> Good news for US citizens: _Prince Jones v US_ was decided Thursday. The important text from the opinion is recreated here, and the implications for encrypted email follow. * * * * * But in addition to the fact that people reasonably value and hope to protect the privacy of their location information, what necessitates our conclusion is the _method_ by which the government obtained the location information in this case. Unlike in a situation in which the government determines a person's location through visual surveillance or by employing the older generation of tracking devices, it cannot be argued that "the information obtained by [the government] in this case was ... readily available and in the public view". The cell-site simulator employed in this case gave the government a powerful person-locating capability that private actors do not have and that, as explained above, the government itself had previously lacked -- a capability only superficially analogous to the visual tracking of a suspect. And the simulator's operation involved exploitation of a security flaw in a device that most people now feel obligated to carry with them at all times. Allowing the government to deploy such a powerful tool without judicial oversight would surely "shrink the realm of guaranteed privacy" far below that which "existed when the Fourth Amendment was adopted". It would also place an individual in the difficult position either of accepting the risk that at any moment his or her cellphone could be converted into tracking device or of forgoing "necessary use of" the cellphone. We thus conclude that under ordinary circumstances, the use of a cell-site simulator to locate a person through his or her cellphone invades the person's actual, legitimate, and reasonable expectation of privacy in his or her location information and is a search. * * * * * The above is taken from the opinion -- citations omitted. But it appears to me this logic is immediately applicable to many different kinds of surveillance: namely, if it involves security flaws in common everyday technologies which millions of Americans entrust with their secrets and who really cannot reasonably avoid using... then it needs a warrant. The implications for electronic privacy in the United States should be clear. This is a really good development. :) From stefan.claas at posteo.de Fri Sep 22 10:03:18 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 10:03:18 +0200 Subject: Houston, we have a problem In-Reply-To: <1506040660.1175.4.camel@16bits.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <8256f10b-8817-0c00-5c32-87d019636847@sixdemonbag.org> <20170921204939.75749613@iria.my-fqdn.de> <6665bf74-ae96-737c-233e-7c6e484290f7@monksofcool.net> <20170921213844.3d0b37e5@iria.my-fqdn.de> <20170921221126.2af714c2@iria.my-fqdn.de> <20170921223738.7ac9ff43@iria.my-fqdn.de> <38d3cffb-ca6f-a466-3999-3fb19f4bb01a@monksofcool.net> <20170921233701.5ba33d86@iria.my-fqdn.de> <1506040660.1175.4.camel@16bits.net> Message-ID: <8d25bc87-1448-76bd-e757-7f685f12480b@posteo.de> Am 22.09.2017 um 02:37 schrieb ?ngel: > On 2017-09-21 at 23:37 +0200, Stefan Claas wrote: >> Long ago when we had a discussion here on the Mailing List on >> how to prevent unwanted signatures i made a proposal that >> signing someone's public key should work similar to revocation >> certificates. If you would like to sign my pub key you had to >> send me a, let's call it, Signature Request Certificate, if i accept >> it i enter my passphrase and then the Software would extract >> the needed signature bits from the request cert and add those >> bits to my pub key. Like i said i'm no programmer and can't >> therefore test if such a feature proposal would work. >> >> Regards >> Stefan > > Nope. This would solve the case of ?Key of legitimate user signed by > fake user?? but not ?Fake user signed by another fake user?, which is > the problem. > > > ? Assuming the legitimate one would notice and not allow his key to be > signed by the evil one, which is no problem, actually. > > > The proposal would be technically feasible (invalidating all existing > signatures, and probably conflicting with local sigs, but feasible). > However, it wouldn't solve the underlying problem. > > Thanks for your insights, much appreciated! Regards Stefan From alci at mecadu.org Fri Sep 22 10:36:45 2017 From: alci at mecadu.org (Franck Routier) Date: Fri, 22 Sep 2017 10:36:45 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <3290527.E9oQLpDK85@linux.suse> References: <3771476.PIQjPmmXgn@linux.suse> <20170919134453.26107fa7@debian-i7> <3290527.E9oQLpDK85@linux.suse> Message-ID: <8488acb3-7da7-8014-a324-a0f8a6b8f007@mecadu.org> Hi, Jolla did an official port of SailfishOS to Sony Xperia X hardware. It's about one year old, but you still can get one in Europe for around 300?. Then you'll have to buy (49?) a Sailfish for Xperia license, and install it. The only point is the the image is not yet available for purchase, but it should be a matter of days... See https://blog.jolla.com/sailfishx/ Regards, Franck Le 21/09/2017 ? 19:33, Thomas Hejze a ?crit : > Am Dienstag, 19. September 2017, 13:44:53 CEST schrieb Andreas Ronnquist: > >> If I had the money, I would pledge for one of these: >> >> https://puri.sm/shop/librem-5/ >> > > That project looks promising, however, I fear I am not able to spend $924.000 > for my smartphone ;-) > > Anyway that is what I am looking for, I hope they will make it. Nevertheless, > even then it will take at least one year for them to bring their product to > the market. > > Looking at Tizen, Jolla, Firefox OS and Ubuntu Touch, I start to worry for the > future of Open Source. Isn't there a business case for a FOSS smartphone? > > Best regards > Thomas > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From jerry at seibercom.net Fri Sep 22 11:55:00 2017 From: jerry at seibercom.net (Jerry) Date: Fri, 22 Sep 2017 05:55:00 -0400 Subject: Prince Jones v US In-Reply-To: <5c19ac6a-f367-583c-a1df-505a87732483@sixdemonbag.org> References: <5c19ac6a-f367-583c-a1df-505a87732483@sixdemonbag.org> Message-ID: <20170922055500.00003273@seibercom.net> On Fri, 22 Sep 2017 01:22:13 -0400, Robert J. Hansen stated: >Good news for US citizens: _Prince Jones v US_ was decided Thursday. >The important text from the opinion is recreated here, and the >implications for encrypted email follow. > >* * * * * > >But in addition to the fact that people reasonably value and hope to >protect the privacy of their location information, what necessitates our >conclusion is the _method_ by which the government obtained the location >information in this case. Unlike in a situation in which the government >determines a person's location through visual surveillance or by >employing the older generation of tracking devices, it cannot be argued >that "the information obtained by [the government] in this case was ... >readily available and in the public view". The cell-site simulator >employed in this case gave the government a powerful person-locating >capability that private actors do not have and that, as explained above, >the government itself had previously lacked -- a capability only >superficially analogous to the visual tracking of a suspect. And the >simulator's operation involved exploitation of a security flaw in a >device that most people now feel obligated to carry with them at all >times. Allowing the government to deploy such a powerful tool without >judicial oversight would surely "shrink the realm of guaranteed privacy" >far below that which "existed when the Fourth Amendment was adopted". It >would also place an individual in the difficult position either of >accepting the risk that at any moment his or her cellphone could be >converted into tracking device or of forgoing "necessary use of" the >cellphone. We thus conclude that under ordinary circumstances, the use >of a cell-site simulator to locate a person through his or her cellphone >invades the person's actual, legitimate, and reasonable expectation of >privacy in his or her location information and is a search. > >* * * * * > >The above is taken from the opinion -- citations omitted. But it >appears to me this logic is immediately applicable to many different >kinds of surveillance: namely, if it involves security flaws in common >everyday technologies which millions of Americans entrust with their >secrets and who really cannot reasonably avoid using... then it needs a >warrant. > >The implications for electronic privacy in the United States should be >clear. This is a really good development. :) Can you cite the case #. All I could find is an old "local appeals court in Washington, D.C." ruling. I found nothing under the US Supreme Court. -- Jerry From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 14:27:13 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 14:27:13 +0200 Subject: Prince Jones v US In-Reply-To: <20170922055500.00003273@seibercom.net> References: <5c19ac6a-f367-583c-a1df-505a87732483@sixdemonbag.org> <20170922055500.00003273@seibercom.net> Message-ID: <4b5b82a7-ad79-6865-91c8-d73cfc1afd81@sumptuouscapital.com> On 09/22/2017 11:55 AM, Jerry wrote: > Can you cite the case #. All I could find is an old "local appeals court in > Washington, D.C." ruling. I found nothing under the US Supreme Court. See https://www.dccourts.gov/sites/default/files/2017-09/15-CF-322.pdf DISTRICT OF COLUMBIA COURT OF APPEALS No. 15-CF-322 09/21/2017 P RINCE J ONES , A PPELLANT , V . U NITED S TATES , A PPELLEE . Appeal from the Superior Court of the District of Columbia (CF1-18140-13) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Great things are not accomplished by those who yield to trends and fads and popular opinion." (Jack Kerouac) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Sep 22 16:18:51 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 22 Sep 2017 10:18:51 -0400 Subject: Prince Jones v US In-Reply-To: <20170922055500.00003273@seibercom.net> References: <5c19ac6a-f367-583c-a1df-505a87732483@sixdemonbag.org> <20170922055500.00003273@seibercom.net> Message-ID: <69ceb2e7-4b84-c1cf-29b5-609d4ff8f61d@sixdemonbag.org> > Can you cite the case #. All I could find is an old "local appeals court in > Washington, D.C." ruling. I found nothing under the US Supreme Court. It was a DC Court of Appeals decision, not SCOTUS. It appears unlikely to hit SCOTUS. https://www.dccourts.gov/sites/default/files/2017-09/15-CF-322.pdf From sandhya.sharma at morpho.com Fri Sep 22 14:51:16 2017 From: sandhya.sharma at morpho.com (SHARMA Sandhya (MORPHO)) Date: Fri, 22 Sep 2017 12:51:16 +0000 Subject: Use of Passphrase Callback Message-ID: <46eaa07fffa64100a63f07e47c3ec55f@Y0032RM.rd1.rf1> Hello, I am Using gnupg on windows and want to use "Passphrase Callback" functionality to input password for private key. My current lines of code is: error = gpgme_set_pinentry_mode(context,GPGME_PINENTRY_MODE_LOOPBACK); gpgme_passphrase_cb_t func = &passphrase_callback; gpgme_pinentry_mode_t pinMode = gpgme_get_pinentry_mode(context); void *pp = 0; gpgme_set_passphrase_cb(context,func,pp); and declaration of gpgme_passphrase_cb_t is gpgme_error_t passphrase_callback(void *opaque, const char *uid_hint, const char *desc,int prev_was_bad, int fd) but breakpoint on this function never hits. Kindly provide help on this or any example used to implement Passphrase CallBack. Thanks & Regards, Sandhya Sharma # " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." # -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Fri Sep 22 17:24:01 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 22 Sep 2017 17:24:01 +0200 Subject: gpg 2.1.19 fails to generate key pair Message-ID: <20170922152401.GA3739@c720-r314251> Hello, I've compile gpg 2.1.19 and all the required shared libs from source. The cmd sequence: LD_LIBRARY_PATH=/home/phablet/myRoot/usr/local/lib export LD_LIBRARY_PATH PATH=/home/phablet/myRoot/usr/local/bin:$PATH export PATH GNUPGHOME=/home/phablet/.gnupg export GNUPGHOME /home/phablet/myRoot/usr/local/bin/gpg-agent --homedir /home/phablet/.gnupg \ --daemon \ --pinentry-program /home/phablet/myRoot/usr/bin/pinentry-curses /home/phablet/myRoot/usr/local/bin/gpg-connect-agent /bye /home/phablet/myRoot/usr/local/bin/gpg2 --full-generate-key fails at the end (after the dialog and asking the passphrase) with: gpg: signing failed: End of file gpg: make_keysig_packet failed: End of file Key generation failed: End of file I instructed via gpg-agent.conf the gpg-agent to do a debug log which follows. The proc gpg-agent crashes with SIG_BUS. Any help? matthias 2017-09-22 16:46:49 gpg-agent[15163] listening on socket '/run/user/32011/gnupg/S.gpg-agent' 2017-09-22 16:46:49 gpg-agent[15163] listening on socket '/run/user/32011/gnupg/S.gpg-agent.extra' 2017-09-22 16:46:49 gpg-agent[15163] listening on socket '/run/user/32011/gnupg/S.gpg-agent.browser' 2017-09-22 16:46:49 gpg-agent[15163] listening on socket '/run/user/32011/gnupg/S.gpg-agent.ssh' 2017-09-22 16:46:49 gpg-agent[15166] gpg-agent (GnuPG) 2.1.19 started 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK Pleased to meet you, process 15167 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- RESET 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION ttyname=/dev/pts/58 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION ttytype=linux 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Y5hTZhXCoe 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION putenv=QT_IM_MODULE=maliitphablet 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION lc-ctype=en_GB.UTF-8 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- OPTION lc-messages=en_GB.UTF-8 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:49 gpg-agent[15166] DBG: chan_9 <- [eof] 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK Pleased to meet you, process 15169 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- RESET 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION ttyname=/dev/pts/58 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION ttytype=linux 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Y5hTZhXCoe 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION putenv=QT_IM_MODULE=maliitphablet 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION lc-ctype=en_GB.UTF-8 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION lc-messages=en_GB.UTF-8 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- GETINFO version 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> D 2.1.19 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION allow-pinentry-notify 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- OPTION agent-awareness=2.1.0 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- RESET 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- GENKEY 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> S INQUIRE_MAXLEN 1024 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> INQUIRE KEYPARAM 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- D (genkey(rsa(nbits 4:2048))) 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- END 2017-09-22 16:46:59 gpg-agent[15166] starting a new PIN Entry 2017-09-22 16:46:59 gpg-agent[15166] DBG: connection to PIN entry established 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 -> INQUIRE PINENTRY_LAUNCHED 15347 unknown 0.8.3 ? ? ? 2017-09-22 16:46:59 gpg-agent[15166] DBG: chan_9 <- END 2017-09-22 16:47:30 gpg-agent[15166] starting a new PIN Entry 2017-09-22 16:47:30 gpg-agent[15166] DBG: connection to PIN entry established 2017-09-22 16:47:30 gpg-agent[15166] DBG: chan_9 -> INQUIRE PINENTRY_LAUNCHED 15474 unknown 0.8.3 ? ? ? 2017-09-22 16:47:30 gpg-agent[15166] DBG: chan_9 <- END 2017-09-22 16:47:34 gpg-agent[15166] starting a new PIN Entry 2017-09-22 16:47:34 gpg-agent[15166] DBG: connection to PIN entry established 2017-09-22 16:47:34 gpg-agent[15166] DBG: chan_9 -> INQUIRE PINENTRY_LAUNCHED 15482 unknown 0.8.3 ? ? ? 2017-09-22 16:47:34 gpg-agent[15166] DBG: chan_9 <- END 2017-09-22 16:47:38 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 30 128 2017-09-22 16:47:38 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 30 128 2017-09-22 16:48:38 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 30 128 2017-09-22 16:48:38 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 38 128 2017-09-22 16:48:59 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 38 128 2017-09-22 16:49:00 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 46 128 2017-09-22 16:49:03 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 46 128 2017-09-22 16:49:05 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 54 128 2017-09-22 16:49:08 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 54 128 2017-09-22 16:49:11 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 54 128 2017-09-22 16:49:14 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 54 128 2017-09-22 16:49:16 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:49:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:49:22 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:49:25 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:49:28 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:49:29 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 70 128 2017-09-22 16:49:32 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 70 128 2017-09-22 16:49:35 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 70 128 2017-09-22 16:49:38 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 70 128 2017-09-22 16:49:41 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:44 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:47 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:50 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:53 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:56 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:49:58 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 86 128 2017-09-22 16:50:01 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 86 128 2017-09-22 16:50:02 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 94 128 2017-09-22 16:50:06 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 94 128 2017-09-22 16:50:06 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 102 128 2017-09-22 16:50:09 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 110 128 2017-09-22 16:50:11 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 118 128 2017-09-22 16:50:15 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 118 128 2017-09-22 16:50:15 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 126 128 2017-09-22 16:50:18 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 128 128 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen X 100 100 2017-09-22 16:50:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 0 128 2017-09-22 16:50:25 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 14 128 2017-09-22 16:50:29 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 14 128 2017-09-22 16:50:30 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 22 128 2017-09-22 16:50:33 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 22 128 2017-09-22 16:50:33 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 30 128 2017-09-22 16:50:36 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 30 128 2017-09-22 16:50:37 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 38 128 2017-09-22 16:50:40 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 38 128 2017-09-22 16:50:40 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 46 128 2017-09-22 16:50:44 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 46 128 2017-09-22 16:50:44 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 54 128 2017-09-22 16:50:47 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:50:51 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 62 128 2017-09-22 16:50:52 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 70 128 2017-09-22 16:50:56 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 78 128 2017-09-22 16:50:59 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 86 128 2017-09-22 16:51:02 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 86 128 2017-09-22 16:51:02 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 94 128 2017-09-22 16:51:05 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 102 128 2017-09-22 16:51:08 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 110 128 2017-09-22 16:51:10 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 118 128 2017-09-22 16:51:13 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 118 128 2017-09-22 16:51:16 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 126 128 2017-09-22 16:51:19 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 126 128 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS need_entropy X 128 128 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen + 0 0 2017-09-22 16:51:21 gpg-agent[15166] DBG: chan_9 -> S PROGRESS primegen X 100 100 2017-09-22 16:51:21 gpg-agent[15166] DBG: p= :+c6280f1a49907c0d81b305f9a0240775c6e24710574a076036f4d70db1cfe02e \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 8ab4cfa5c0e6da76c587c4f9045e3a6389fe7c0c57ae36f00cb95cce05179141 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: c86928929c90b95ef2d623a0ead52da6cf8908de960e688314bcb49150f007c0 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: f12ff2126e659aa536ce198e8bbcbdac90fbf359e6e5c1fa3bed3790bfcd7d25 2017-09-22 16:51:21 gpg-agent[15166] DBG: q= :+ffc1f0e1038df2bba07f2be661d34fa93dc65c8e5295eecd98cbe2f9e23a1ae1 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 5afee816e97b87e507abad6424294c18ea7b9d7032f2d65659f7523b9f25f8ab \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 429ceb98e07d4363630f4a0a251b29c5eeedb2ed7b667d6ff05fef74150d5083 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: c465c01e415fd04f276edcd05563547c91d9bf80e0f00f8243242198bc94b5ed 2017-09-22 16:51:21 gpg-agent[15166] DBG: phi= :+c5f805b24c36a4b1d0c65d73c3b156dac637c5d7e97b65a623e25d81d46418b8 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 3f10dff24eee59bea7e73f176de3a189912935edde7b37abd44bdfa4a1e91444 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 91a79cc263b02aa2e602e1a41db4709d7226b9bece6cb6e70429b1a151de371b \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: b27ed9eb762cb88890a9bf29bc3b75a3168f84b38b29c918c25bd12a269a9d54 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 3f2b6f36e86dad0ff73c2c14c544aec8f9f841d3cc1720596b435f7fdcd1861f \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 0c8ac8cd37ec73eec868ed85b2d45a73da275e883ba33776e3c4189f02133c5a \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: b5a01818b4d12d9d6e1ed767e05e1d62ab575f1cbde02c65ad78c1c1877544c5 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: ac85550f64238fe228c58ce4335d7bc1bf08ce8054a0a899c7b64d1fe3b9d130 2017-09-22 16:51:21 gpg-agent[15166] DBG: g= :+04 2017-09-22 16:51:21 gpg-agent[15166] DBG: f= :+317e016c930da92c7431975cf0ec55b6b18df175fa5ed96988f897607519062e \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 0fc437fc93bb966fa9f9cfc5db78e862644a4d7b779ecdeaf512f7e9287a4511 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 2469e73098ec0aa8b980b869076d1c275c89ae6fb39b2db9c10a6c6854778dc6 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: ec9fb67add8b2e22242a6fca6f0edd68c5a3e12ce2ca72463096f44a89a6a755 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 0fcadbcdba1b6b43fdcf0b0531512bb23e7e1074f305c8165ad0d7dff7346187 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: c322b2334dfb1cfbb21a3b616cb5169cf689d7a20ee8cdddb8f10627c084cf16 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: ad6806062d344b675b87b5d9f8178758aad5d7c72f780b196b5e307061dd5131 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 6b215543d908e3f88a3163390cd75ef06fc233a015282a2671ed9347f8ee744c 2017-09-22 16:51:21 gpg-agent[15166] DBG: n= :+c5f805b24c36a4b1d0c65d73c3b156dac637c5d7e97b65a623e25d81d46418b8 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 3f10dff24eee59bea7e73f176de3a189912935edde7b37abd44bdfa4a1e91444 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 91a79cc263b02aa2e602e1a41db4709d7226b9bece6cb6e70429b1a151de371b \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: b27ed9eb762cb88890a9bf29bc3b75a3168f84b38b29c918c25bd12a269a9d56 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 05156f32358c1bd9196e5df4c73c05e7fea0e57275f716873b04198770db812e \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: f23e8089e24ed64a959c5fe2db5be0f04ea17804c64444bd4a74c7a8a650c647 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: c0a62c4431df2a5fc4044512f04e74cf69ce1ae8cf551258b29565c6ed729d0a \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 621b074013e8fad687028343147d8deae1de815b1c767a1646c7a649601c0441 2017-09-22 16:51:21 gpg-agent[15166] DBG: e= :+010001 2017-09-22 16:51:21 gpg-agent[15166] DBG: d= :+266b12bdee74e742bbbb972cad5437c1069911bbac2b9e871ead220cdd391ca3 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: fad72d42a2873662ddc62e73ff471ed4e9d707c874f5d010b8470e2c6ea06326 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: c86670f13773db5e5809449d3b078698436c18fd5aa575dc40ae4fb2b906c906 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 86bdffcfe653d8eee5b60f6b4bc47538945aff3b719d0711d73c06cc29883552 \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 815cce3d275f8b678f08fe1bfcc96eab0179a85ab01f67cf7a95ad4d8cbe9b8a \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: e07df9687bfb16e786bc7825cb55d304eb17db4c5058851dbd2753c8ddd7fa4d \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 37348da093cc894fe52c368cc9d9b1d5b15f280dd59a50bb5dae12d9da0e0bad \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: d9e45924bebff8ff007f0fefc43916d87b587beca31fb7807a659a337f57d2ed 2017-09-22 16:51:21 gpg-agent[15166] DBG: u= :+0338a9db6d7bd87e4293cec0b4c2e73b842a6df53d8279417fc97036f8bd7e4d \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: a3b68dd0daa2bac2ee1a656dc1a2c528e2bdb9cefc43b181495e302c3cf6c2df \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: 73afc1853abcc24d21db6335b636cc973a9da8face1780ff2bb55abc8e2deb8e \ 2017-09-22 16:51:21 gpg-agent[15166] DBG: b4004a3d7ee48aab59b5a22f15702fed255b4c8bb97ff22c95a9ac2c1b6c4b4c 2017-09-22 16:51:22 gpg-agent[15166] DBG: storing private key 2017-09-22 16:51:25 gpg-agent[15166] S2K calibration: 2466816 -> 100ms 2017-09-22 16:51:25 gpg-agent[15166] DBG: agent_put_cache '72C072DF8E8A7E956E83631D' (mode 5) requested ttl=900 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> S CACHE_NONCE 72C072DF8E8A7E956E83631D 2017-09-22 16:51:25 gpg-agent[15166] DBG: returning public key 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(286 byte(s) skipped) ] 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 <- RESET 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 <- SIGKEY 7A4385DA9EB9353BB10B23B473A005546A5DAE36 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22[User+ID+not+found]%22%0A2048-bit+RSA+key,+ID+E63AE41B03128A87,%0Acreated+2017-09-22.%0A 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 <- SETHASH 8 C32083165BB1A88A814A1BB2F62984D2B521AEAB1210B9B32648E0FAEC28F206 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 -> OK 2017-09-22 16:51:25 gpg-agent[15166] DBG: chan_9 <- PKSIGN -- 72C072DF8E8A7E956E83631D 2017-09-22 16:51:25 gpg-agent[15166] DBG: agent_get_cache '72C072DF8E8A7E956E83631D' (mode 5) ... 2017-09-22 16:51:25 gpg-agent[15166] DBG: ... hit -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stefan.claas at posteo.de Fri Sep 22 19:23:22 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 19:23:22 +0200 Subject: Houston, we have a problem In-Reply-To: <20170921164431.48a03cb3@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> Message-ID: <20170922192322.2d0cfba2@iria.my-fqdn.de> On Thu, 21 Sep 2017 16:44:57 +0200, Stefan Claas wrote: > Hi all, > > http://pgp.zdv.uni-mainz.de:11371/pks/lookup?op=vindex&search=Erika+Mustermann > > Question for the experts, how can a casual or new GnuPG user, like > Alice and Bob, detect a Signature forgery on a pub key, when using > Web based key servers? > > Note for native English speakers, Erika Mustermann is well known among > german users, same as Jon Doe. O.k. i just tested a bit and this is a bug int the Web Interface and in GnuPG's CLI Interface. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From wk at gnupg.org Fri Sep 22 20:19:14 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Sep 2017 20:19:14 +0200 Subject: gpg 2.1.19 fails to generate key pair In-Reply-To: <20170922152401.GA3739@c720-r314251> (Matthias Apitz's message of "Fri, 22 Sep 2017 17:24:01 +0200") References: <20170922152401.GA3739@c720-r314251> Message-ID: <87r2uyegv1.fsf@wheatstone.g10code.de> On Fri, 22 Sep 2017 17:24, guru at unixarea.de said: > I instructed via gpg-agent.conf the gpg-agent to do a debug log which > follows. The proc gpg-agent crashes with SIG_BUS. That is why you see and EOF error from gpg. We did a few more release after 2.1.19, which was released on March 1. Not all fixed bugs are noted in the NEWS and it is also possible that the SIGBUS comes from Libgcrypt. (run gpg-agent --version to see the version of Libgcrypt). Please first try to build with a recent version (2.2.1 is current but 2.1.23 should be okay) and the latest version of the respective Libgcrypt branch. That would be easier for us than to try to figure out a bug we might have already fixed. What OS and which platform are you using? I assume it is a BSD (or Plan-9 ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Sep 22 20:29:07 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Sep 2017 20:29:07 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922192322.2d0cfba2@iria.my-fqdn.de> (Stefan Claas's message of "Fri, 22 Sep 2017 19:23:22 +0200") References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> Message-ID: <87mv5megek.fsf@wheatstone.g10code.de> On Fri, 22 Sep 2017 19:23, stefan.claas at posteo.de said: > O.k. i just tested a bit and this is a bug int the Web Interface and in > GnuPG's CLI Interface. I don't see a bug here. However, given that you use Posteo, you are in the good position to use the Web Key Directory feature. This requires 2.2.1 because we had to add some workaround for key upload due to changes at Posteo which we didn't caught earlier. So people sending mail to you using a GnuPG 2.2 would find your key instantly. It is not there right now: /usr/local/libexec/gpg-wks-client -v --check stefan.claas at posteo de gpg-wks-client: public key for 'stefan.claas at posteo.de' NOT found via WKD You may use the latest Enigmail or Kmail to automate the upload but you can also use Posteo's Web interface to upload the key. But take care: Posteo does not allow a Name in the user id, only the mail address (addr-spec) is allowed. Thus you need to add a second user id with just your mailaddress and use gpg's filter stuff to export only that UID. GnuPG 2.2.1 automates that tasks and creates another user if needed. If you want to test this feature you may send a mail to clara.chefin at posteo de, which is a test account of us. (You can also write to the owner of Posteo to ask him why they still have an invalid certificate for posteo.net addresses ;-). > > Regards > Stefan -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Fri Sep 22 20:48:43 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 22 Sep 2017 20:48:43 +0200 Subject: gpg 2.1.19 fails to generate key pair In-Reply-To: <87r2uyegv1.fsf@wheatstone.g10code.de> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> Message-ID: <20170922184843.GA2196@c720-r314251> El d?a viernes, septiembre 22, 2017 a las 08:19:14p. m. +0200, Werner Koch escribi?: > On Fri, 22 Sep 2017 17:24, guru at unixarea.de said: > > > I instructed via gpg-agent.conf the gpg-agent to do a debug log which > > follows. The proc gpg-agent crashes with SIG_BUS. > > That is why you see and EOF error from gpg. > I can imagine. That's why I attached the log of the gpg-agent. > We did a few more release after 2.1.19, which was released on March 1. > Not all fixed bugs are noted in the NEWS and it is also possible that > the SIGBUS comes from Libgcrypt. (run gpg-agent --version to see the > version of Libgcrypt). > > Please first try to build with a recent version (2.2.1 is current but > 2.1.23 should be okay) and the latest version of the respective > Libgcrypt branch. That would be easier for us than to try to figure out > a bug we might have already fixed. Ok. I will update to the most recent version. Btw: libcrypt is 1.7.0. > What OS and which platform are you using? I assume it is a BSD (or > Plan-9 ;-). No, wrong guess in this case. It is: phablet at ubuntu-phablet-bq:~$ uname -a Linux ubuntu-phablet 3.4.67 #1 SMP PREEMPT Mon Jun 6 12:04:40 UTC 2016 b75400e armv7l armv7l armv7l GNU/Linux an Ubuntu based smartphone. matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stefan.claas at posteo.de Fri Sep 22 21:34:22 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 21:34:22 +0200 Subject: Houston, we have a problem In-Reply-To: <87mv5megek.fsf@wheatstone.g10code.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> Message-ID: <20170922213300.28d7c209@iria.my-fqdn.de> On Fri, 22 Sep 2017 20:29:07 +0200, Werner Koch wrote: > On Fri, 22 Sep 2017 19:23, stefan.claas at posteo.de said: > > > O.k. i just tested a bit and this is a bug int the Web Interface > > and in GnuPG's CLI Interface. > > I don't see a bug here. Now i am a bit confused... Then maybe a "funny" design flaw? I mean what should users unfamiliar with the whole WoT procedure may think when seeing a fake "sig3" (which they may not spot) and then clicking on the key-id in question, which then links to the original key? > However, given that you use Posteo, you are in the good position to > use the Web Key Directory feature. This requires 2.2.1 because we > had to add some workaround for key upload due to changes at Posteo > which we didn't caught earlier. So people sending mail to you using > a GnuPG 2.2 would find your key instantly. It is not there right now: > > /usr/local/libexec/gpg-wks-client -v --check stefan.claas at posteo > de gpg-wks-client: public key for 'stefan.claas at posteo.de' NOT found > via WKD Well, as i mentioned previously i have have no longer access to my key, due to my stupidness. I may consider to create a new one for posteo usage, but this may take a while. > You may use the latest Enigmail or Kmail to automate the upload but > you can also use Posteo's Web interface to upload the key. But take > care: Posteo does not allow a Name in the user id, only the mail > address (addr-spec) is allowed. Thus you need to add a second user > id with just your mailaddress and use gpg's filter stuff to export > only that UID. GnuPG 2.2.1 automates that tasks and creates another > user if needed. > > If you want to test this feature you may send a mail to clara.chefin > at posteo de, which is a test account of us. (You can also write to > the owner of Posteo to ask him why they still have an invalid > certificate for posteo.net addresses ;-). O.k thanks for the info. When time permits i will check this out. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 21:40:41 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 21:40:41 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922213300.28d7c209@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: On 09/22/2017 09:34 PM, Stefan Claas wrote: >>> O.k. i just tested a bit and this is a bug int the Web Interface >>> and in GnuPG's CLI Interface. >> I don't see a bug here. > Now i am a bit confused... Then maybe a "funny" design flaw? I mean > what should users unfamiliar with the whole WoT procedure may > think when seeing a fake "sig3" (which they may not spot) and then > clicking on the key-id in question, which then links to the original > key? > No, its not a design flaw, it is valid design. OpenPGP keyblock information is based on an object based security model where packets are added, but don't carry any meaning until the signature has been verified. The public keyserver network is by design not a trusted third party, and can not be, so keyblock needs to be imported using a local client at which point invalid data, including invalid signatures, results in discarding of the data, which would filter out the signature in this case. So all is as it is supposed to be -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 21:44:06 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 21:44:06 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: <168902eb-3d59-2f05-5157-57b550df4bf4@sumptuouscapital.com> On 09/22/2017 09:40 PM, Kristian Fiskerstrand wrote: > So all is as it is supposed to be Just to add, the alternative if not considering WoT is a direct validation structure, a user in this case should only (locally) sign keyblock information of communication peers after a direct fingerprint exchange in person, that removes any need for adding ownertrust to keys not your own and simplifies the model. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nunc aut numquam Now or never -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Fri Sep 22 22:08:15 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 22:08:15 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: <20170922220815.488cf2c6@iria.my-fqdn.de> On Fri, 22 Sep 2017 21:40:41 +0200, Kristian Fiskerstrand wrote: > On 09/22/2017 09:34 PM, Stefan Claas wrote: > >>> O.k. i just tested a bit and this is a bug int the Web Interface > >>> and in GnuPG's CLI Interface. > >> I don't see a bug here. > > Now i am a bit confused... Then maybe a "funny" design flaw? I mean > > what should users unfamiliar with the whole WoT procedure may > > think when seeing a fake "sig3" (which they may not spot) and then > > clicking on the key-id in question, which then links to the original > > key? > > > > No, its not a design flaw, it is valid design. OpenPGP keyblock > information is based on an object based security model where packets > are added, but don't carry any meaning until the signature has been > verified. The public keyserver network is by design not a trusted > third party, and can not be, so keyblock needs to be imported using a > local client at which point invalid data, including invalid > signatures, results in discarding of the data, which would filter out > the signature in this case. > > So all is as it is supposed to be Thanks for the information! Can you tell me please how to import a pub key with a local client, so that invalid data get's removed automatically? When doing a gpg --receive-key key-id the fake data is not removed. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Fri Sep 22 22:10:06 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 22:10:06 +0200 Subject: Houston, we have a problem In-Reply-To: <168902eb-3d59-2f05-5157-57b550df4bf4@sumptuouscapital.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <168902eb-3d59-2f05-5157-57b550df4bf4@sumptuouscapital.com> Message-ID: <20170922220957.16c073cd@iria.my-fqdn.de> On Fri, 22 Sep 2017 21:44:06 +0200, Kristian Fiskerstrand wrote: > On 09/22/2017 09:40 PM, Kristian Fiskerstrand wrote: > > So all is as it is supposed to be > > Just to add, the alternative if not considering WoT is a direct > validation structure, a user in this case should only (locally) sign > keyblock information of communication peers after a direct fingerprint > exchange in person, that removes any need for adding ownertrust to > keys not your own and simplifies the model. Good points, thanks! Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From dkg at fifthhorseman.net Fri Sep 22 22:12:50 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 22 Sep 2017 16:12:50 -0400 Subject: automatic conversion from keyring to keybox files? In-Reply-To: <714482652.20170921234714@riseup.net> References: <714482652.20170921234714@riseup.net> Message-ID: <87lgl6ze4d.fsf@fifthhorseman.net> On Thu 2017-09-21 23:47:14 +0100, MFPA wrote: > Now that the upgrade path for GnuPG 2.0.x users is to 2.2.x versions, > will be there any automatic conversion from keyring to keybox files, > either offered by the installer or available as a command? On debian systems, you can run: migrate-pubring-from-classic-gpg And it should handle things sanely. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 22:17:17 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 22:17:17 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922220815.488cf2c6@iria.my-fqdn.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <20170922220815.488cf2c6@iria.my-fqdn.de> Message-ID: On 09/22/2017 10:08 PM, Stefan Claas wrote: > Thanks for the information! Can you tell me please how to import > a pub key with a local client, so that invalid data get's removed > automatically? When doing a gpg --receive-key key-id the fake data > is not removed. What does gpg --check-sigs report? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Fri Sep 22 22:19:36 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 22 Sep 2017 22:19:36 +0200 Subject: gpg 2.1.19 fails to generate key pair In-Reply-To: <20170922184843.GA2196@c720-r314251> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> Message-ID: <20170922201936.GA4052@c720-r314251> it works with: phablet at ubuntu-phablet-bq:~$ ./gpg2.sh --version gpg-agent[28499]: enabled debug flags: mpi crypto memory cache memstat hashing ipc gpg-agent: a gpg-agent is already running - not starting a new one gpg-agent: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg-agent: secmem usage: 0/32768 bytes in 0 blocks gpg (GnuPG) 2.2.1 libgcrypt 1.8.1 ... phablet at ubuntu-phablet-bq:~$ ~/gpg2.sh --full-generate-key ... ???????????????????????????????????????????????????????? ? Please re-enter this passphrase ? ? ? ? Passphrase: ***_____________________________________ ? ? ? ? ? ???????????????????????????????????????????????????????? We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: /home/phablet/.gnupg/trustdb.gpg: trustdb created gpg: key 3FECB79DDDA409E4 marked as ultimately trusted gpg: directory '/home/phablet/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/home/phablet/.gnupg/openpgp-revocs.d/41E0B3688FDD76C9337ECD873FECB79DDDA409E4.rev' public and secret key created and signed. pub rsa2048 2017-09-22 [SC] 41E0B3688FDD76C9337ECD873FECB79DDDA409E4 uid Matthias Apitz (test) sub rsa2048 2017-09-22 [E] -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From stefan.claas at posteo.de Fri Sep 22 22:29:53 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 22:29:53 +0200 Subject: Houston, we have a problem Message-ID: <20170922222847.50c05b65@iria.my-fqdn.de> On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote: > On 09/22/2017 10:08 PM, Stefan Claas wrote: > > Thanks for the information! Can you tell me please how to import > > a pub key with a local client, so that invalid data get's removed > > automatically? When doing a gpg --receive-key key-id the fake data > > is not removed. > > What does gpg --check-sigs report? Ah... it reports (in german) 3 correct sigs and 2 not checked because of errors. And in place of the fake sigs it says erroneous MPI value. :-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 22:32:37 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 22:32:37 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922222847.50c05b65@iria.my-fqdn.de> References: <20170922222847.50c05b65@iria.my-fqdn.de> Message-ID: On 09/22/2017 10:29 PM, Stefan Claas wrote: > On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote: >> On 09/22/2017 10:08 PM, Stefan Claas wrote: >>> Thanks for the information! Can you tell me please how to import >>> a pub key with a local client, so that invalid data get's removed >>> automatically? When doing a gpg --receive-key key-id the fake data >>> is not removed. >> >> What does gpg --check-sigs report? > > Ah... it reports (in german) 3 correct sigs and 2 not checked because of > errors. > > And in place of the fake sigs it says erroneous MPI value. :-) And what happens if you do gpg --import-options import-clean --recv-key ? is the bad MPI value sigs removed or still there in that case? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Veni, vidi, vacatum I came , I saw, I left -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From david at mandelberg.org Fri Sep 22 21:15:42 2017 From: david at mandelberg.org (David Mandelberg) Date: Fri, 22 Sep 2017 15:15:42 -0400 Subject: gpg-agent UI when waiting for smart card touch? Message-ID: <3f58eaa6-2fd3-d3c2-f483-4fbd7deee4da@mandelberg.org> Hi, I'm using gpg-agent with Yubikeys configured to require a physical touch before performing operations. Is there any way to get gpg-agent to display something on screen when it's waiting for me to touch the Yubikey? (Otherwise, I sometimes don't realize it's waiting for anything, and the operation times out.) -- Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/ From stefan.claas at posteo.de Fri Sep 22 22:48:35 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 22:48:35 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170922222847.50c05b65@iria.my-fqdn.de> Message-ID: <20170922224823.22ac7937@iria.my-fqdn.de> On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote: > On 09/22/2017 10:29 PM, Stefan Claas wrote: > > On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote: > >> On 09/22/2017 10:08 PM, Stefan Claas wrote: > >>> Thanks for the information! Can you tell me please how to import > >>> a pub key with a local client, so that invalid data get's removed > >>> automatically? When doing a gpg --receive-key key-id the fake data > >>> is not removed. > >> > >> What does gpg --check-sigs report? > > > > Ah... it reports (in german) 3 correct sigs and 2 not checked > > because of errors. > > > > And in place of the fake sigs it says erroneous MPI value. :-) > > And what happens if you do gpg --import-options import-clean > --recv-key ? is the bad MPI value sigs removed or still there in that > case? Unfortunately still there. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 22 22:52:13 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 22 Sep 2017 22:52:13 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922224823.22ac7937@iria.my-fqdn.de> References: <20170922222847.50c05b65@iria.my-fqdn.de> <20170922224823.22ac7937@iria.my-fqdn.de> Message-ID: <8f36c2bf-3d57-e897-ac24-4309464e2da2@sumptuouscapital.com> On 09/22/2017 10:48 PM, Stefan Claas wrote: > On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote: >>> And in place of the fake sigs it says erroneous MPI value. :-) >> >> And what happens if you do gpg --import-options import-clean >> --recv-key ? is the bad MPI value sigs removed or still there in that >> case? > > Unfortunately still there. Well, it doesn't really do anything, as the signature will be checked when calculating the trust database for the web of trust, but indeed, need to use --check-sigs explicitly in your use case then. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Potius sero quam numquam Better late then never -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Fri Sep 22 22:58:39 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 22:58:39 +0200 Subject: Houston, we have a problem In-Reply-To: <8f36c2bf-3d57-e897-ac24-4309464e2da2@sumptuouscapital.com> References: <20170922222847.50c05b65@iria.my-fqdn.de> <20170922224823.22ac7937@iria.my-fqdn.de> <8f36c2bf-3d57-e897-ac24-4309464e2da2@sumptuouscapital.com> Message-ID: <20170922225822.2627cff0@iria.my-fqdn.de> On Fri, 22 Sep 2017 22:52:13 +0200, Kristian Fiskerstrand wrote: > On 09/22/2017 10:48 PM, Stefan Claas wrote: > > On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote: > > > >>> And in place of the fake sigs it says erroneous MPI value. :-) > >> > >> And what happens if you do gpg --import-options import-clean > >> --recv-key ? is the bad MPI value sigs removed or still there in > >> that case? > > > > Unfortunately still there. > > Well, it doesn't really do anything, as the signature will be checked > when calculating the trust database for the web of trust, but indeed, > need to use --check-sigs explicitly in your use case then. O.k. and thanks a lot for your help! Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From stefan.claas at posteo.de Fri Sep 22 23:45:39 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 22 Sep 2017 23:45:39 +0200 Subject: Houston, we have a problem In-Reply-To: <20170922211655.bko6oqjymwzn5vvs@localhost.localdomain> References: <20170922222847.50c05b65@iria.my-fqdn.de> <20170922211655.bko6oqjymwzn5vvs@localhost.localdomain> Message-ID: <20170922234539.37b1af35@iria.my-fqdn.de> On Fri, 22 Sep 2017 23:16:55 +0200, Guilhem Moulin wrote: > On Fri, 22 Sep 2017 at 22:32:37 +0200, Kristian Fiskerstrand wrote: > > And what happens if you do gpg --import-options import-clean > > --recv-key ? is the bad MPI value sigs removed or still there in > > that case? > > Should be `gpg --keyserver-options import-clean --recv-key $keyid`; or > alternatively, `gpg --edit-key $keyid clean save` if you want to do it > offline. Both commands removes these ?Bad MPI value? sigs here > (2.2.1), and `--check-sigs` reports that all remaining signatures are > indeed valid. That did the trick. Thanks a lot! :-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From guilhem at fripost.org Fri Sep 22 23:16:55 2017 From: guilhem at fripost.org (Guilhem Moulin) Date: Fri, 22 Sep 2017 23:16:55 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170922222847.50c05b65@iria.my-fqdn.de> Message-ID: <20170922211655.bko6oqjymwzn5vvs@localhost.localdomain> On Fri, 22 Sep 2017 at 22:32:37 +0200, Kristian Fiskerstrand wrote: > And what happens if you do gpg --import-options import-clean --recv-key > ? is the bad MPI value sigs removed or still there in that case? Should be `gpg --keyserver-options import-clean --recv-key $keyid`; or alternatively, `gpg --edit-key $keyid clean save` if you want to do it offline. Both commands removes these ?Bad MPI value? sigs here (2.2.1), and `--check-sigs` reports that all remaining signatures are indeed valid. -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From guru at unixarea.de Sat Sep 23 10:47:45 2017 From: guru at unixarea.de (Matthias Apitz) Date: Sat, 23 Sep 2017 10:47:45 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <20170922201936.GA4052@c720-r314251> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> Message-ID: <20170923084745.GA3490@c720-r314251> I have the GnuPG-card working in the Ubuntu smartphone BQ E4.5, details here: https://forums.ubports.com/topic/554/support-for-gnupg-smartcard/3 I could post a small how-to to some place because due to the nature of the phone (read-only mounted root file system) the installation needs some tricks. matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Sat Sep 23 15:15:05 2017 From: wk at gnupg.org (Werner Koch) Date: Sat, 23 Sep 2017 15:15:05 +0200 Subject: gpg 2.1.19 fails to generate key pair In-Reply-To: <20170922184843.GA2196@c720-r314251> (Matthias Apitz's message of "Fri, 22 Sep 2017 20:48:43 +0200") References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> Message-ID: <871smxeeue.fsf@wheatstone.g10code.de> On Fri, 22 Sep 2017 20:48, guru at unixarea.de said: > Ok. I will update to the most recent version. Btw: libcrypt is 1.7.0. Please update to 1.7.9 - Libgcrypt is the most likely cause for a bus error. > Linux ubuntu-phablet 3.4.67 #1 SMP PREEMPT Mon Jun 6 12:04:40 UTC 2016 b75400e armv7l armv7l armv7l GNU/Linux 1.7.2 has this NEWS entry - Fix bus errors on ARM for Poly1305, ChaCha20, AES, and SHA-512. AES is used by gpg-agent to protect your key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Sep 23 16:44:41 2017 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 23 Sep 2017 15:44:41 +0100 Subject: automatic conversion from keyring to keybox files? In-Reply-To: <87lgl6ze4d.fsf@fifthhorseman.net> References: <714482652.20170921234714@riseup.net> <87lgl6ze4d.fsf@fifthhorseman.net> Message-ID: <502539907.20170923154441@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 22 September 2017 at 9:12:50 PM, in , Daniel Kahn Gillmor wrote:- > On debian systems, you can run: > migrate-pubring-from-classic-gpg > And it should handle things sanely. Thank you. Somebody on PGPNET was wondering if there was an automated way instead of following the steps at . Some of the members over there could use this. - -- Best regards MFPA I'd give my right arm to be ambidextrous. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWcZzW18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +paVAP4288ERdPmpo1hNeGkWO+BYnl41Ho4vxpBDEzN6iedZEQD+JMZKWfiTFKJU sU8ThlmcZOLk3S00QumFoa8JDFuOjw2JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCWcZzW18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/2ALD/9wkmEL4JGR/itkjq0tnG67Dq27 Bs03j45UBU/4ptZP+5nqQyh84CaoFg1OkKnuYGIj/vekFRMHbGzT6XdD4aSEVRYz 5XOWUIO0JKpdXqH9Ar8y7++hZTBATt0SimjK4SZpEZ7XXvZ8sSRd6/ufWfBdp7wH dFwE8pl90Sxilg9o51OjlA1SfWFVCg3VpMEOBLRZXUspsW4b68QLQaABaHRKwGgJ jsGKohAGP0EnBBuuMNFf/Q9R2ManPUFpIZ9fN8CbdsB3KrN5Vp+c0mx0ARn4o4hZ CgIWc+9nqIONLAX8Tdb2k07YiblfXGlQ5I6YdraqDYIVE0l9aoYH36cUm1hNZOhw jct9VXAp0pE2flHT+U/tLcP+12A4Gm0eplXKlp+jIKlXJNC6H7Ro12II87Y5eLEJ oYJoSr44xKlJnHZ8GzRWP/STupN1Os7tctfefzBYH7Qwia3VhQZh48SezFo0dOWD IC6LRoukyOlawgaKFdfLxEa7N2oTGgI0b76eA0TC2DfcGLgHdivKdYUgTmQCFS+a kYen06FBc8QG1NEsd5agPEwIgEszjPfgwDkUh45Ie9G2fz8lzw+wWfUtR3IY12F+ mPWea0ekklfdFt89D3PTxCA2yAueFN23NXbk+7ypCQ7cPmDTdfyx3LtUBC5hUiT/ BkiyCj0fCDUXVT4ayg== =CSZJ -----END PGP SIGNATURE----- From stefan.claas at posteo.de Sat Sep 23 22:14:56 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 23 Sep 2017 22:14:56 +0200 Subject: Houston, we have a problem In-Reply-To: <87mv5megek.fsf@wheatstone.g10code.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> Message-ID: <20170923221430.7c30b2b7@iria.my-fqdn.de> On Fri, 22 Sep 2017 20:29:07 +0200, Werner Koch wrote: > You may use the latest Enigmail or Kmail to automate the upload but > you can also use Posteo's Web interface to upload the key. But take > care: Posteo does not allow a Name in the user id, only the mail > address (addr-spec) is allowed. Thus you need to add a second user > id with just your mailaddress and use gpg's filter stuff to export > only that UID. GnuPG 2.2.1 automates that tasks and creates another > user if needed. I just created a new key pair made a second UID with only containing my email address and now i don't know how to filter for an export... Also i have let certified my pub key again by Governikus. Then i checked posteo's FAQ and now i see (under Point 4.) this: Diese Kriterien muss Ihr ?ffentlicher OpenPGP-Schl?ssel erf?llen, um ihn bei Posteo hinterlegen zu k?nnen. 1. Das Namensfeld muss leer sein oder lediglich Ihre E-Mail-Adresse enthalten. 2. Der ?ffentliche Schl?ssel darf nur eine E-Mail-Adresse enthalten. Unterschl?ssel (Subkeys) oder mehrere E-Mail-Adressen sind nicht zul?ssig. 3. Ihr Schl?ssel muss Ihre Posteo-E-Mail-Adresse oder eine Ihrer Alias-Adressen enthalten. 4. Der Schl?ssel darf nicht von anderen unterschrieben oder signiert sein. 5. Der Schl?ssel darf kein Foto oder andere pers?nliche Daten enthalten. If i need email privacy with GnuPG i would use Mixmaster Remailers with a nym account or Bitmessage and not a german based email provider, where i have to pay for their service... :-) So it seem that while it's a good idea with WKD, posteo is no option for me, when it comes to submitting my pub key there. Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From wk at gnupg.org Sun Sep 24 08:56:56 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Sep 2017 08:56:56 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <20170923084745.GA3490@c720-r314251> (Matthias Apitz's message of "Sat, 23 Sep 2017 10:47:45 +0200") References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> Message-ID: <87k20od1on.fsf@wheatstone.g10code.de> On Sat, 23 Sep 2017 10:47, guru at unixarea.de said: > I have the GnuPG-card working in the Ubuntu smartphone BQ E4.5, details > here: https://forums.ubports.com/topic/554/support-for-gnupg-smartcard/3 Cool. > I could post a small how-to to some place because due to the nature of Would you like to write a blog entry for gnupg.org? Needs to be done in org-mode formaty but I can offer to copyedit it for you. One or two picture would also be nice. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Sun Sep 24 10:59:35 2017 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 24 Sep 2017 10:59:35 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <87k20od1on.fsf@wheatstone.g10code.de> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> <87k20od1on.fsf@wheatstone.g10code.de> Message-ID: <20170924085935.GA2714@c720-r314251> El d?a domingo, septiembre 24, 2017 a las 08:56:56a. m. +0200, Werner Koch escribi?: > On Sat, 23 Sep 2017 10:47, guru at unixarea.de said: > > I have the GnuPG-card working in the Ubuntu smartphone BQ E4.5, details > > here: https://forums.ubports.com/topic/554/support-for-gnupg-smartcard/3 > > Cool. > > > I could post a small how-to to some place because due to the nature of > > Would you like to write a blog entry for gnupg.org? Needs to be done in > org-mode formaty but I can offer to copyedit it for you. One or two > picture would also be nice. I would be happy to write something in this blog, but I never wrote something in 'org-mode' format, any pointer to some guide? I'm attaching below a text version of the write-up. A photo is here: http://www.unixarea.de/UbuntuPhone-GnuPG-card.jpg If it should be og better quality, I have to look for some equipment. For the connection between the USB token and the phone, I used some OTG (USB On-The-Go) cable. I own as well a small connector receiving on one end the token and to be plugged in into the phones port, but this connection is very unstable, with the cable it's fine. matthias Using GnuPG-card in the UbuntuPhone BQ E4.5: phablet at ubuntu-phablet-bq:~$ phablet at ubuntu-phablet-bq:~$ sudo chroot myRoot/ ... root at ubuntu-phablet:/# apt-get install pinentry-curses root at ubuntu-phablet:/# apt-get install pass root at ubuntu-phablet:/# apt-get install libudev-dev Installing GnuPG 2.2.1 into the 'myRoot' system compile in ~phablet (in myRoot) the following pieces: libassuan-2.4.3 libgpg-error-1.27 libksba-1.3.5 npth-1.5 libgcrypt-1.8.1 gnupg-2.2.1 always with ./configure && make && sudo make install; the software ends up below /usr/local (i.e. /home/phablet/myRoot/usr/local when one looks from outside the chroot'ed phone system); note: 'gpg2' is /usr/local/bin/gpg Now from the phone system configure: $ mkdir ~/.gnupg $ cat .gnupg/gpg.conf # agent-program /home/phablet/myRoot/usr/local/bin/gpg-agent $ cat .gnupg/gpg-agent.conf pinentry-program /home/phablet/myRoot/usr/bin/pinentry-curses scdaemon-program /home/phablet/myRoot/usr/local/libexec/scdaemon log-file /home/phablet/gpg-agent.log log-file /dev/null debug-level guru Due to the nature of the installation in the chrooted system we need small wrapper scripts to set PATH, LD_LIBRARY_PATH, ... and other stuff; $ cat ~/gpg.sh #!/bin/sh LD_LIBRARY_PATH=/home/phablet/myRoot/usr/local/lib export LD_LIBRARY_PATH PATH=/home/phablet/myRoot/usr/local/bin:$PATH export PATH GNUPGHOME=/home/phablet/.gnupg export GNUPGHOME GPG_TTY=$(tty) export GPG_TTY /home/phablet/myRoot/usr/local/bin/gpg-agent \ --homedir /home/phablet/.gnupg \ --daemon \ --pinentry-program /home/phablet/myRoot/usr/bin/pinentry-curses /home/phablet/myRoot/usr/local/bin/gpg-connect-agent /bye /home/phablet/myRoot/usr/local/bin/gpg $* run and create for test a keypair (later we want to use the GnuPG-card for this) $ ~/gpg.sh --full-generate-key gpg-agent[2973]: enabled debug flags: mpi crypto memory cache memstat hashing ipc gpg (GnuPG) 2.2.1; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? ... This starts the gpg-agent as: $ ps ax | grep gpg-a 2974 ? Ss 0:00 /home/phablet/myRoot/usr/local/bin/gpg-agent --homedir /home/phablet/.gnupg --daemon --pinentry-program /home/phablet/myRoot/usr/bin/pinentry-curses Now we can use the the 'pass' command we installed in the chroot'es system with $ cat pass.sh #!/bin/sh LD_LIBRARY_PATH=/home/phablet/myRoot/usr/local/lib export LD_LIBRARY_PATH PATH=/home/phablet/myRoot/usr/local/bin:$PATH export PATH GNUPGHOME=/home/phablet/.gnupg export GNUPGHOME GPG_TTY=$(tty) export GPG_TTY unset GPG_AGENT_INFO /home/phablet/myRoot/usr/bin/pass $* Init the pass storage as: $ ./pass.sh init Matthias ?????????????????????????????????????????????????????????????????? ? Please enter the passphrase to unlock the OpenPGP secret key: ? ? "Matthias Apitz (test) " ? ? 2048-bit RSA key, ID 93A6FBF52FA76DB0, ? ? created 2017-09-22 (main key ID 3FECB79DDDA409E4). ? ? ? ? ? ? Passphrase: ***_______________________________________________ ? ? ? ? ? ?????????????????????????????????????????????????????????????????? $ find .password-store/ .password-store/ .password-store/.gpg-id Insert some password for test: $ ./pass.sh insert -m web/bla Enter contents of web/bla and press Ctrl+D when finished: password Username: guru $ ./pass.sh web/bla password Username: guru Final step is getting support for the GnuPG-card. We need the 'pcscd' daemon. Its build is a bit tricky because it must later, on start from outside the chrooted system, find the ccid driver. We compile the following pieces inside the chroot'ed system: pcsc-lite-1.8.20 ccid-1.4.25 with the following options set on ./configure ... phablet at ubuntu-phablet-bq:~$ cd pcsc-lite-1.8.20 phablet at ubuntu-phablet-bq:~/ccid-1.4.25$ ./configure --enable-usbdropdir=/home/phablet/myRoot/usr/local/lib/pcsc/drivers --enable-confdir=/home/phablet/myRoot/etc/reader.conf.d ... PC/SC lite has been configured with following options: Version: 1.8.20 System binaries: /usr/local/sbin Configuration dir: /usr/local/etc/reader.conf.d Host: armv7l-unknown-linux-gnueabihf Compiler: gcc Preprocessor flags: -I${top_srcdir}/src Compiler flags: -Wall -fno-common -g -O2 Preprocessor flags: -I${top_srcdir}/src Linker flags: Libraries: -ldl -lrt PTHREAD_CFLAGS: -pthread PTHREAD_LIBS: PCSC_ARCH: Linux pcscd binary /usr/local/sbin/pcscd polkit support: no polkit policy dir: libudev support: yes libusb support: no USB drop directory: /home/phablet/myRoot/usr/local/lib/pcsc/drivers ATR parsing messages: false ipcdir: /var/run/pcscd use serial: yes use usb: yes systemd unit directory: /lib/systemd/system serial config dir.: /home/phablet/myRoot/etc/reader.conf.d filter: no PCSCLITE_FEATURES: Linux armv7l-unknown-linux-gnueabihf serial usb libudev usbdropdir=/home/phablet/myRoot/usr/local/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/home/phablet/myRoot/etc/reader.conf.d checking that generated files are newer than configure... done ... phablet at ubuntu-phablet-bq:~/ccid-1.4.25$ make phablet at ubuntu-phablet-bq:~/ccid-1.4.25$ sudo make install ok, now the 'ccid' driver, installed (copied) to be seen by the daemon: ccid-1.4.25.tar.bz2: phablet at ubuntu-phablet-bq:~$ sudo apt-get install libusb-dev phablet at ubuntu-phablet-bq:~$ sudo apt-get install libusb-1.0-0-dev phablet at ubuntu-phablet-bq:~$ cd ccid-1.4.25 phablet at ubuntu-phablet:~/ccid-1.4.25$ ./configure -enable-usbdropdir=/home/phablet/myRoot/usr/local/lib/pcsc/drivers ... libccid has been configured with following options: Version: 1.4.25 User binaries: /usr/local/bin Configuration files: /usr/local/etc Host: armv7l-unknown-linux-gnueabihf Compiler: gcc Preprocessor flags: Compiler flags: -g -O2 Preprocessor flags: Linker flags: Libraries: PCSC_CFLAGS: -pthread -I/usr/local/include/PCSC PCSC_LIBS: -L/usr/local/lib -lpcsclite PTHREAD_CFLAGS: -pthread PTHREAD_LIBS: BUNDLE_HOST: Linux DYN_LIB_EXT: so LIBUSB_CFLAGS: -I/usr/include/libusb-1.0 LIBUSB_LIBS: -lusb-1.0 SYMBOL_VISIBILITY: -fvisibility=hidden NOCLASS: libusb support: yes composite as multislot: no multi threading: yes bundle directory name: ifd-ccid.bundle USB drop directory: /home/phablet/myRoot/usr/local/lib/pcsc/drivers serial Twin support: no serial twin install dir: /home/phablet/myRoot/usr/local/lib/pcsc/drivers/serial serial config directory: /home/phablet/myRoot/etc/reader.conf.d compiled for pcsc-lite: yes syslog debug: no class driver: yes ... phablet at ubuntu-phablet:~/ccid-1.4.25$ make phablet at ubuntu-phablet:~/ccid-1.4.25$ sudo make install the driver libccid.so and its control file Info.plist ended up as configured: phablet at ubuntu-phablet:~$ find /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/ /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/ /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist but if we run the daemon from outside the chrooted system, must be in some other place because '/home/phablet/myRoot' is added in front; so we copy them over to the correct place: phablet at ubuntu-phablet:~$ sudo mkdir -p /usr/local/lib/pcsc/drivers/ifd-ccid.bundle phablet at ubuntu-phablet:~$ sudo cp -rp /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents /usr/local/lib/pcsc/drivers/ifd-ccid.bundle phablet at ubuntu-phablet:~$ find /usr/local/lib/pcsc/drivers/ifd-ccid.bundle /usr/local/lib/pcsc/drivers/ifd-ccid.bundle /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist from outside the chrooted system we can now start the daemon as: $ sudo /home/phablet/myRoot/usr/local/sbin/pcscd --foreground --debug | tee pcscd.log and check the log file pcscd.log to see if it sees the card attaching (see at the very end of the write-up); Now we start in the phone the pcscd daemon as: $ sudo /home/phablet/myRoot/usr/local/sbin/pcscd $ ps ax | grep pcscd 31669 pts/53 Sl 0:00 /home/phablet/myRoot/usr/local/sbin/pcscd and run the gpg --card-status to see if it finds the card after attaching it: $ ./gpg.sh --card-status gpg-agent[20254]: enabled debug flags: mpi crypto memory cache memstat hashing ipc gpg-agent: a gpg-agent is already running - not starting a new one gpg-agent: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg-agent: secmem usage: 0/32768 bytes in 0 blocks Reader ...........: Identiv uTrust 3512 SAM slot Token [CCID Interface] (55511514602745) 00 00 Application ID ...: D27600012401020100050000532B0000 Version ..........: 2.1 Manufacturer .....: ZeitControl Serial number ....: 0000532B Name of cardholder: Matthias Apitz Language prefs ...: en Sex ..............: unspecified URL of public key : http://www.unixarea.de/ccid--export-key-guru.pub Login data .......: [not set] Signature PIN ....: not forced Key attributes ...: rsa4096 rsa4096 rsa4096 Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 457 Signature key ....: 5E69 FBAC 1618 562C B3CB FBC1 47CC F7E4 76FE 9D11 created ....: 2017-05-14 18:20:07 Encryption key....: EB62 00DA 13A1 9E80 679B 1A13 61F1 ECB6 25C9 A6C3 created ....: 2017-05-14 18:20:07 Authentication key: E51D D2D6 C727 35D6 651D EA4B 6AA5 C5C4 51A1 CD1C created ....: 2017-05-14 18:20:07 General key info..: [none] Now we removed ~/.gnupg (saving the *.conf files) and copied over from my real netbook the ~/.password-store and the key material for the GnuPG-card; let's see if 'pass' can unlock the card (via the gpg-agent) and decipher the encrypted information (unencrypted shown here as 'XXXXXXXX-XXXXXX'): $ ./pass.sh askubuntu.com/guru at unixarea.de ??????????????????????????????????????????????? ? Please insert the card with serial number: ? ? ? ? 0005 0000532B ? ? ? ? ? ??????????????????????????????????????????????? ???????????????????????????????????????????????? ? Please unlock the card ? ? ? ? Number: 0005 0000532B ? ? Holder: Matthias Apitz ? ? ? ? PIN ________________________________________ ? ? ? ? ? ???????????????????????????????????????????????? XXXXXXXX-XXXXXX $ on the 2nd run it does not need anymore the PIN: $ ./pass.sh askubuntu.com/guru at unixarea.de XXXXXXXX-XXXXXX i.e. all is fine! This is only the debug log of the pcscd daemon for reference. 00000000 debuglog.c:289:DebugLogSetLevel() debug level=debug 00001760 configfile.l:282:DBGetReaderListDir() Parsing conf directory: /home/phablet/myRoot/etc/reader.conf.d 00000840 configfile.l:319:DBGetReaderListDir() Skipping non regular file: . 00000349 configfile.l:319:DBGetReaderListDir() Skipping non regular file: .. 00000364 configfile.l:358:DBGetReaderList() Parsing conf file: /home/phablet/myRoot/etc/reader.conf.d/libccidtwin 00000568 pcscdaemon.c:655:main() pcsc-lite 1.8.20 daemon ready. 00007279 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 07475463 hotplug_libudev.c:648:HPEstablishUSBNotifications() USB Device add 00005501 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x04E6, PID: 0x5816, path: /dev/bus/usb/001/009 00000555 hotplug_libudev.c:433:HPAddDevice() Adding USB device: Identiv uTrust 3512 SAM slot Token 00000673 readerfactory.c:1079:RFInitializeReader() Attempting startup of Identiv uTrust 3512 SAM slot Token [CCID Interface] (55511514602745) 00 00 using /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so 00001129 readerfactory.c:954:RFBindFunctions() Loading IFD Handler 3.0 00013183 ifdhandler.c:1953:init_driver() Driver version: 1.4.25 00004027 ifdhandler.c:1970:init_driver() LogLevel: 0x0003 00004427 ifdhandler.c:1981:init_driver() DriverOptions: 0x0000 00001127 ifdhandler.c:110:CreateChannelByNameOrChannel() Lun: 0, device: usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 00001212 ccid_usb.c:287:OpenUSBByName() Using: /home/phablet/myRoot/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist 00005565 ccid_usb.c:305:OpenUSBByName() ifdManufacturerString: Ludovic Rousseau (ludovic.rousseau at free.fr) 00001479 ccid_usb.c:306:OpenUSBByName() ifdProductString: Generic CCID driver 00000362 ccid_usb.c:307:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version. 00003937 ccid_usb.c:621:OpenUSBByName() Found Vendor/Product: 04E6/5816 (Identiv uTrust 3512 SAM slot Token) 00000667 ccid_usb.c:623:OpenUSBByName() Using USB bus/device: 1/9 00000337 ccid_usb.c:680:OpenUSBByName() bNumDataRatesSupported is 0 00010195 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB3, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00000626 readerfactory.c:395:RFAddReader() Using the reader polling thread 00000838 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFAE, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00000470 ifdhandler.c:470:IFDHGetCapabilities() Reader supports 1 slot(s) 00001264 ifdhandler.c:1146:IFDHPowerICC() action: PowerUp, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00032378 eventhandler.c:286:EHStatusHandlerThread() powerState: POWER_STATE_POWERED 00000596 Card ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 05001478 ifdhandler.c:1146:IFDHPowerICC() action: PowerDown, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00003148 eventhandler.c:479:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED 14774363 hotplug_libudev.c:642:HPEstablishUSBNotifications() USB Device removed 00000796 hotplug_libudev.c:360:HPRemoveDevice() Removing USB device[0]: Identiv uTrust 3512 SAM slot Token [CCID Interface] (55511514602745) at /dev/bus/usb/001/009 00000053 readerfactory.c:608:RFRemoveReader() UnrefReader() count was: 1 00000024 eventhandler.c:176:EHDestroyEventHandler() Stomping thread. 00000026 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB1, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00000024 ifdhandler.c:379:IFDHGetCapabilities() tag: 0xFB2, usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00000018 eventhandler.c:201:EHDestroyEventHandler() Request stopping of polling thread 00000020 ifdhandler.c:344:IFDHStopPolling() usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00397726 eventhandler.c:502:EHStatusHandlerThread() Die 00001909 eventhandler.c:216:EHDestroyEventHandler() Thread stomped. 00000049 readerfactory.c:1130:RFUnInitializeReader() Attempting shutdown of Identiv uTrust 3512 SAM slot Token [CCID Interface] (55511514602745) 00 00. 00000039 ifdhandler.c:282:IFDHCloseChannel() usb:04e6/5816:libudev:0:/dev/bus/usb/001/009 (lun: 0) 00000101 ccid_usb.c:797:WriteUSB() write failed (1/9): -4 LIBUSB_ERROR_NO_DEVICE 00000147 ccid_usb.c:189:close_libusb_if_needed() libusb_exit 00001864 readerfactory.c:991:RFUnloadReader() Unloading reader driver. -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Sun Sep 24 17:31:56 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Sep 2017 17:31:56 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <20170924085935.GA2714@c720-r314251> (Matthias Apitz's message of "Sun, 24 Sep 2017 10:59:35 +0200") References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> <87k20od1on.fsf@wheatstone.g10code.de> <20170924085935.GA2714@c720-r314251> Message-ID: <878th4az9v.fsf@wheatstone.g10code.de> On Sun, 24 Sep 2017 10:59, guru at unixarea.de said: > I would be happy to write something in this blog, but I never wrote > something in 'org-mode' format, any pointer to some guide? I'm attaching If you are on Emacs it is already included and part of Emacs help system. It's website is org-mode.org. The markup is easy: --8<---------------cut here---------------start------------->8--- # Without a .org suffix this is useful: -*- org -*- #+TITLE: Sample Document * This is a level 1 header ** This is a level 2 header Here is some text with /italics/ or *bold* or _underscored_. - First list item - Second list item - Sublist item 1 - sublist iten 2 #+begin_src source code #+end_src This is [[https://example.org][an external link]] and there are a lot of other things one does not need to know to get started. # IMHO a major annoyance in Markdown the missing of source comments like # this one in org-mode --8<---------------cut here---------------end--------------->8--- If you go to a blog article on gnupg.org (or actually any page) you find a link to the source right down at the bottom of the page. > below a text version of the write-up. A photo is here: Shall I do a basic markup and send it to you? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From azarus at posteo.net Sun Sep 24 17:34:46 2017 From: azarus at posteo.net (azarus) Date: Sun, 24 Sep 2017 17:34:46 +0200 Subject: Signing failed -- "No secret key", even though I have the key Message-ID: <20170924153446.GA10229@dura> Hello GPG users, I have a problem regarding signing data. Whenever I try clear-signing, this appears: gpg: writing to stdout -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hello gpg: signing failed: No secret key gpg: [stdin]: clear-sign failed: No secret key I invoked clearsign like this: echo "hello" | gpg --sign-with --clearsign This is what gpg -K lists: /home/azarus/.gnupg/pubring.kbx ------------------------------- sec rsa4096 2016-12-20 [SC] uid [ultimate] uid [ultimate] ssb rsa4096 2016-12-20 [E] ssb# rsa4096 2017-06-23 [SE] Can somebody explain what I'm doing wrong? This was working a couple of days ago, I even reset my .gnupg directory from a backup, with no success. Thanks for the help! All the best, azarus From azarus at posteo.net Sun Sep 24 17:47:26 2017 From: azarus at posteo.net (azarus) Date: Sun, 24 Sep 2017 17:47:26 +0200 Subject: Signing failed -- "No secret key" even though I have it Message-ID: <20170924154726.GA27012@dura> Hello GPG users, I have a problem regarding signing data. Whenever I try clear-signing, this appears: gpg: writing to stdout -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hello gpg: signing failed: No secret key gpg: [stdin]: clear-sign failed: No secret key I invoked clearsign like this: echo "hello" | gpg --sign-with --clearsign This is what gpg -K lists: /home/azarus/.gnupg/pubring.kbx ------------------------------- sec rsa4096 2016-12-20 [SC] uid [ultimate] uid [ultimate] ssb rsa4096 2016-12-20 [E] ssb# rsa4096 2017-06-23 [SE] Can somebody explain what I'm doing wrong? This was working a couple of days ago, I even reset my .gnupg directory from a backup, with no success. Thanks for the help! All the best, azarus From azarus at posteo.net Sun Sep 24 17:34:46 2017 From: azarus at posteo.net (azarus) Date: Sun, 24 Sep 2017 17:34:46 +0200 Subject: Signing failed -- "No secret key", even though I have the key Message-ID: <20170924153446.GA10229@dura> Hello GPG users, I have a problem regarding signing data. Whenever I try clear-signing, this appears: gpg: writing to stdout -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hello gpg: signing failed: No secret key gpg: [stdin]: clear-sign failed: No secret key I invoked clearsign like this: echo "hello" | gpg --sign-with --clearsign This is what gpg -K lists: /home/azarus/.gnupg/pubring.kbx ------------------------------- sec rsa4096 2016-12-20 [SC] uid [ultimate] uid [ultimate] ssb rsa4096 2016-12-20 [E] ssb# rsa4096 2017-06-23 [SE] Can somebody explain what I'm doing wrong? This was working a couple of days ago, I even reset my .gnupg directory from a backup, with no success. Thanks for the help! All the best, azarus From kristian.fiskerstrand at sumptuouscapital.com Sun Sep 24 18:53:45 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 24 Sep 2017 18:53:45 +0200 Subject: Signing failed -- "No secret key", even though I have the key In-Reply-To: <20170924153446.GA10229@dura> References: <20170924153446.GA10229@dura> Message-ID: On 09/24/2017 05:34 PM, azarus wrote: > ssb# rsa4096 2017-06-23 [SE] > > Can somebody explain what I'm doing wrong? A combined sign and encrypt capable subkey would be wrong #1, you likely want to revoke this one and generate separate subkeys for the various options. Aditionally, they are stubs, as indicated by the "#"-sign, so not available on the computer you're executing the signature operation on. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nomina stultorum scribuntur ubique locorum Fools have the habit of writing their names everywhere -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Sun Sep 24 19:55:28 2017 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 24 Sep 2017 19:55:28 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <878th4az9v.fsf@wheatstone.g10code.de> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> <87k20od1on.fsf@wheatstone.g10code.de> <20170924085935.GA2714@c720-r314251> <878th4az9v.fsf@wheatstone.g10code.de> Message-ID: <20170924175528.GA5046@c720-r314251> El d?a domingo, septiembre 24, 2017 a las 05:31:56p. m. +0200, Werner Koch escribi?: > On Sun, 24 Sep 2017 10:59, guru at unixarea.de said: > > > I would be happy to write something in this blog, but I never wrote > > something in 'org-mode' format, any pointer to some guide? I'm attaching > > If you are on Emacs it is already included and part of Emacs help > system. It's website is org-mode.org. The markup is easy: I'm not on Emacs, but vim. But, with the example you gave and looking on some sources in the blog at gnupg.org I think I can do it. Groff was more challenging in the past :-) I will look for some slot next week. I will have to send it to you as I don't see a way to create an account in the blog... matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From juanmi.3000 at gmail.com Sun Sep 24 19:44:32 2017 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Sun, 24 Sep 2017 19:44:32 +0200 Subject: Signing failed -- "No secret key", even though I have the key In-Reply-To: <20170924153446.GA10229@dura> References: <20170924153446.GA10229@dura> Message-ID: On 2017-09-24 at 17:34, azarus wrote: > This is what gpg -K lists: > > /home/azarus/.gnupg/pubring.kbx > ------------------------------- > sec rsa4096 2016-12-20 [SC] > > uid [ultimate] > uid [ultimate] > ssb rsa4096 2016-12-20 [E] > ssb# rsa4096 2017-06-23 [SE] > You're missing the secret part of your subkey: > ssb# rsa4096 2017-06-23 [SE]) ... and, for at least GnuPG >= 2.1.0, GPGAgent most likely wants to use that subkey because it has been detected in the pubring.gpg or pubring.kbx keyring, but due to the missing secret part GPGAgent doesn't fallback to the master key with signing capabilities which you have its secret parts. -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Sun Sep 24 22:14:37 2017 From: ben at adversary.org (Ben McGinnes) Date: Mon, 25 Sep 2017 06:14:37 +1000 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <20170924175528.GA5046@c720-r314251> References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> <87k20od1on.fsf@wheatstone.g10code.de> <20170924085935.GA2714@c720-r314251> <878th4az9v.fsf@wheatstone.g10code.de> <20170924175528.GA5046@c720-r314251> Message-ID: <20170924201437.64x7ko72jmjuxz6q@adversary.org> On Sun, Sep 24, 2017 at 05:55:28PM +0000, Matthias Apitz wrote: > > I'm not on Emacs, but vim. But, with the example you gave and > looking on some sources in the blog at gnupg.org I think I can do > it. Groff was more challenging in the past :-) You can always use the quick and dirty solution: write it in Markdown and then use pandoc to convert from that to Org-Mode. It might need a little tweaking or adjustment afterwards, but probably not much. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From wk at gnupg.org Mon Sep 25 11:24:36 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Sep 2017 11:24:36 +0200 Subject: GnuPG-card works in the Ubuntu smartphone In-Reply-To: <20170924175528.GA5046@c720-r314251> (Matthias Apitz's message of "Sun, 24 Sep 2017 19:55:28 +0200") References: <20170922152401.GA3739@c720-r314251> <87r2uyegv1.fsf@wheatstone.g10code.de> <20170922184843.GA2196@c720-r314251> <20170922201936.GA4052@c720-r314251> <20170923084745.GA3490@c720-r314251> <87k20od1on.fsf@wheatstone.g10code.de> <20170924085935.GA2714@c720-r314251> <878th4az9v.fsf@wheatstone.g10code.de> <20170924175528.GA5046@c720-r314251> Message-ID: <87efqv9lm3.fsf@wheatstone.g10code.de> On Sun, 24 Sep 2017 19:55, guru at unixarea.de said: > I will look for some slot next week. I will have to send it to you as I > don't see a way to create an account in the blog... Ack. The accounts on that box are only for regular gnupg commiters. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From emestee at catnarok.net Mon Sep 25 11:48:47 2017 From: emestee at catnarok.net (Michael Stolovitzsky) Date: Mon, 25 Sep 2017 09:48:47 +0000 Subject: Signing failed -- "No secret key" even though I have it In-Reply-To: <20170924154726.GA27012@dura> References: <20170924154726.GA27012@dura> Message-ID: <20170925094847.y6byy5s5gkjw2o7k@arise.catnarok.net> On 17-09-24, azarus wrote: > Hello GPG users, > > I have a problem regarding signing data. Whenever I try clear-signing, > this appears: > [snip] > This is what gpg -K lists: > > /home/azarus/.gnupg/pubring.kbx > ------------------------------- > sec rsa4096 2016-12-20 [SC] > > uid [ultimate] > uid [ultimate] > ssb rsa4096 2016-12-20 [E] > ssb# rsa4096 2017-06-23 [SE] > > Can somebody explain what I'm doing wrong? This was working a couple of Your signing key has been replaced by a stub, which is what # after the key indicates, so gpg is unable to reach it, it's just aware of its existence. From andrewg at andrewg.com Tue Sep 26 13:07:48 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Sep 2017 12:07:48 +0100 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: On 22/09/17 20:40, Kristian Fiskerstrand wrote: > On 09/22/2017 09:34 PM, Stefan Claas wrote: >>>> O.k. i just tested a bit and this is a bug int the Web Interface >>>> and in GnuPG's CLI Interface. >>> I don't see a bug here. >> Now i am a bit confused... Then maybe a "funny" design flaw? I mean >> what should users unfamiliar with the whole WoT procedure may >> think when seeing a fake "sig3" (which they may not spot) and then >> clicking on the key-id in question, which then links to the original >> key? >> > > No, its not a design flaw, it is valid design. OpenPGP keyblock > information is based on an object based security model where packets are > added, but don't carry any meaning until the signature has been > verified. The public keyserver network is by design not a trusted third > party, and can not be Absolutely. But it can *appear* to be trustworthy, and this is a problem in itself. The issue is UX and user expectation. If I go to a server and ask for some specific data, and the server gives me that data, then there is an implied authority to that data. We can argue here until the heat death that users *should not* read any sort of endorsement into a server merely providing data. But that's not the way human beings think. And trying to train human beings to constantly fight against their instincts is like trying to train cats not to catch birds. If we don't want people to read anything into unverified data, then we should not display unverified data in a form where people may mistake it for verified data. So in this case, the problem arises not because the server has provided a signature on a key, but because it has naively repeated the (unverified) claim that a particular signature was made by a key that has a particular ID bound to it, in human readable form and without a giant red flashing neon sign saying *THIS IS ALL LIES*. As you say, we know nothing meaningful until the full signature chain (including any SBINDs) has been validated. The problem comes when software is "being helpful" and blindly regurgitates unverified (therefore meaningless, therefore *misleading*) data. Average users cannot be expected to remember when data has been verified and when it has not. The only way to stop people making the same mistakes over and over again is to stop facilitating those mistakes. We can draw a parallel with fake news. No matter how many times you tell people "Do not trust anything you read on the internet", the default state of the human brain is to believe what it is told unless suspicion is aroused. It can only be thus. If you doubted every single thing you were presented with every day, you would never get out of bed. So when SKS lists the signatures on a key, people believe it. When Enigmail says "untrusted good signature", people read the "good" and gloss over the "untrusted". The only way to stop people believing things that may not be true is to stop telling them things that may not be true. So SKS should just say "unverified signature from ". It should not repeat the purported user ID, nor provide a search link that returns completely unrelated keys that happen to have the same purported ID. But user-facing software shouldn't be exposing unverified IDs *at all*. Enigmail now sort-of does this - the latest versions won't even admit to the existence of a signature by a key that's not in the keyring. It could do even better - it should stop saying "untrusted good signature" and just say "unknown signature". If people want the gory details, they can click the details button. The gpg command itself should cryptographically verify signatures when performing --list-sigs, so that at least it can throw a warning when an invalid signature packet is found. Ideally it should not display invalid packets at all (by default). Displaying a genuine-looking signature on a key that doesn't result in a valid chain of trust is a sure way to encourage people to work around the safeties. It is not enough that something bad is forbidden. You have to make it obvious at all times *why* it's forbidden, otherwise people think the system is broken and fight against it. The fact that technically-proficient people have been coming in here for twenty years with the same misconceptions about what is and isn't verified and/or trustworthy is a sign that there's something fundamentally broken with the ecosystem's UX. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 26 13:30:28 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 26 Sep 2017 13:30:28 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: On 09/26/2017 01:07 PM, Andrew Gallagher wrote: > So SKS should just say "unverified signature from ". It > should not repeat the purported user ID, nor provide a search link that > returns completely unrelated keys that happen to have the same purported ID. No, that is also wrong, as it implies that anything is trusted unless otherwise stated. A malicious actor can claim it is verified all he/she wants (simply removing the disclaimer). The user's default position NEEDS to be that nothing is verified until it is done locally or by an explicitly trusted third party. Any kind of disclaimer is actually doing the user a dis-service and supporting a subset of the user base that lacks sufficient experience/knowledge to do anything securely to begin with, which is the root cause of the issue; the solution isn't a disclaimer it is more education. Fwiw I don't recommend anyone to directly link to vindex etc on keyservers, you'll notice that https://sks-keyservers.net only links to get operations for similar purposes (if you find a (v)index link it is a bug and you should report it separately), but being able to browse the keyserver directly is too useful for debugging to completely remove. It is a reason it is done on port 11371 for hkp and I would encourage only accessing it through a local client, but other than that it isn't much to do on the keyserver side. But the lesson here is that in order to avoid misuse by an unexperience userbase the protocol has to be a binary obfuscated mess instead of trying to re-use well-established protocols in text form, just in case the user walks into the maze for some reason. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you don't drive your business, you will be driven out of business" (B. C. Forbes) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Sep 26 14:15:58 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Sep 2017 13:15:58 +0100 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> On 26/09/17 12:30, Kristian Fiskerstrand wrote: > On 09/26/2017 01:07 PM, Andrew Gallagher wrote: >> So SKS should just say "unverified signature from ". It >> should not repeat the purported user ID, nor provide a search link that >> returns completely unrelated keys that happen to have the same purported ID. > > No, that is also wrong, as it implies that anything is trusted unless > otherwise stated. A malicious actor can claim it is verified all he/she > wants (simply removing the disclaimer). Um, did you reply to the wrong paragraph? I did mention disclaimers elsewhere, but only in passing (and tongue in cheek). My argument is that we shouldn't be displaying unverified information at all. > The user's default position > NEEDS to be that nothing is verified until it is done locally or by an > explicitly trusted third party. Absolutely. None of this is an argument against users having to do things right. But the way to get users to do things right is to train them to do things right from the start - and you do that by railroading them down the straight and narrow and not even have the option to do it any other way. That way, if the opportunity to do it wrong arises in the future their first instinct will be "this isn't how it's supposed to happen". If you can't train people personally, you have to write your software so that the software trains them. WhatsApp gets the UX *very nearly* right. And since everyone and his dog now uses it that's the new baseline. If it's easier to do it wrong than in WhatsApp, it's broken. If it's harder to understand than WhatsApp, it's broken. If you have to read more instructions than WhatsApp, it's broken. It's no good implementing something correctly if it can be applied incorrectly. Murphy's Law applies. > being able to browse the > keyserver directly is too useful for debugging to completely remove Indeed, but is it necessary to display the untrustworthy user-ID on signatures? The fingerprint should be sufficient. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 26 14:49:46 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 26 Sep 2017 14:49:46 +0200 Subject: Houston, we have a problem In-Reply-To: <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> Message-ID: <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> On 09/26/2017 02:15 PM, Andrew Gallagher wrote: > Absolutely. None of this is an argument against users having to do > things right. But the way to get users to do things right is to train > them to do things right from the start - and you do that by railroading > them down the straight and narrow and not even have the option to do it > any other way. That way, if the opportunity to do it wrong arises in the > future their first instinct will be "this isn't how it's supposed to > happen". If you can't train people personally, you have to write your > software so that the software trains them. The users shoudn't browse keyservers at all, so it shouldn't really be an issue. Linking to get operation to get the public keyblock is just a convenience. > > WhatsApp gets the UX *very nearly* right. And since everyone and his dog > now uses it that's the new baseline. If it's easier to do it wrong than No, that actually is broken by design as it doesn't open up for proper operational security controls, in particular lack of private key separation on smartcard and airgapped computer. > >> being able to browse the >> keyserver directly is too useful for debugging to completely remove > Indeed, but is it necessary to display the untrustworthy user-ID on > signatures? The fingerprint should be sufficient. the name of the primary UID of a signature is irrelevant; if we follow this argument; (i) until it is verified everything is untrustworthy, so (ii) the signature itself shouldn't be shown, nor should any of the UIDs for the public keyblock itself, as the self-signature isn't verified, and (iii) and the keyserver can't verify it as it isn't a trusted part of the infrastructure so the user can't know that it isn't a malicious operator running the specific server. The only logical consequence from (i)-(iii) is to remove keyservers from the mix and let users do bilateral exchanges (good luck with revocation distribution), for the simple reason that SOME users can't do things right, it has to destroy any chance of a proper security for others. Which incidentally is similar to a lot of other over-simplification and interconnections throughout the world, but that is a separate discussion. Finding the least common denominator and simplify everything to the absurd, no matter the consequences. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Great things are not accomplished by those who yield to trends and fads and popular opinion." (Jack Kerouac) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Sep 26 15:05:37 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 26 Sep 2017 15:05:37 +0200 Subject: Houston, we have a problem In-Reply-To: <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> Message-ID: <4013a4ce-eb4e-8ea1-da49-e35d2cda918e@posteo.de> Am 26.09.2017 um 14:49 schrieb Kristian Fiskerstrand: > On 09/26/2017 02:15 PM, Andrew Gallagher wrote: > >>> being able to browse the >>> keyserver directly is too useful for debugging to completely remove >> Indeed, but is it necessary to display the untrustworthy user-ID on >> signatures? The fingerprint should be sufficient. > the name of the primary UID of a signature is irrelevant; if we follow > this argument; (i) until it is verified everything is untrustworthy, so > (ii) the signature itself shouldn't be shown, nor should any of the UIDs > for the public keyblock itself, as the self-signature isn't verified, > and (iii) and the keyserver can't verify it as it isn't a trusted part > of the infrastructure so the user can't know that it isn't a malicious > operator running the specific server. > > The only logical consequence from (i)-(iii) is to remove keyservers from > the mix and let users do bilateral exchanges (good luck with revocation > distribution), for the simple reason that SOME users can't do things > right, it has to destroy any chance of a proper security for others. > Which incidentally is similar to a lot of other over-simplification and > interconnections throughout the world, but that is a separate > discussion. Finding the least common denominator and simplify everything > to the absurd, no matter the consequences. > I'm no expert like all you guys, but my dream would be if Werner and his team could work together with the keybase team, so that we could have WKD support for keybase. Regards Stefan From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 26 15:14:38 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 26 Sep 2017 15:14:38 +0200 Subject: Houston, we have a problem In-Reply-To: <4013a4ce-eb4e-8ea1-da49-e35d2cda918e@posteo.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> <4013a4ce-eb4e-8ea1-da49-e35d2cda918e@posteo.de> Message-ID: <2b40a80b-e952-b3a1-f603-2d8ddb898308@sumptuouscapital.com> On 09/26/2017 03:05 PM, Stefan Claas wrote: > I'm no expert like all you guys, but my dream would be if Werner and his > team could > work together with the keybase team, so that we could have WKD support > for keybase. WKD is a good step in providing a mechanism for key discovery, but if automatically considering such keys valid (either directly or through TOFU-model) you reduce the security to security of X.509 root certificate PKIX, which many users trusts implicitly already so it is a good simplification in many cases. That said I fail to see where keybase comes into the picture, maybe you can elaborate a bit on that? -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you don't drive your business, you will be driven out of business" (B. C. Forbes) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From duane at nofroth.com Tue Sep 26 14:32:30 2017 From: duane at nofroth.com (Duane Whitty) Date: Tue, 26 Sep 2017 09:32:30 -0300 Subject: Houston, we have a problem In-Reply-To: <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-09-26 09:15 AM, Andrew Gallagher wrote: > On 26/09/17 12:30, Kristian Fiskerstrand wrote: >> On 09/26/2017 01:07 PM, Andrew Gallagher wrote: >>> So SKS should just say "unverified signature from >>> ". It should not repeat the purported user ID, nor >>> provide a search link that returns completely unrelated keys >>> that happen to have the same purported ID. >> >> No, that is also wrong, as it implies that anything is trusted >> unless otherwise stated. A malicious actor can claim it is >> verified all he/she wants (simply removing the disclaimer). > > Um, did you reply to the wrong paragraph? I did mention > disclaimers elsewhere, but only in passing (and tongue in cheek). > My argument is that we shouldn't be displaying unverified > information at all. > >> The user's default position NEEDS to be that nothing is verified >> until it is done locally or by an explicitly trusted third >> party. > > Absolutely. None of this is an argument against users having to do > things right. But the way to get users to do things right is to > train them to do things right from the start - and you do that by > railroading them down the straight and narrow and not even have the > option to do it any other way. That way, if the opportunity to do > it wrong arises in the future their first instinct will be "this > isn't how it's supposed to happen". If you can't train people > personally, you have to write your software so that the software > trains them. > Why? Ultimately are we not all responsible for our own actions? People should be required to make some effort. > WhatsApp gets the UX *very nearly* right. And since everyone and > his dog now uses it that's the new baseline. If it's easier to do > it wrong than in WhatsApp, it's broken. If it's harder to > understand than WhatsApp, it's broken. If you have to read more > instructions than WhatsApp, it's broken. > WhatsApp controls the key material. *Seems* safe so far but who knows. I personally would never put anything truly confidential over WhatsApp. And actually people are supposed to verify that they are messaging who they think they are messaging by doing a comparison of fingerprints or ids or whatever they are called. I only message one person with it so it's been a while since I've had to do it. But I am willing to bet lots of users don't do that verification step. It's a good UX but not perfect. Same goes for GPG in my opinion. It's good but not perfect. It never will be and I don't believe any (security) software will ever have a perfect mix of features for all users and use cases out of the "box" > It's no good implementing something correctly if it can be applied > incorrectly. Murphy's Law applies. > I don't want my software or its developers acting like my big brother! >> being able to browse the keyserver directly is too useful for >> debugging to completely remove > > Indeed, but is it necessary to display the untrustworthy user-ID > on signatures? The fingerprint should be sufficient. > > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZykjZAAoJEOJfpr8UVxtkeY4IAKL6A0KqGm85yzSrEh6Stj5z sC86fbEtP/xXkrbYdUDVfkEYuj3AqkNL+E4AaJXO0xT8limk4COMRwl8346V9J7O dzNIjdHAXU0iGrIBxj+CWILyY4qxTnmDar9ef+7lKxFAbJ8pUBJVxzeh0Ci2Al2L hYXhWBrCyjqHqbMmAB/JaUBJy4BTCHNAFy704rblB2ZbqKAqbQpaTP+Jx14HWCQG saSZn8qZwbiAnVcX4vUzssOi5Ls81eEU4W5GPGOqw7u5CvyadgXuJB8578B3qjHH I9JQAIom6xrw3V8USwqsBCO4W9v3+C3fcT1WXivOJsZbKqJDRodjtBrxvKuI1/k= =oYMp -----END PGP SIGNATURE----- From andrewg at andrewg.com Tue Sep 26 15:38:06 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Sep 2017 14:38:06 +0100 Subject: Houston, we have a problem In-Reply-To: <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> Message-ID: On 26/09/17 13:49, Kristian Fiskerstrand wrote: > > The users shoudn't browse keyservers at all, so it shouldn't really be > an issue. Linking to get operation to get the public keyblock is just a > convenience. Users shouldn't do it. And yet they still do it, precisely because it is a convenience. >> WhatsApp gets the UX *very nearly* right. And since everyone and his dog >> now uses it that's the new baseline. If it's easier to do it wrong than > > No, that actually is broken by design It's broken, but it's usable. They've prioritised usability over security, absolutely. People don't care. They should, but they don't. We're not going to get them to embrace something technically better if it's harder to use. > as it doesn't open up for proper operational security controls, > in particular lack of private key > separation on smartcard and airgapped computer. Yes. Unfortunately it's tricky to implement that on a smartphone. We don't have card+phone working in gnupg yet either. We *barely* have gnupg working on phones at all. But that's for another day. > the name of the primary UID of a signature is irrelevant; if we follow > this argument; (i) until it is verified everything is untrustworthy, so > (ii) the signature itself shouldn't be shown, nor should any of the UIDs > for the public keyblock itself, as the self-signature isn't verified I wouldn't go that far. The signature itself is not a signature by "John Doe " - it's a signature by some (sub)key "0x123456...". The fact that it may or may not be a (sub)key bound to "John Doe" is rightly stored elsewhere. My argument is that displaying an unverified comment that *implies* there is a binding *somewhere else* identifying this key with a particular ID may be a convenience, but is a) unnecessary and b) a source of confusion. We can't perform any verification without downloading the full key of the owner anyway, and that's done with the fingerprint. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 26 15:39:12 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 26 Sep 2017 15:39:12 +0200 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> Message-ID: <30c05cb8-875c-60c2-5d50-55917073b12b@sumptuouscapital.com> On 09/26/2017 03:38 PM, Andrew Gallagher wrote: > Yes. Unfortunately it's tricky to implement that on a smartphone. We > don't have card+phone working in gnupg yet either. We *barely* have > gnupg working on phones at all. But that's for another day. Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from OpenKeychain.. Not that it should be used too much, a smartphone is one of the least secure devices around. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Credo quia absurdum I believe it because it is absurd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Sep 26 15:51:34 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Sep 2017 14:51:34 +0100 Subject: Houston, we have a problem In-Reply-To: <30c05cb8-875c-60c2-5d50-55917073b12b@sumptuouscapital.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> <30c05cb8-875c-60c2-5d50-55917073b12b@sumptuouscapital.com> Message-ID: <5f870e35-c72d-71cc-6b28-dc584d542573@andrewg.com> On 26/09/17 14:39, Kristian Fiskerstrand wrote: > On 09/26/2017 03:38 PM, Andrew Gallagher wrote: >> Yes. Unfortunately it's tricky to implement that on a smartphone. We >> don't have card+phone working in gnupg yet either. We *barely* have >> gnupg working on phones at all. But that's for another day. > > Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from > OpenKeychain.. Not that it should be used too much, a smartphone is one > of the least secure devices around. Not getting into an OS flame war here, but not everyone uses Android. ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From sandhya.sharma at morpho.com Tue Sep 26 14:04:56 2017 From: sandhya.sharma at morpho.com (SHARMA Sandhya (MORPHO)) Date: Tue, 26 Sep 2017 12:04:56 +0000 Subject: Use of Passphrase Callback Message-ID: Hello, Does anyone has idea how to implement this. As I have urgent business need to do it ASAP. Thanks, Sandhya From: SHARMA Sandhya (MORPHO) Sent: Friday, September 22, 2017 6:21 PM To: 'gnupg-users at gnupg.org' Subject: Use of Passphrase Callback Hello, I am Using gnupg on windows and want to use "Passphrase Callback" functionality to input password for private key. My current lines of code is: error = gpgme_set_pinentry_mode(context,GPGME_PINENTRY_MODE_LOOPBACK); gpgme_passphrase_cb_t func = &passphrase_callback; gpgme_pinentry_mode_t pinMode = gpgme_get_pinentry_mode(context); void *pp = 0; gpgme_set_passphrase_cb(context,func,pp); and declaration of gpgme_passphrase_cb_t is gpgme_error_t passphrase_callback(void *opaque, const char *uid_hint, const char *desc,int prev_was_bad, int fd) but breakpoint on this function never hits. Kindly provide help on this or any example used to implement Passphrase CallBack. Thanks & Regards, Sandhya Sharma # " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." # -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Sep 26 16:18:17 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 26 Sep 2017 16:18:17 +0200 Subject: Houston, we have a problem In-Reply-To: <5f870e35-c72d-71cc-6b28-dc584d542573@andrewg.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> <30c05cb8-875c-60c2-5d50-55917073b12b@sumptuouscapital.com> <5f870e35-c72d-71cc-6b28-dc584d542573@andrewg.com> Message-ID: <1e9738bc-b07f-5a2d-de9a-420a00d2bc7e@sumptuouscapital.com> On 09/26/2017 03:51 PM, Andrew Gallagher wrote: > Not getting into an OS flame war here, but not everyone uses Android. That doesn't mean it doesn't exist, it just means different user preferences as represented by the weigths in the decision matrix when purchasing a new device. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Tue Sep 26 16:25:21 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Tue, 26 Sep 2017 16:25:21 +0200 Subject: Houston, we have a problem In-Reply-To: <2b40a80b-e952-b3a1-f603-2d8ddb898308@sumptuouscapital.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <474d0b8c-e49b-4b5f-8abd-f94961f65ee7@andrewg.com> <4f44b1d6-dbc1-aed3-5743-90402fe7069c@sumptuouscapital.com> <4013a4ce-eb4e-8ea1-da49-e35d2cda918e@posteo.de> <2b40a80b-e952-b3a1-f603-2d8ddb898308@sumptuouscapital.com> Message-ID: <20170926162506.08836a35@iria.my-fqdn.de> On Tue, 26 Sep 2017 15:14:38 +0200, Kristian Fiskerstrand wrote: > On 09/26/2017 03:05 PM, Stefan Claas wrote: > > I'm no expert like all you guys, but my dream would be if Werner > > and his team could > > work together with the keybase team, so that we could have WKD > > support for keybase. > > WKD is a good step in providing a mechanism for key discovery, but if > automatically considering such keys valid (either directly or through > TOFU-model) you reduce the security to security of X.509 root > certificate PKIX, which many users trusts implicitly already so it is > a good simplification in many cases. That said I fail to see where > keybase comes into the picture, maybe you can elaborate a bit on that? > Well, i can't fetch keys from keybase with GnuPG in the command line like i can do with traditional key servers. On keybase i am in full control of my pub key, so that nobody can add there unwanted signatures or a fake "sig3" to my pub key. I could not test WKD yet, but believe that the same rule applies there too, with protecting my pub key. If both, WKD and keybase could work as one unit GnuPG power users could fetch keys via CLI, as usual, or via their client software and users had the ability too to check also the keybase Web Interface for additional infos about a user, if they like to do so. keybase current stats: Keys: 763,642 Humans: 180,431 Teams: 8,652 (new!) The figures should not be underestimated imho because i believe that keybase helps also the grow of GnuPG and is a nice addition for GnuPG users, me thinks. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From rjh at sixdemonbag.org Tue Sep 26 17:37:53 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 26 Sep 2017 11:37:53 -0400 Subject: Houston, we have a problem In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: <265df61b-2f12-566a-fa47-15b127239e6e@sixdemonbag.org> > But user-facing software shouldn't be exposing unverified IDs *at all*. > Enigmail now sort-of does this... As the guy who was largely pushing that on Enigmail ... although I strongly sympathize, there's a rock here and a hard place there. UX is not driven by the users we *might* have: it's driven by the users we *do* have. The users we do have *do not want to switch*. I think that after investing so much in learning the current system, users tend to develop powerful opinions the UX should just be left alone please don't fix a thing. Imagine you have this certificate: + Kate 0xDECAFBAD +-- Kathryn Carver 0xDECAFBAD (That is to say, a primary userID of Kate, and one other UIDs using her full name.) Now throw that into a whole bunch of other certificates and render them in a GUI toolkit. All rows are collapsed by default. Now ask a user to find the certificate associated with Kathryn Carver. 90% of users will click on the "Name" column header to sort by name, will survey the Ks, and then say "she's not in the system." (And yes, I found this in a usability study I did in '07 with Tristan Thiede and Juan-Pablo Hourcade.) Clearly there's a problem here. Obviously the way we present certificates to users is broken and wrong. But God help you if you change the way you present certificates: some people will complain loudly and the vast majority of users just won't consider switching. Change is hard, and I have no good answer for that. From andrewg at andrewg.com Tue Sep 26 17:52:04 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Sep 2017 16:52:04 +0100 Subject: Houston, we have a problem In-Reply-To: <265df61b-2f12-566a-fa47-15b127239e6e@sixdemonbag.org> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <265df61b-2f12-566a-fa47-15b127239e6e@sixdemonbag.org> Message-ID: On 26/09/17 16:37, Robert J. Hansen wrote: > I think > that after investing so much in learning the current system, users tend > to develop powerful opinions the UX should just be left alone please > don't fix a thing. Yes, this is a universal problem. The people who are most invested in Thing X are also the people who are most resistant to making Thing X more attractive to new people. This applies to politics, culture, engineering, you name it. It's also the main non-technical reason why we keep reinventing things from scratch instead of building on what we already have (the technical one being baked-in assumptions). On the other hand, I am usually the first person to complain about weakly justified UX changes. Gnome3 comes to mind... ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Sep 26 21:39:50 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Sep 2017 21:39:50 +0200 Subject: Houston, we have a problem In-Reply-To: (Andrew Gallagher's message of "Tue, 26 Sep 2017 12:07:48 +0100") References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> Message-ID: <8760c55jw9.fsf@wheatstone.g10code.de> On Tue, 26 Sep 2017 13:07, andrewg at andrewg.com said: > The gpg command itself should cryptographically verify signatures when > performing --list-sigs, so that at least it can throw a warning when an Actually --list-sigs is more of a debug command than a command users should use to verify a key. The real command is --check-sigs and it does what you suggested. Unfortunately the man pages describes --list-sigs in detail and only in the next paragraph --check-sigs is explained in terms of --list-sigs. it might be better to merge them into one description with a focus on --check-sigs. Anyway, it is easy to create keys just for signatures and --check-sigs would not make a difference. Look at my key for all those vanity signature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thejze at gmx.at Tue Sep 26 21:46:33 2017 From: thejze at gmx.at (Thomas Hejze) Date: Tue, 26 Sep 2017 21:46:33 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <20170921174834.GA2358@c720-r314251> References: <3771476.PIQjPmmXgn@linux.suse> <2539217.4tTC13fNCR@linux.suse> <20170921174834.GA2358@c720-r314251> Message-ID: <12562420.FHXlO7kFAI@linux.suse> Am Donnerstag, 21. September 2017, 19:48:34 CEST schrieb Matthias Apitz: > > Unfortunately their hardware dos not seem to support Ubuntu any more. I > > found the "Ubuntu Edition" under "obsolete models", even a cyanogen > > edition, but all their current models run on Android. The rest of their > > homepage is all marketing gibberish as it is the use, nowadays. > > Look for second hand devices of the BQ "Ubuntu Edition" (BQ does not > produce nor sell them anymore). Such devices you could reflash to the > software available at ubports.com Thanks for the information, but what are the perspectives? Lets hope the community has enough endurance, but which hardware to buy in three or four years? Regards Thomas From thejze at gmx.at Tue Sep 26 21:37:16 2017 From: thejze at gmx.at (Thomas Hejze) Date: Tue, 26 Sep 2017 21:37:16 +0200 Subject: OT: Which smartphone would you use In-Reply-To: <8488acb3-7da7-8014-a324-a0f8a6b8f007@mecadu.org> References: <3771476.PIQjPmmXgn@linux.suse> <3290527.E9oQLpDK85@linux.suse> <8488acb3-7da7-8014-a324-a0f8a6b8f007@mecadu.org> Message-ID: <1673217.R4ems7K5yi@linux.suse> Am Freitag, 22. September 2017, 10:36:45 CEST schrieb Franck Routier: > Hi, Jolla did an official port of SailfishOS to Sony Xperia X hardware. > The only point is the the image is not yet available for purchase, > but it should be a matter of days... > > See https://blog.jolla.com/sailfishx/ Thanks for the information. I'll keep an eye on it. Regards Thomas From andrewg at andrewg.com Wed Sep 27 11:10:54 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 27 Sep 2017 10:10:54 +0100 Subject: Houston, we have a problem In-Reply-To: <8760c55jw9.fsf@wheatstone.g10code.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> Message-ID: On 26/09/17 20:39, Werner Koch wrote: > On Tue, 26 Sep 2017 13:07, andrewg at andrewg.com said: > >> The gpg command itself should cryptographically verify signatures when >> performing --list-sigs, so that at least it can throw a warning when an > > Actually --list-sigs is more of a debug command than a command users > should use to verify a key. The real command is --check-sigs and it > does what you suggested. I've been using gpg for decades, and I was unaware of the distinction. Thanks! But a follow-on question arises: is Enigmail using --list-sigs rather than --check-sigs? Its output appears to be derived from --list-sigs, which undermines somewhat the rationale behind only displaying sigs from known keys. > Unfortunately the man pages describes --list-sigs in detail and only in > the next paragraph --check-sigs is explained in terms of --list-sigs. > it might be better to merge them into one description with a focus on > --check-sigs. Or just describe --check-sigs and have --list-sigs tucked away in an "experts only, beware" section. This is the sort of thing I was thinking of when I talked about "railroading the user" earlier. There are two ways of doing something, one is more secure than the other but it's not immediately clear which, and the casual user therefore has *too much* choice. This has two effects: 1. the user may choose the less secure option by accident; 2. the user is frightened of using the software for fear of choosing the less secure option by accident. And if you do choose the less secure option by accident, there's no feedback to tell you that you're off the reservation. I've been using --list-sigs forever and I thought I was getting --check-sigs. At no time did gpg disabuse me of that. I hear the arguments about users becoming reliant on warnings, but warnings in this case aren't about telling people that something unexpected has happened - they're about telling users that they're doing it wrong. Once they learn how to do things right, they become *less* reliant on the warnings, not more. > Anyway, it is easy to create keys just for signatures and --check-sigs > would not make a difference. Look at my key for all those vanity > signature. Yes, but unless a collision is found (in which case we're all screwed), a signature made by a fake key will have a distinct fingerprint, and we've reduced the problem space back to fake keys, which at least have the advantage of being well-known. An option such as Enigmail's "don't display unknown sigs" can handle that. Furthermore, if "don't display unknown sigs" was default behaviour everywhere, it would remove the incentive to make wasteful vanity sigs in the first place. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Sep 27 20:24:49 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 Sep 2017 14:24:49 -0400 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> Message-ID: <87zi9gt2xa.fsf@fifthhorseman.net> On Wed 2017-09-27 10:10:54 +0100, Andrew Gallagher wrote: > On 26/09/17 20:39, Werner Koch wrote: >> Unfortunately the man pages describes --list-sigs in detail and only in >> the next paragraph --check-sigs is explained in terms of --list-sigs. >> it might be better to merge them into one description with a focus on >> --check-sigs. > > Or just describe --check-sigs and have --list-sigs tucked away in an > "experts only, beware" section. I've noted this as https://dev.gnupg.org/T3430 --dkg From stefan.claas at posteo.de Thu Sep 28 11:57:14 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 28 Sep 2017 11:57:14 +0200 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: <87zi9gt2xa.fsf@fifthhorseman.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> Message-ID: <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> Am 27.09.2017 um 20:24 schrieb Daniel Kahn Gillmor: > On Wed 2017-09-27 10:10:54 +0100, Andrew Gallagher wrote: >> On 26/09/17 20:39, Werner Koch wrote: >>> Unfortunately the man pages describes --list-sigs in detail and only in >>> the next paragraph --check-sigs is explained in terms of --list-sigs. >>> it might be better to merge them into one description with a focus on >>> --check-sigs. >> Or just describe --check-sigs and have --list-sigs tucked away in an >> "experts only, beware" section. > I've noted this as https://dev.gnupg.org/T3430 > > --dkg > Now i have a problem lol... with my new pub key and --check-sigs. My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1, which i just downloaded... Therfore i checked other users, which have a Governikus sig3 and the error persists. Any ideas gentlemen? Regards Stefan From andrewg at andrewg.com Thu Sep 28 13:30:11 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 28 Sep 2017 12:30:11 +0100 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> Message-ID: On 2017/09/28 10:57, Stefan Claas wrote: > > Now i have a problem lol... with my new pub key and --check-sigs. > > My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed > by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing > a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1, > which i just > downloaded... Therfore i checked other users, which have a Governikus > sig3 and > the error persists. Any ideas gentlemen? What specific error are you getting? I don't see any errors using --check-sigs on that key, but then I don't trust Governikus so I'm not performing the same test that you are. BTW, your usage of key IDs to contain arbitrary text produces some weird results: ``` galactica:~ andrewg$ gpg --search-keys stefan.claas at posteo.de gpg: searching for "stefan.claas at posteo.de" from hkps server hkps.pool.sks-keyservers.net (1) supersedes 0x981EB7C382EC52B4 Stefan Claas 2048 bit RSA key 0xD68B6EAC6ECF3AB6, created: 2017-09-23, expires: 2022-09-22 (2) Stefan Claas (ECC Test Key - do not use) 256 bit unknown key 0x2C5F53E23FC75D86, created: 2017-07-15 (revoked) (3) Stefan Claas 2048 bit RSA key 0x981EB7C382EC52B4, created: 2017-05-26, expires: 2021-05-26 (4) Stefan Claas Stefan Claas Stefan Claas at https://keybase.io/stefan_claas Stefan Claas Stefan Claas Stefan Claas servers. A valid copy of this key can be found because i no longer support standard public key This key is revoked for public key server usage, 2048 bit RSA key 0xAAD2E08D4A3C2C49, created: 2013-11-27 (revoked) Keys 1-4 of 4 for "stefan.claas at posteo.de". Enter number(s), N)ext, or Q)uit > 1 ``` A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Thu Sep 28 13:59:59 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 28 Sep 2017 13:59:59 +0200 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> Message-ID: Am 28.09.2017 um 13:30 schrieb Andrew Gallagher: > On 2017/09/28 10:57, Stefan Claas wrote: >> Now i have a problem lol... with my new pub key and --check-sigs. >> >> My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed >> by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing >> a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1, >> which i just >> downloaded... Therfore i checked other users, which have a Governikus >> sig3 and >> the error persists. Any ideas gentlemen? > What specific error are you getting? I don't see any errors using > --check-sigs on that key, but then I don't trust Governikus so I'm not > performing the same test that you are. Well, i installed today at work gpg4win (GnuPG 2.2.1) and it tells me when downloading my pub key 1 bad signature in German. when doing a --check-sigs it tells me in German: gpg: 5 korrekte Signaturen gpg: 1 falsche Beglaubigung the good signatures are shown with gpg in cmd.exe as sig!3 and the bad signature is shown as sig-3. Same applies when i do gpg --recv-keys/--check-sigs from other keys signed by Governikus. > > BTW, your usage of key IDs to contain arbitrary text produces some weird > results: > > When long time ago Facebook's pub key received it's vanity sigs i was upset and decided to no longer support traditional key servers and added this text to my key. Regards Stefan From wk at gnupg.org Thu Sep 28 14:20:13 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Sep 2017 14:20:13 +0200 Subject: preferring --check-sigs over --list-sigs In-Reply-To: <87zi9gt2xa.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 27 Sep 2017 14:24:49 -0400") References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> Message-ID: <8737772ewy.fsf@wheatstone.g10code.de> On Wed, 27 Sep 2017 20:24, dkg at fifthhorseman.net said: > I've noted this as https://dev.gnupg.org/T3430 Thanks. My fix is --check-signatures --check-sigs Same as --list-keys, but the key signatures are verified and listed too. Note that for performance reasons the revocation status of a signing key is not shown. This command has the same effect as using --list-keys with --with-sig-check. The status of the verification is indicated by a flag directly following the "sig" tag (and thus before the flags described below. A "!" indicates that the signature has been success? fully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm). Signatures where the public key is not availabale are not listed; to see their keyids the command --list-sigs can be used. For each signature listed, there are several flags in between the signature status flag and keyid. These flags give addi? tional information about each key signature. From left to right, they are the numbers 1-3 for certificate check level (see --ask-cert-level), "L" for a local or non-exportable sig? nature (see --lsign-key), "R" for a nonRevocable signature (see the --edit-key command "nrsign"), "P" for a signature that contains a policy URL (see --cert-policy-url), "N" for a signature that contains a notation (see --cert-notation), "X" for an eXpired signature (see --ask-cert-expire), and the num? bers 1-9 or "T" for 10 and above to indicate trust signature levels (see the --edit-key command "tsign"). and far below under esoteric options: --list-signatures --list-sigs Same as --list-keys, but the signatures are listed too. This command has the same effect as using --list-keys with --with- sig-list. Note that in contrast to --check-signatures the key signatures are not verified. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Thu Sep 28 15:18:09 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Sep 2017 15:18:09 +0200 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> Message-ID: <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> On 28/09/17 13:30, Andrew Gallagher wrote: > What specific error are you getting? I don't see any errors using > --check-sigs on that key, but then I don't trust Governikus so I'm not > performing the same test that you are. Are you sure you had the Governikus key in your keyring? I am seeing the same as Stefan: the signature is bad. It says sig-3, the dash indicates failure. It should have been sig!3 for a good signature. For reference, this is the Governikus signature in --list-packets format: :signature packet: algo 1, keyid 5E5CCCB4A4BF43D7 version 4, created 1506196241, md5len 0, sigclass 0x13 digest algo 8, begin of digest 6b 6e hashed subpkt 2 len 4 (sig created 2017-09-23) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 5E5CCCB4A4BF43D7) data: [4095 bits] It is a SHA256 trust signature issued by an RSA key. I think it's odd they issue a level 1 partial trust signature, but I'd guess they think they're doing their users a service by making it possible to automatically assign partial trust to all keys signed by them, if you want to. Don't worry, this won't happen unless you issue at least a level 2 trust signature to Governikus. At least, I'm fairly sure it's not enough to simply assign full ownertrust to Governikus, ownertrust and trust signatures don't interact, right? I don't see anything yet that stands out to me as "this must be why it's a bad signature". But we can always dig deeper. Using gpg's debugging output, it is clear that the RSA signature is well-formed, but the hash doesn't match. If I read it right, GnuPG wants the hash to be: 8fa83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46 But the Governikus signature hash is: 6b6e7c7823d29203332faae25a3abb18a7e36689a77e5f32feb57c73e7e0ec48 I didn't actually parse the ASN.1, though, I simply used common sense: the signature packet indicates the Governikus hash starts with 6b 6e, and the length is correct for a SHA-256 hash, so it makes sense that the ASN.1 ends with the pure hash. Haven't thought about endianness. I don't know what could cause this. This is as far as I can go. Perhaps a developer recognises the situation. Here's the debugging output: --8<---------------cut here---------------start------------->8--- gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004208f \ gpg: DBG: a83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46 gpg: DBG: rsa_verify sig:+7c0d84121a51ae5f5e99d131fc0e0e1e9157b03375b65bfd706aef1b42776ccd \ gpg: DBG: c5ef1d4c7a4a77733af8f49648000e2c779e176e4874609ca3d22a88beac09c4 \ gpg: DBG: f4556a9a25636ac6acc33e366356fb71f7c702771a622773ab55fe00cb4d3f71 \ gpg: DBG: 6d291871302dc35e0ecd9a37cf60887d9b65e2f751172eb9c81e5c9bb76d3b07 \ gpg: DBG: f2589f29196761f39d9786956ba8d20a2a4df6f0157861bc49a972d923567135 \ gpg: DBG: a45bcaf8bded2a55edcdadd7109fef620b533fabb0a29bcf4a254a2a6043be46 \ gpg: DBG: be8606d0e21075a1b1927f3a3c846a21abb52d64c3260c451a7a9688ff290caf \ gpg: DBG: 9be60639618cd547dd6ad5beed0dd0167ba01fafbcf0b8650b02bd47166d5705 \ gpg: DBG: 2b30fd7314625b925b4638469524b54d084f1e4bec5fd3ed19b576fc25fffe27 \ gpg: DBG: cf71b534be9cf865f4db030bf99f2617f4520c6c47bf94593af2fe91800cc838 \ gpg: DBG: 8e43c86864d5338b53ef88d65657b5ba241072cdc4b1744b44bd01ccbf9e8124 \ gpg: DBG: 83fb23c00e94900bd94c3070c0dfbfd85a8244e07b22f275376dd9ba8b8af16b \ gpg: DBG: 6f79ed424330e4b4611478863ad67819a1a12fe86ec6bb466d8823d5982c462a \ gpg: DBG: 4a2f35a8369092487d66d12f75e7701205e2d3b6b5932e01a98d66e2ac61243a \ gpg: DBG: d97d8f5c46d7d965d27e1dbaee09af1c2787121845d11a73c8a3b5b6dc66d44b \ gpg: DBG: d849cd96decb42ad8d4d7df80da7aa9ddc072c37fea1cf68c349d7c3a4909e2a gpg: DBG: rsa_verify n:+ac04bff70099263c05a8a3be359f82648d18b3b0e5b7fd15994c438683ba175b \ gpg: DBG: 7d6763f59f8778f01957fa82a3edcc94896de20f1fe8b0e4d214db863f18013f \ gpg: DBG: 8e4ab9b4d16e4381cca8b877db3399a99aa8475c6ba9b6e04143e5e55ac8c438 \ gpg: DBG: 323e5365abef50c0468dc8afeb03cd0e15846393d5a52aaa7b60ade16b834214 \ gpg: DBG: d8be2000ac9550327215c2e8da95cd8e5ba60dbf2846f139ffd44e1e3a1dd366 \ gpg: DBG: e3e7c0a7c1dd8924501e8f93bfb18020fbae5c3f942a0e8b0c61f5561ee9b17d \ gpg: DBG: 23521cabc4c26213236720824a0356c34af4e22ee1da9dde2d151e1b0b0e04d6 \ gpg: DBG: a63df7817aadaa43964bd57de7c1c4d0092ba132a9e5bd8bb05335d5e195a5b4 \ gpg: DBG: c47d121004021f3648a13da771edf0a48601fc047b9aa54d4f58fba2f53b680e \ gpg: DBG: 29e2e8c6101f050fc5035f08f38300b1c799e6631efff5eb78c1d8898c6862cf \ gpg: DBG: 3cc167e371817499afff072f5b3f8e150a4c836580911d17f47fc460ae8d6547 \ gpg: DBG: ca4b067811cae95590e294e89610af96aeb834697d9525d86ce74129e432dc7c \ gpg: DBG: 4380807b1eb6fd5dfc5604ab3d050bf9f1ba589979f914717e11807b02787681 \ gpg: DBG: 66b729babd216b2e85beb3565d2583fc1fff7c69a6ec91226b40b2fe0aead4f9 \ gpg: DBG: 7625d05eb251e3ab8a85f16981c85ec03d745db81dee38ca948e4aa5aff14529 \ gpg: DBG: f6ae044278dec55f50ccb7c918d7f9b41443df640ddebc7d1632bf90d47dc9cf gpg: DBG: rsa_verify e:+010001 gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004206b \ gpg: DBG: 6e7c7823d29203332faae25a3abb18a7e36689a77e5f32feb57c73e7e0ec48 gpg: DBG: rsa_verify => Bad signature --8<---------------cut here---------------end--------------->8--- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Sep 28 15:20:39 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Sep 2017 15:20:39 +0200 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> Message-ID: Okay, I made a boo boo regarding text wrapping. Let me repaste the debug output: --8<---------------cut here---------------start------------->8--- gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004208f \ gpg: DBG: a83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46 gpg: DBG: rsa_verify sig:+7c0d84121a51ae5f5e99d131fc0e0e1e9157b03375b65bfd706aef1b42776ccd \ gpg: DBG: c5ef1d4c7a4a77733af8f49648000e2c779e176e4874609ca3d22a88beac09c4 \ gpg: DBG: f4556a9a25636ac6acc33e366356fb71f7c702771a622773ab55fe00cb4d3f71 \ gpg: DBG: 6d291871302dc35e0ecd9a37cf60887d9b65e2f751172eb9c81e5c9bb76d3b07 \ gpg: DBG: f2589f29196761f39d9786956ba8d20a2a4df6f0157861bc49a972d923567135 \ gpg: DBG: a45bcaf8bded2a55edcdadd7109fef620b533fabb0a29bcf4a254a2a6043be46 \ gpg: DBG: be8606d0e21075a1b1927f3a3c846a21abb52d64c3260c451a7a9688ff290caf \ gpg: DBG: 9be60639618cd547dd6ad5beed0dd0167ba01fafbcf0b8650b02bd47166d5705 \ gpg: DBG: 2b30fd7314625b925b4638469524b54d084f1e4bec5fd3ed19b576fc25fffe27 \ gpg: DBG: cf71b534be9cf865f4db030bf99f2617f4520c6c47bf94593af2fe91800cc838 \ gpg: DBG: 8e43c86864d5338b53ef88d65657b5ba241072cdc4b1744b44bd01ccbf9e8124 \ gpg: DBG: 83fb23c00e94900bd94c3070c0dfbfd85a8244e07b22f275376dd9ba8b8af16b \ gpg: DBG: 6f79ed424330e4b4611478863ad67819a1a12fe86ec6bb466d8823d5982c462a \ gpg: DBG: 4a2f35a8369092487d66d12f75e7701205e2d3b6b5932e01a98d66e2ac61243a \ gpg: DBG: d97d8f5c46d7d965d27e1dbaee09af1c2787121845d11a73c8a3b5b6dc66d44b \ gpg: DBG: d849cd96decb42ad8d4d7df80da7aa9ddc072c37fea1cf68c349d7c3a4909e2a gpg: DBG: rsa_verify n:+ac04bff70099263c05a8a3be359f82648d18b3b0e5b7fd15994c438683ba175b \ gpg: DBG: 7d6763f59f8778f01957fa82a3edcc94896de20f1fe8b0e4d214db863f18013f \ gpg: DBG: 8e4ab9b4d16e4381cca8b877db3399a99aa8475c6ba9b6e04143e5e55ac8c438 \ gpg: DBG: 323e5365abef50c0468dc8afeb03cd0e15846393d5a52aaa7b60ade16b834214 \ gpg: DBG: d8be2000ac9550327215c2e8da95cd8e5ba60dbf2846f139ffd44e1e3a1dd366 \ gpg: DBG: e3e7c0a7c1dd8924501e8f93bfb18020fbae5c3f942a0e8b0c61f5561ee9b17d \ gpg: DBG: 23521cabc4c26213236720824a0356c34af4e22ee1da9dde2d151e1b0b0e04d6 \ gpg: DBG: a63df7817aadaa43964bd57de7c1c4d0092ba132a9e5bd8bb05335d5e195a5b4 \ gpg: DBG: c47d121004021f3648a13da771edf0a48601fc047b9aa54d4f58fba2f53b680e \ gpg: DBG: 29e2e8c6101f050fc5035f08f38300b1c799e6631efff5eb78c1d8898c6862cf \ gpg: DBG: 3cc167e371817499afff072f5b3f8e150a4c836580911d17f47fc460ae8d6547 \ gpg: DBG: ca4b067811cae95590e294e89610af96aeb834697d9525d86ce74129e432dc7c \ gpg: DBG: 4380807b1eb6fd5dfc5604ab3d050bf9f1ba589979f914717e11807b02787681 \ gpg: DBG: 66b729babd216b2e85beb3565d2583fc1fff7c69a6ec91226b40b2fe0aead4f9 \ gpg: DBG: 7625d05eb251e3ab8a85f16981c85ec03d745db81dee38ca948e4aa5aff14529 \ gpg: DBG: f6ae044278dec55f50ccb7c918d7f9b41443df640ddebc7d1632bf90d47dc9cf gpg: DBG: rsa_verify e:+010001 --8<---------------cut here---------------end--------------->8--- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Sep 28 15:22:55 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Sep 2017 15:22:55 +0200 Subject: preferring --check-sigs over --list-sigs In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> Message-ID: <55d582ab-8f68-adb1-1d92-940754592e22@digitalbrains.com> Ugh, really, how hard can it be? :-( Sorry about this. I'll try to get it right this time. --8<---------------cut here---------------start------------->8--- gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004208f \ gpg: DBG: a83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46 gpg: DBG: rsa_verify sig:+7c0d84121a51ae5f5e99d131fc0e0e1e9157b03375b65bfd706aef1b42776ccd \ gpg: DBG: c5ef1d4c7a4a77733af8f49648000e2c779e176e4874609ca3d22a88beac09c4 \ gpg: DBG: f4556a9a25636ac6acc33e366356fb71f7c702771a622773ab55fe00cb4d3f71 \ gpg: DBG: 6d291871302dc35e0ecd9a37cf60887d9b65e2f751172eb9c81e5c9bb76d3b07 \ gpg: DBG: f2589f29196761f39d9786956ba8d20a2a4df6f0157861bc49a972d923567135 \ gpg: DBG: a45bcaf8bded2a55edcdadd7109fef620b533fabb0a29bcf4a254a2a6043be46 \ gpg: DBG: be8606d0e21075a1b1927f3a3c846a21abb52d64c3260c451a7a9688ff290caf \ gpg: DBG: 9be60639618cd547dd6ad5beed0dd0167ba01fafbcf0b8650b02bd47166d5705 \ gpg: DBG: 2b30fd7314625b925b4638469524b54d084f1e4bec5fd3ed19b576fc25fffe27 \ gpg: DBG: cf71b534be9cf865f4db030bf99f2617f4520c6c47bf94593af2fe91800cc838 \ gpg: DBG: 8e43c86864d5338b53ef88d65657b5ba241072cdc4b1744b44bd01ccbf9e8124 \ gpg: DBG: 83fb23c00e94900bd94c3070c0dfbfd85a8244e07b22f275376dd9ba8b8af16b \ gpg: DBG: 6f79ed424330e4b4611478863ad67819a1a12fe86ec6bb466d8823d5982c462a \ gpg: DBG: 4a2f35a8369092487d66d12f75e7701205e2d3b6b5932e01a98d66e2ac61243a \ gpg: DBG: d97d8f5c46d7d965d27e1dbaee09af1c2787121845d11a73c8a3b5b6dc66d44b \ gpg: DBG: d849cd96decb42ad8d4d7df80da7aa9ddc072c37fea1cf68c349d7c3a4909e2a gpg: DBG: rsa_verify n:+ac04bff70099263c05a8a3be359f82648d18b3b0e5b7fd15994c438683ba175b \ gpg: DBG: 7d6763f59f8778f01957fa82a3edcc94896de20f1fe8b0e4d214db863f18013f \ gpg: DBG: 8e4ab9b4d16e4381cca8b877db3399a99aa8475c6ba9b6e04143e5e55ac8c438 \ gpg: DBG: 323e5365abef50c0468dc8afeb03cd0e15846393d5a52aaa7b60ade16b834214 \ gpg: DBG: d8be2000ac9550327215c2e8da95cd8e5ba60dbf2846f139ffd44e1e3a1dd366 \ gpg: DBG: e3e7c0a7c1dd8924501e8f93bfb18020fbae5c3f942a0e8b0c61f5561ee9b17d \ gpg: DBG: 23521cabc4c26213236720824a0356c34af4e22ee1da9dde2d151e1b0b0e04d6 \ gpg: DBG: a63df7817aadaa43964bd57de7c1c4d0092ba132a9e5bd8bb05335d5e195a5b4 \ gpg: DBG: c47d121004021f3648a13da771edf0a48601fc047b9aa54d4f58fba2f53b680e \ gpg: DBG: 29e2e8c6101f050fc5035f08f38300b1c799e6631efff5eb78c1d8898c6862cf \ gpg: DBG: 3cc167e371817499afff072f5b3f8e150a4c836580911d17f47fc460ae8d6547 \ gpg: DBG: ca4b067811cae95590e294e89610af96aeb834697d9525d86ce74129e432dc7c \ gpg: DBG: 4380807b1eb6fd5dfc5604ab3d050bf9f1ba589979f914717e11807b02787681 \ gpg: DBG: 66b729babd216b2e85beb3565d2583fc1fff7c69a6ec91226b40b2fe0aead4f9 \ gpg: DBG: 7625d05eb251e3ab8a85f16981c85ec03d745db81dee38ca948e4aa5aff14529 \ gpg: DBG: f6ae044278dec55f50ccb7c918d7f9b41443df640ddebc7d1632bf90d47dc9cf gpg: DBG: rsa_verify e:+010001 gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ gpg: DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004206b \ gpg: DBG: 6e7c7823d29203332faae25a3abb18a7e36689a77e5f32feb57c73e7e0ec48 --8<---------------cut here---------------end--------------->8--- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Thu Sep 28 15:43:54 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 28 Sep 2017 14:43:54 +0100 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> Message-ID: <09082638-3cc5-bf1b-0a0c-6972174f08dd@andrewg.com> On 28/09/17 12:59, Stefan Claas wrote: > When long time ago Facebook's pub key received it's vanity sigs i was > upset and decided > to no longer support traditional key servers and added this text to my key. As I argued above, vanity signatures *shouldn't* be an issue - the problem comes when client software blindly regurgitates vanity signatures without any consideration of their usefulness. But back to the point at hand. I wasn't referring to you putting plaintext in your ID (lots of people do that), but because you split the plaintext over multiple IDs it becomes scrambled because IDs don't have an intrinsic order. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Thu Sep 28 15:58:05 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 28 Sep 2017 14:58:05 +0100 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> Message-ID: <3d7b3232-53e7-0044-6da9-57fddf39f1b2@andrewg.com> On 28/09/17 14:18, Peter Lebbing wrote: > Are you sure you had the Governikus key in your keyring? I am seeing the > same as Stefan: the signature is bad. It says sig-3, the dash indicates > failure. It should have been sig!3 for a good signature. Apologies, you are right. Importing the governikus key gives me the same result. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Thu Sep 28 16:13:58 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 28 Sep 2017 16:13:58 +0200 Subject: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem] In-Reply-To: <3d7b3232-53e7-0044-6da9-57fddf39f1b2@andrewg.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> <3d7b3232-53e7-0044-6da9-57fddf39f1b2@andrewg.com> Message-ID: <20170928161344.7d7149ea@iria.my-fqdn.de> On Thu, 28 Sep 2017 14:58:05 +0100, Andrew Gallagher wrote: > On 28/09/17 14:18, Peter Lebbing wrote: > > Are you sure you had the Governikus key in your keyring? I am > > seeing the same as Stefan: the signature is bad. It says sig-3, the > > dash indicates failure. It should have been sig!3 for a good > > signature. > > Apologies, you are right. Importing the governikus key gives me the > same result. I just mailed Governikus. Let's see what they say, or what Werner says. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas From dkg at fifthhorseman.net Thu Sep 28 19:13:10 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Sep 2017 13:13:10 -0400 Subject: onwnertrust and trust signature (tsig) interactions [was: Re: preferring --check-sigs over --list-sigs] In-Reply-To: <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> Message-ID: <87tvzmrbkp.fsf@fifthhorseman.net> On Thu 2017-09-28 15:18:09 +0200, Peter Lebbing wrote: > It is a SHA256 trust signature issued by an RSA key. I think it's odd > they issue a level 1 partial trust signature, but I'd guess they think > they're doing their users a service by making it possible to > automatically assign partial trust to all keys signed by them, if you > want to. Don't worry, this won't happen unless you issue at least a > level 2 trust signature to Governikus. At least, I'm fairly sure it's > not enough to simply assign full ownertrust to Governikus, ownertrust > and trust signatures don't interact, right? Yes, ownertrust and trust signatures do interact. a trust signature (tsig) made by a key that you have set ultimate ownertrust on delegates some of that ownertrust via trust signatures. I thought that was also true for full ownertrust, but i'm unable to replicate it with an experimental keyring. Perhaps Werner or someone else closer to the trust management code can comment on the expected behavior? --dkg From peter at digitalbrains.com Thu Sep 28 20:15:33 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Sep 2017 20:15:33 +0200 Subject: onwnertrust and trust signature (tsig) interactions In-Reply-To: <87tvzmrbkp.fsf@fifthhorseman.net> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> <87tvzmrbkp.fsf@fifthhorseman.net> Message-ID: <2afb6244-e270-a9bb-9291-97c153383710@digitalbrains.com> I didn't formulate what I meant well enough, I think. Sorry. On 28/09/17 19:13, Daniel Kahn Gillmor wrote: > Yes, ownertrust and trust signatures do interact. > > a trust signature (tsig) made by a key that you have set ultimate > ownertrust on delegates some of that ownertrust via trust signatures. Fair enough; that I would expect, actually. It has to start somewhere, and that's what "ultimate" is for, on your own keys. If "ultimate" keys didn't have this capability, there would be no root for the trust signatures. > I thought that was also true for full ownertrust, but i'm unable to > replicate it with an experimental keyring. This I would not expect, but it is what I meant with my comment: do they interact in this case, or not? First of all, trust signatures indicate a maximum depth. Regular full ownertrust does not; so are we to interpret this as unlimited depth then? That sounds wrong. Secondly, it seems undesirable. If I /want/ to delegate trust decisions, I would tsign somebody, along with a maximum depth that is no deeper than necessary[1]. However, if I just regular-sign :) their key and assign ownertrust, what I'm trying to say is: "I trust this person to check identities well". I'm not saying "I trust this person to decide for me whether other people are trustworthy". I don't even care about the whole trust signature business unless I tsigned some key myself. In other words, as long as I don't tsign anything myself, I want trust-model pgp to behave as trust-model classic. It seems to be the path of least surprise. So even if the person who has my full trust tsigns some key, I would like to treat that signature as a regular key validating signature, and wouldn't want it to influence ownertrust assigned to the person holding that signed key. When I'm trying to explain the Web of Trust here on the list, I usually say "don't bother with or worry about trust signatures, they're only used in very specific settings". If, however, they do affect the regular Web of Trust, I've been explaining it wrong all along. > Perhaps Werner or someone > else closer to the trust management code can comment on the expected > behavior? I'd like that as well. Because I was almost convinced that full ownertrust would not "activate" trust signatures, but wanted to err on the side of caution and not state this as truth while unverified. But if /you/, so close to the kitchen, actually thought differently, I think it's important to figure out what it is, or is meant to be. Cheers, Peter. [1] As determined by company signing policy, for instance. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Sep 28 20:27:13 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Sep 2017 14:27:13 -0400 Subject: onwnertrust and trust signature (tsig) interactions In-Reply-To: <2afb6244-e270-a9bb-9291-97c153383710@digitalbrains.com> References: <20170921164431.48a03cb3@iria.my-fqdn.de> <20170922192322.2d0cfba2@iria.my-fqdn.de> <87mv5megek.fsf@wheatstone.g10code.de> <20170922213300.28d7c209@iria.my-fqdn.de> <8760c55jw9.fsf@wheatstone.g10code.de> <87zi9gt2xa.fsf@fifthhorseman.net> <6d5c8e94-f389-4b94-e78e-ea915a152d79@posteo.de> <5ec7d5fc-10c7-fc57-d189-b1f19f5f4a17@digitalbrains.com> <87tvzmrbkp.fsf@fifthhorseman.net> <2afb6244-e270-a9bb-9291-97c153383710@digitalbrains.com> Message-ID: <87k20ir85a.fsf@fifthhorseman.net> On Thu 2017-09-28 20:15:33 +0200, Peter Lebbing wrote: > So even if the person who has my full trust tsigns some key, I would > like to treat that signature as a regular key validating signature, and > wouldn't want it to influence ownertrust assigned to the person holding > that signed key. I understand where you're coming from, and i think your interpretation is a (very) sensible one. And indeed, the only place that i've actually used trust signatures (monkeysphere-authentication) uses them directly from an ultimately-trusted key. I hope that my own idea about them chaining from non-ultimately-trusted keys is simply wrong :) > When I'm trying to explain the Web of Trust here on the list, I usually > say "don't bother with or worry about trust signatures, they're only > used in very specific settings". If, however, they do affect the regular > Web of Trust, I've been explaining it wrong all along. If your interpretation is how GnuPG implements them, then the right way to introduce/avoid them in a training is: * don't bother with trust signatures or worry about them. As long as you don't issue any yourself, and as long as you don't assign ultimate ownertrust to any keys that you do not control, they won't have any effect on you. that's already too complicated :( But i agree that it's way better than "oh yeah, and if you assign full ownertrust to someone else, then they can trivially delegate it away at infinite depth " -- yikes! hopefully we'll get some clarification (and hopefully your interpretation matches the intended implementation)! --dkg From alex at nitrokey.com Fri Sep 29 15:29:16 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Fri, 29 Sep 2017 15:29:16 +0200 Subject: Information on scdaemon protocol commands Message-ID: <0d791e2d-4aee-2b3e-bc70-64bbd84da550@nitrokey.com> Hello, I was happy to see, that there is a documentation for the SETATTR command for invoking commands to scdaemon directly by using gpg-connect-agent on https://www.gnupg.org/documentation/manuals/gnupg-2.0/Scdaemon-SETATTR.html#Scdaemon-SETATTR but realized that it is to be written :) Is there any other way to find out the options other than reading source code? I didn't find anything yet... Kind regards Alex From peter at digitalbrains.com Fri Sep 29 15:53:46 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 29 Sep 2017 15:53:46 +0200 Subject: Information on scdaemon protocol commands In-Reply-To: <0d791e2d-4aee-2b3e-bc70-64bbd84da550@nitrokey.com> References: <0d791e2d-4aee-2b3e-bc70-64bbd84da550@nitrokey.com> Message-ID: On 29/09/17 15:29, Alexander Paetzelt | Nitrokey wrote: > Is there any other way to find out the options other than reading source > code? I didn't find anything yet... Talk to the agent :-). $ gpg-connect-agent > scd help setattr # SETATTR # # This command is used to store data on a a smartcard. The allowed # names and values are depend on the currently selected smartcard # application. NAME and VALUE must be percent and '+' escaped. # # However, the current implementation assumes that NAME is not # escaped; this works as long as no one uses arbitrary escaping. # # A PIN will be requested for most NAMEs. See the corresponding # setattr function of the actually used application (app-*.c) for # details. OK > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From alex at nitrokey.com Fri Sep 29 16:04:31 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Fri, 29 Sep 2017 16:04:31 +0200 Subject: Information on scdaemon protocol commands In-Reply-To: References: <0d791e2d-4aee-2b3e-bc70-64bbd84da550@nitrokey.com> Message-ID: <823ca018-ef17-4d7d-bfa1-3b7ad5e985f8@nitrokey.com> Thanks a lot! But what if I want to know more about 'key-attr' for example? I tried scd help setattr key-attr help key-attr scd help key-attr and alike... On 09/29/2017 03:53 PM, Peter Lebbing wrote: > On 29/09/17 15:29, Alexander Paetzelt | Nitrokey wrote: >> Is there any other way to find out the options other than reading source >> code? I didn't find anything yet... > Talk to the agent :-). > > $ gpg-connect-agent >> scd help setattr > # SETATTR > # > # This command is used to store data on a a smartcard. The allowed > # names and values are depend on the currently selected smartcard > # application. NAME and VALUE must be percent and '+' escaped. > # > # However, the current implementation assumes that NAME is not > # escaped; this works as long as no one uses arbitrary escaping. > # > # A PIN will be requested for most NAMEs. See the corresponding > # setattr function of the actually used application (app-*.c) for > # details. > OK > HTH, > > Peter. >