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
--88---
log-file /somewhere/gpg-agent.log
verbose
debug ipc
debug-pinentry
--88---
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
>
> --88---
> log-file /somewhere/gpg-agent.log
> verbose
> debug ipc
> debug-pinentry
> --88---
>
> 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 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 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 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 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 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 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 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
> 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
> 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